Lee Burgess wrote:
> In my opinion, Perl is a glue language;
This is more than your opinion, it is pretty much accepted fact. This is
its primary utility. It is not, however, its only one.
> it is a disposable scripting language.
Another useful talent. Easy enough to write one-offs when necessary so
that you don't feel you are wasting time or effort in doing so.
> I have taken way too much Excedrin Migraine for headaches
> caused by maintaining OPP (Other People's Perl).
Ok, I'm sorry that this has been your personal experience and I
sympathize with you.
> Perl should not be used for anything really important.
Really? Give me five minutes. Read on...
In May of 1998, I changed jobs. After 11 years as a 'C' and C++ jock, I
ended up at a small, boutique asset management firm in New York City.
$75 billion US in assets under management. Yes, that's small - see
Merrill Lynch. But I think it's still important, yes?
Anyway, a conversion was underway when I got there. The commercially
bought asset management software was being upgraded from version 2.0 to
version 4.0. The biggest difference is that 4.0 brought the ability to
queue up jobs in a database batch table. In 2.0, you had to open up a
pipe to the curses-based client and send keystrokes down the pipe to
implement batch processing.
The existing 5000 line 'C' code was a mess. And mostly irrelevant with
the new software. So, I bet my brand new job and a significant portion
of the company's ability to process client statements on designing a
brand new process in a language I BARELY KNEW - Perl. Why? Because the
'C' was a mess and the process was basically :
1) read data from the database
2) queue up the jobs
3) fire off the client via backticks.
In short, "glue-time". Guess what? That system is humming along today
with minimal problems. In addition to running the asset management
client, the system also handles the coordination of calculation of
rollup data, generation of client statements using that data, and the
archival of those reports in our document management system that allows
our clients to access their reports via the web.
To be fair, the rollup and generation programs are C-based binaries.
However the archival stuff is pure Perl. This demonstrates one of Perl's
strengths, pulling disparate processes together into a cohesive unit.
As far as readability goes, I've had two other people maintain it with
me. I have formal namespaces for all the modules. I use h2xs to build my
module frameworks. I use OO where it makes sense (and sometimes when it
doesn't!)
Another set of colleagues (three to be exact) has designed and built a
security master database system in Perl. It grabs input files from
providers like Bloomberg and regurgitates the inputs into our central
database. The multiple phases are controlled by rules stored in a
database. Which, are themselves coded in Perl and eval'ed as needed. How
many projects have been derailed at the point where a "description
language" had to be written to complete the project? Not this one.
Perl is being used for 'important' things. Using it properly may take
more effort than using Java properly and it can be abused more than most
langages in terms of line-noise resemblance. These are its weaknesses.
In my opinion, the weaknesses are compensated by the flexibility and
speed of implementation as compared to 'C' for example (because my java
experience is limited, I won't make a comparison to java.)
If it is not your experience, I am really sorry. Like anything else,
Perl has its weaknesses and strengths. We can even disagree as to what
those weaknesses and strengths are.
But don't say that "Perl should not be used for anything really
important." Because it is being used that way.
> As an aside, my solution to OPP hell is this: people just need to be
> educated to be better programmers. They need to be taught that
> TIMTOWTDI is an evil trap and an excuse for putting up with clever or
> crappy code. The Real mantra should be The Right Tool For The Job.
I almost agree. It's not that T7I is evil in itself, it's that T7I is
not treated as the means to an end, the end being the code most balanced
between efficiency/maintainability, but rather as the end itself, i.e.,
being cool. People don't put up with T7I, they embrace it. THAT'S the
problem. T7I should be used until you find the best way, for some
definition of 'best way', then move on.
> They need to understand what Larry Wall was *really* talking about
> when he defined laziness, impatience and hubris. They need to
> understand that simplicity, clarity and generality take precedence.
And if speed/efficiency lead away from these goals, there's always ## or
=pod.
Case in point: I had a section of code that was causing a bottleneck.
After stepping back and redesigning, I got improvements. As I understood
better how perl works, I started to optimize small sections at a time.
The coup de grace was classic five-line Schwarzian (spelling?) transform
that replaced a number of slower loops and copying statements.
Now, a ST for a newbie is like Sanskrit. And for me six months later, it
may have been too. But, I put a full paragraph comment in the code (ten
lines, fifteen words per line) before the transform that explained what
was going on line by line and why. Voila. Speed and effiency and clarity
for maintainability. Sometimes you can have it all. :-)
It's not hard. It just takes work. And I think the effort expended pays
off in cycles down the road. Both processing and maintenance cycles.
>
> Okay, I'm done.
>
Hopefully I am too, cause answering this delayed me in dialing into work
and completing my latest project!
--
Matthew O. Persico
http://www.acecape.com/dsl
AceDSL:The best ADSL in Verizon area
Received on Sat Oct 21 14:36:25 2006