Choosing Perl/Python for my particular niche
fma at doe.carleton.ca
Sun Mar 28 01:54:08 CET 2004
"Tassilo v. Parseval" wrote:
> Also sprach Fred Ma:
> > No XML processing or database interaction in what I do.
> Who knows, though. The desire to do certain things grows with the skills one
You might be right. Some digital CAD data is stored in XML.
> 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.
> 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.
> 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.
Thanks for the commentary on Perl, for clarifying the source of unweldiness in
big Perl projects, as well as its nonuniversality.
More information about the Python-list