Choosing Perl/Python for my particular niche

[Fred Ma]

Cameron Laird wrote:
> 
> 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,

I was under the impression (rightly or wrongly) that Tcl
was good at interfacing to, and controlling, CAD tools.
I was more motivated by the need to massage data, though
they probably overlap greatly.  My experience with Tcl is
limited to using Synopsys DC shell to do unconventional
things, like traverse my design hierarchy (originally
in verilog) flattening and stripping out things.  At the
time, the documentation for their dcshell was more
complete than for their Tcl version of the same.  But
it's good to know that Tcl is an option to Perl and Python,
at least for some things.

> 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.

Good to know that at a personal level, I can run faster with
whichever one I feel more comfortable with (though I have
yet to explore Python for personal comfort).  I was also
trying to take into consideration the prevalence of Perl
in digital design.

Along this line, I should clarify that by CAD, I don't mean
general purpose computer aided drawing.  I mean software
that helps designers in digital design, much of which is not
graphical.  In fact, my area is more combinatoric
optimization and graph theory-ish than drawing.  Sometimes,
I forget that CAD has a much more general meaning than this.

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

I'm surprised to hear that.  Perhaps it's related to the
confusion above (due to the initial generality of my
description).  My thesis research deals with evolutionary
algorithms (EAs) for programming coarse grain reconfigurable
logic platforms.  They tend to be heavy on computation, and
I migrated to C++ for the speedup compared to matlab.
Matlab has been made fast for highly vectorizable
computation, but the restrictive conditions for such speedup
was, too restrictive.  I saw some examples of genetic
algorithms in Perl (or perhaps it was Python), but assumed
(maybe prematurely) that it was much slower than C++.  Other
factors also contributed to this impression, including the
fact that I augment the evolutionary search with local searh
heuristics, giving rise to complicated control flow in the
code.  So I've used C++ for the computation engine code, and
shell/data-massaging scripts for "glue" activity.  Matlab
I'm using because I've got alot of familiarity invested in
its graphing capabilities (to assess data rather than
drawing).  I'm also pretty familiar with its compact
vectorized operations, which helps for data massaging in the
post-processing phase.

> 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.

Actually, I was thinking more along the lines of pipelining
Perl commands in a bash command pipeline, along with other
commands.  But it's good to know that they pipeline within
their own scripts (if I understand you correctly), and for
general shell scripting.

> "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?

The man page for "verilator" says this: "many limitations and
lack of features compared to a commercial simulator".  One
of the things that prompted me to ask about Perl/Python is
because I'm looking at making many changes throughout a
number of files in order to accommodate the limitations.
Regardless of limitations carried by commercial tools, these
are the ones that I have to deal with.

> 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 described my experience with VNC just as an example of the
various situation in which I had to make sense of Perl
scripts.  The vncserver script is written in Perl, at least
for TightVNC, and for older versions of RealVNC I seem to
recall.  That's the extent to which I delved into VNC, since
my area of study (and thus the area where I spend most of my
time) is in "CAD" algorithms, as described above.  I was
driven more by a need to expediently get a certain
kind/level of functionality from VNC rather than the
intention of developing it.

> 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*.

That's good news, from my standpoint.  I don't know what
level of programming qualifies a person to be "specializing
in programming", thus leading to more satisfaction with
Python.  I've tried to read my own C++ code after half a
year, and have gained a new appreciation for the importance
of readability.  So I'm still fine-tuning my idea of
adequate commenting.  Since I'm working on my thesis rather
than commercial code, I don't have large amounts of generic
C++ library code.  Just a big-ish heap of routines/functions
for the problem that I'm investigating, as the algorithms
that I choose to try morph.

My impression is that you think Python would be more
appropriate for my situation.  Just wondering if you can
comment on the merit of having lots of Perl code around.  It
seems to be prevelant in a digital design tool environment.
It may not matter all that much to me right now, but it
would be nice to be on the same wavelength as others if I
find myself in a team situation.  As I mentioned, there have
already been situations where a nodding familiarity with
Perl has helped in making use of other people's tools.

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

Thanks for your comments, and looking forward to hear any
further comments.

Fred
-- 
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6