Choosing Perl/Python for my particular niche

Cameron Laird claird at
Sat Mar 27 16:32:18 CET 2004

In article <40657D14.3FBE7E82 at>,
Fred Ma  <fma at> wrote:
>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.
>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.
Several people have posted good advice already.

Thanks for the clarification; NOW I understand considerably
better your focus on graph-theoretic and related work.

When I characterize you as not primarily a software person,
I'm just trying to say that your aim is engineering or 
mathematical understanding.  You have a life beyond pro-
gramming (good thing!).

My current instinct is that you'll be happiest with Perl--
but it's a close choice, all around.  I'm most accomplished
in Tcl, and would happily use it, or Perl, or Python.  It
seems to me, though, that it's crucial that you be able
to exploit libraries that pertain to your domain, and, in
particular, optimized engines for linear algebra, graph
theory, and linear and mathematical programming.  Tcl 
lacks the weight that Perl and, to an increasing extent,
Python can boast in their libraries.

The most important thing I can do is to continue to push
you in the direction of exploring at least one of Perl 
and Python.  YES genetic algorithms and other adaptive 
methods are available.  Some C++ is more mature--but some-
times Perl, or Python, have taken the lead.  I understand
your concern with performance.  Switch to one of Perl or
Python now, and I think you'll look back on the decision
as a correct one.

That's much more to say on precisely this issue.  It
likely will take weeks to get it all out.  I'm quite
certain of my conclusion, though, even without making the
time to explain it in detail:  you'll be happier basing
your experiments in combinatoric and graph-theoretic
algorithms on Perl or Python than if you focused on C++.

Cameron Laird <claird at>

More information about the Python-list mailing list