Choosing Perl/Python for my particular niche

[Cameron Laird]

In article <c43dvk$adq$1 at nets3.rz.RWTH-Aachen.DE>,
Tassilo v. Parseval <tassilo.parseval at post.rwth-aachen.de> wrote:
>Also sprach Fred Ma:
			.
			.
			.
>> purpose.  My area of research is in CAD algorithms,
>> and I'm sensing the need to resort to something more
>> expedient than C++, bash scripting, or sed scripting.
			.
			.
			.
>> One thing I expect to have to do is to modify design
>> files.  For example, there is a tool which takes ASCII
>> hardware desscription language (HDL) and converts it
>> to a C++ (augmented by hardware simulation library).
>> The translator is freeware, so has limitations which I
>> have to make up for by tweaking the HDL code.  In the
>> past, I've eeked out sed scripts for such tasks, but
>> would appreciate a more traditional language.  Since
>> Perl is used alot in digital IC design, I took a stab
>> at that, motivated by the simple need to convert my
>> mail aliases from one mail reader to the other.  It
			.
			.
			.
>> The alternative is Python, which is easier to read
>> from what I've read.  My concern there is that I cut
>> myself off from large availability of stuff that's
>> out there.  For example, I use a PC-to-solaris
>> viewer called VNC, and I've banged my head against the
>> startup script to change it a bit for my situation.
			.
			.
			.
>work on the long run. I didn't know that Perl was particularly strong 
>in the field of IC design. If so, good then.
>
>Apart from this particular case, it's generally a good thing when
>pre-written code exists that can be used. The amount of such code for
>Perl is immense (several thousand libraries) and gathered all in one
>place (the CPAN) with a unified interface to access and install them and
>a vast infrastructure built around it.
			.
			.
			.
>> An additional usage scenario is to (if reasonable)
>> replace my shell scripting e.g. I just converted to
>> bash from tcsh to write scripts that push a document
>> through a series of filters, or simply as a wrapper
>> around a tough-to-use utility e.g. pstops.  A final
			.
			.
			.
>> destination blocks.  Typically, this information will
>> be read by matlab scripts and passed to my C++ code
>> (I've managed to avoid writing code to parse the
>> input file from C++).
			.
			.
			.
>> Whichever way I go, I would like to avoid the overhead
>> of learning both Perl and Python.  I will sculpt out some
>> time in a miserly fashion to slowly get to know one.  Since
>> I spend most of my time exploring the algorithm in Matlab or
>> C++/STL, there's only so much time to pick up higher level
>> languages (it took years before I shelled out the time
>> to switch from tcsh to bash).  One of the things that
>> makes the decision not clear is that despite Python's
>> claim to a gentler learning curve and clearer code, I
>> often like the expedience of sed e.g. a terse one-liner
>> that can be pipelined with other shell commands.  I
			.
			.
			.
Where to begin?  I'm seriously surprised that you haven't
mentioned Tcl, originally created to serve CAD needs, and
still more prevalent than either Perl or Python in CAD,
from all I know.  Perl is indeed present, too, although,
in some ways, PythonCAD <URL: http://www.pythoncad.org/ >
is the most interesting action in this domain.  All three
languages have enough to recommend them, and are close
enough in their capabilities, that I feel comfortable ad-
vising you to choose the one that suits *you* best.  If
you like thinking in Perl, choose that; you'll miss out
on a few Python capabilities, but you'll be as productive
as with any other choice.

Either Perl or Python is going to satisfy you for algorithmic
experiments much, MUCH more than Matlab or C++.  Make the
switch, *now*.

Either Perl or Python can adequately substitute for shell
in the uses you describe.  They pipeline fine themselves;
'fact, I'm working on an essay on how they're *better* at
pipelining.

"The translater is freeware, so has limitations ...":  I
don't understand how to read this.  Has it been your
experience that commercial CAD packages are perfect, and
without limitations?

I work with VNC a lot, too.  You seem to believe that 
there's a special relation between VNC and Perl; do I 
have that right?  That surprises me.  If anything, I'd
say Tcl leads in that domain <URL:
http://www-106.ibm.com/developerworks/linux/library/l-vnc/ >.

I generally favor Python over Perl; in the absence of
more details, I think there's mild evidence that those
who don't specialize in programming are happier over the
long term with the readability of the former.  They're
very close, though.  The one most certain advantage 
Python boasts is a dimension that I'd think important
to you, although you haven't mentioned it:  Python's
interfaces to C++ are MUCH easier to manage than Perl's.
Perl6 will change this.  For now, though, it's FAR 
easier to practice "dual-level programming" with Python
and C++.  If you have a large existing library of C++
work, I think that tips the balance toward Python.
Understand, SWIG and other alternatives make Perl-to-C++
links possible; with Python's facilities, though,
including Pyrex, they're *fun*.

There's more to say; I'll be back later.
-- 

Cameron Laird <claird at phaseit.net>
Business:  http://www.Phaseit.net