Need better string methods

[Paddy McCarthy]

David MacQuigg <dmq at gain.com> wrote in message news:<0d4k40987t6d70bahqil3geth640bufgoc at 4ax.com>...
> I'm considering Python as a replacement for the highly specialized
> scripting languages used in the electronics design industry.  Design
> engineers are typically not programmers, and they avoid working with
> these complex proprietary languages, preferring instead to use GUI
> tools that are poorly implemented and very limited in the problems
> they can solve.
> 
> I am convinced that Python can do anything that can be done by these
> CPL's, but I know it will be an uphill battle getting design engineers
> to learn yet another scripting language. The pitch will be 1) What you
> need to solve most of your design problems can be learned in two days.
> Then you can decide if you want to learn the full language. 2) Learn
> this one and you will have a language applicable to not just
> controlling one company's EDA tools, but almost any scripting or
> computational problem you may encounter.  3) Python may well be the
> ultimate computer language for non-programmer technical professionals.
> You won't have to learn another in the future.
> 
> The resistance will come from people who throw at us little bits and
> pieces of code that can be done more easily in their chosen CPL.
> String processing, for example, is one area where we may face some
> difficulty.  Here is a typical line of garbage from a statefile
> revision control system (simplified to eliminate some items that pose
> no new challenges):
<<SNIP>>
> 
> -- Dave
Hi Dave,
I'm also in the Industry, but I find a different set of problems. I should 
first explain that I have worked mainly on Unix Design flows for ASICS and
PCBs. I find that one problem is that the EDA industry was quite quick in 
embedding scripting languages in their tools; Simulators embedding TCL, 
Layout tools embedding some form of scheme/Lisp, and Synthesizers with TCL.
If an engineer wants to learn a programming language then they are pulled 
towards learning the language in their tools. 
Other, more adventurous/capable engineers get seduced by Perl I think 
because they will know csh or bash and have some grasp of sed/grep regular
expressions. To them, the Perl one liner sed/grep replacement is 
decipherable with a little help. They don't notice until too late that they
are writting 50+ lines of Perl that needs to work in 2 years time, and must 
be ported to another project in four months time. They just get hit with 
the porting and maintenance problem *after* they have invested in learning
Perl and can't believe that Python would be better. They learned by doing 
the one-liner and expanding from that. One-liners in Python are, rare.

The Person that already knows Perl will then conveniently forget about the 
warts when a new designer wants to learn a 'scripting language' and will 
point them at perl too.

Re-reading your mail, I guess we are in agreement. You have pointed out how 
other languages are 'better' at one line string manipulation problems.

Maybe what would help would be a Python 'bridge' language aimed specifically 
at short/interactive progs, maybe something like IPython, but any such 
language would then need a converter to Python for when that 20 line script 
grows into a larger program.

Cheers, Pad.