Choosing Perl/Python for my particular niche

[Tassilo v. Parseval]

Also sprach Fred Ma:

> This is not a troll posting, and I've refrained from
> asking because I've seen similar threads get all
> nitter-nattery.  But I really want to make a decision
> on how best to invest my time.  I'm not interested on
> which language is better in *general*, just for my
> 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.
> What I hope to do is a bit multifaceted.  What I don't
> do dabble in is web apps (though I'm not sure of the
> similarities).  No XML processing or database
> interaction in what I do.

Who knows, though. The desire to do certain things grows with the skills
one acquired.

> 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
> took a while to do, and I'm concerned at the difficulty
> level.  If I did this kind of thing constantly, I
> would probably get proficient and use the power behind
> it, but it's not my main area.

That sounds like a text-processing task. Perl's strengths in this area
are well-known, so there's no need to go into that deeper. Most
scripting languages (and that includes Python) can be used here.

> 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.
> Likewise, the above translator uses Perl extensively
> in its operation, as well as it's building and
> installation.  If I wasn't passingly familiar with
> Perl, I would have had a much harder time installing
> it.  Being in the approximate area digit circuits,
> I'm concerned about being on the band wagon, if only
> to avoid reinventing things, or impediments to sharing
> things.

This is a strong reason to use Perl. While it may not always be
desirable to toe the line, here it is. The availability of tools that
can easily be integrated into one's own work will save you a lot of
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.

I don't know how much or whether at all the situation for Python has
significantly improved over the recent past. A while ago at least there
was no such thing.

> 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
> example is to take a file of design information and
> do more than tweak it e.g. extract all the information
> about interconnections between circuit building blocks,
> including which is the source block, and which are the
> 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++).

As with text processing, both Python and Perl offer all the essential
things needed for that. On a cursory glance, the score of them is tied.

> 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
> also note that Perl's unweldiness only comes for big
> projects, and I don't expect to using Perl quite that
> way.

Perl wins when it comes to one-liners and maybe replacing shell scripts.
As I tend to forget the syntax of bash's scripting language easily, I've
replaced it entirely with Perl.

Perl's bad reputation for big projects is probably due to the variance
of those people using Perl. One large group is sys-admins who use Perl
in an entirely different way as compared to someone building larger
systems. However, there are enough very large Perl projects that show
that it can be used for that just as easily (at least as long as one
keeps the sys-admins away from the source;-).

> I've seen mention of parrot and perl6, which is quite a
> ways off.  I'm not sure how much that should weigh into
> my decision, since it isn't real yet.

It shouldn't. Perl6 is mostly yet another leap towards fitness for large
projects. I don't think it will gain much for those more hackish tasks.
Also, no one quite knows when Perl6 will be due.

Tassilo
-- 
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval