>From: Amara Graps <Amara.Graps@mpi-hd.mpg.de>
>From: Russell Whitaker (firstname.lastname@example.org), Fri Jan 19 2001
> > >I envy you taking up your first language, if it is
> > >indeed your first. I've worked in about a half dozen
> > >languages, and would now argue against Perl.
> > > Consider PostgreSQL instead of MySQL (unless you don't
> > > find the lack of transactions in MySQL a hindrance).
>The programmers coming out of the woodwork talking about their
Actually, Amara, as you well know it's my third favorite
>Perl isn't so bad, Russell. It's a reasonable workhorse for
>scientists like me. I don't have time to continually learn new
>programming languages (I already confuse the syntax of the ones
>that I know).
Oh, I'm not saying Perl's _bad_, just that there are tools
I'd rather use now.
Of course, I'm not a scientist, I'm a programmer who has to
use these tools on a daily basis, and sometimes (this is the
kicker) manage other programmers using these tools.
Have you ever tried to manage a _large_ codebase written
in Perl by a team of programmers? It's enough to make one
I've written a longish essay which I revisit and refine from
time to time. If you're interested, Amara, I'll send you the
URL. It grew out of a tech talk I gave at a client company
last summer. It's a Python advocacy piece, of course.
A couple of points I can mention here though: Python is _much_
easier to learn than Perl. I had the benefit of a direct education
from Randall Schwartz himself (glad SGI picked up the bill), and
eventually became a pretty fair Perlista. It took a long while
I do think you'd find yourself productive in Python given
a few hours of study. There are very good libraries for
scientists, such as NumPy (http://sourceforge.net/projects/numpy).
See also: "http://www.python.org/topics/scicomp/".
Check out "Scientific Computing with Python" too:
>For non-purist, old-fashioned scientist types like me: Perl + DBI + an
>SQL db like Oracle or Sybase is a powerful combination for database
>and Web interaction. I think that DBI is enough reason to go with
>Perl. It's a wonderfully, solid and supported library.
For some applications, this is fine. I've done a good deal
of just that type of Perl/DBI::DBM work against various DBMS
stores. Sufficient for most DML operations but a bit spotty
in support of DDL operations (access to the data dictionary),
especially for the Sybase driver (what you use to talk to
Sybase-badged and "Sybase Lite" pre-v7 MS SQL Server DBMSs).
This can be annoying when you write code which talks to
the data dictionary to generate SQL DML clauses.
You can do the same work in Python too:
Oh, yes, a related nice thing about Python: if you don't
want or need to persist your data in an RDBMS, you can serialize
your data objects to disk using the shelve mechanism. That's
another subject... feel free, anyone, to start a subthread
on this. Go a bit beyond though and discuss next-generation
object databases such as ODI. ;-)
As for the "purist" thing, I don't think that's an issue with
me. From time to time I prefer to re-assess my toolkit and
re-educate myself. I'm keeping an eye on the Ruby language,
just in case it takes off and becomes widely useful.
>And Perl comes in handy for alot of other data processing as well,
>but then I am a data monkey.
Hmmm... _really_ sounds like you should at least do a little
digging into Python. It's much easier to create new data
types and manipulate them. Object orientation is built into
the language from the ground up, not bolted on (Perl).
Get your FREE download of MSN Explorer at http://explorer.msn.com
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 09:56:24 MDT