[oclug] Why Perl is a Bad Language
Michael P. Soulier
msoulier at storm.ca
Sun Feb 25 16:17:22 EST 2001
On Thu, Feb 22, 2001 at 11:21:31AM -0800, Francis Pinteric wrote:
> Yawn! Ok, quoting St. Augustine is not reasoned. Ok, let's quote
> Larry Wahl himself: "Perl is a mess. It's a mess because the problem
> space is also a mess." By problem space he's talking here
> specifically about webpage design and other internet stuff.
Actually no, he's not. He's talking about day-to-day problems that need to
be solved. Sometimes those are internet solutions, but certainly not all the
time. I've used Perl for 2 years now and very little of it has been for CGI
scripts. Most of it has been for where Perl was designed for, in that space
where C takes too damn long and shell isn't ehough. In other words, getting
the job done. Period.
[references to others of the same vein snipped]
We can pass peoples opinions around all day. Lets try thinking for
ourselves, shall we?
> Validation and Verification
>
> This might not seem important to most people on this list, but for
> those of us who do and have worked in industries where software
> errors can be very expensive or cause loss of life, this is
> important. So, in this area, being able to prove that a piece of
> software does what's it's supposed to do is vital.
Agreed.
> The motto of Perl is "there's more than one solution to a problem"
> make this sort of proof very difficult. There is a measure of the
Untrue. Just because there are many solutions to a problem does not
inherently complicate any one solution. You know that. What it does do is
provide more ways for a novice to get their work done. It also provides more
ways for them to screw up. C'est la vie. That's why they're supposed to have
mentors. Now, if you want to use a "safer" language that assumes the
programmer is a moron, fine, but don't you think there should be something
better to graduate to some day that doesn't tie your hands?
> the test set becomes even larger, in fact it becomes an NP^NP
> complexity problem.
Incorrect. At any one time you are using subset of the language. You do
not have to prove the validity of code that you did not write. That's
nonsense.
My only problem with Perl is pretty much the same problem that I have with
Emacs and Netscape. The Unix philosophy is to do one thing and do it well.
Perl does too much. I can't deny it. Then again, I can do a helluva lot with C
too, so maybe that should go. Hey, ditch assembly, you can do anything with
that.
Maybe we should draw the line between the potential to do too much, and
doing too much?
Perl is only a problem at work for me when people write code that sucks.
Since Perl doesn't police these people (like the more Draconian languages like
Java and Python), I have to and that creates work for me. Maybe we should just
hire smarter people, or train them better.
That said, I think Python is neat, but I use the right tool for the job
whenever I can. For Unix toolbuilding, and pseudo system administration, that
has mostly been Perl, with some Bourne-shell, sed and awk thrown in when the
code base wasn't going to be too large and performance wasn't a big deal.
Sorry, but continually forking processes is _not_ good performance, so often
the Unix pipe is overused. Plus, it amazes me when people say Perl is cryptic
and then go and write a Unix pipe a mile long. Yeah, that's fun to debug.
Mike
More information about the OCLUG
mailing list