[oclug] Why Perl is a Bad Language

[Adrian Chung]

I really, really, didn't want to get into a debate about the merits of
Perl as a programming language.  But I can't help myself, since I
can't see how your arguments, and other people's quoted views show
that Perl is a bad language.

On Thu, Feb 22, 2001 at 11:21:31AM -0800, Francis Pinteric wrote:

[..snip..]

> There are complaints about whether or not Perl is really the tool for
> XML (http://www.xml.com/pub/2000/10/11/perlxml/index.html).

So what?  There are complaints about all kinds of languages.
Complaining about something doesn't make that something "bad".
Complaining that Perl isn't the tool for XML may well be true.  So
choose another tool.  That doesn't mark the language as a "bad language".

> Also for ordinary everyday uses, Perl is simply bloat! Time and again
> of the years I see questions on this list "how do I do X" and a one
> line perl scripts comes out that could also be done is a one or
> several line shell script using awk or sed that is faster and more
> efficient. Here is another reference to someone else who thinks the
> same way:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0001.0/0547.html
> (although I could have done his example in one line using awk; c'est
> la vie). Time and again, I see examples of programmes that people
> start out writing in perl then regret it:
> http://oasis2.openave.net/pub/88/6/contrib.log.pl.html (one example
> only).

How is this justification that Perl is a bad language?  People have
chosen to use the wrong tool.  If I can do something faster and more
efficient in shell, then use shell.  If I start writing something in
Perl, and then regret it, then I obviously chose the wrong
language/tool for the job, didn't I?

> In the end it's easier to use shell scripting to do ordinary things.
> Perl was designed as a specific tool to read USENET lists because he
> decided (quite rightly) that the shell scripts in an of themselves
> were too slow to do what he wanted. However, I've found that now the
> reverse has happened: people are using Perl to do things where shell
> scripting is the correct solution.

I agree, people are using Perl to do everything, and things that
shouldn't be done in Perl.  Maybe they should be done in shell.  But
shell can't be necessarily used without modification across 80
platforms.

> Now, to counter Larry Wahl's assertion that because the problem space

It's *Wall* dammit! :)

> 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
> diffuculty in proving a (software) solution and it's called

[..cut lecture about NP completeness...]

> cases becomes exponentially large (there's that NP again). With Perl,
> the test set becomes even larger, in fact it becomes an NP^NP
> complexity problem.

Because there's more than one solution to a problem does *not* mean
that the solution becomes complex, or that proving that the solution
works is complex.  How does the test set become larger because there
are more ways to solve a problem?  You have a problem, and you know
that when solved it adheres to certain requirements.  That sounds like
a static test set to me.  Does it do what it's supposed to?  Who cares
which way out of 50 ways it was solved, if it does what it's supposed
to.

Many ways to solve a problem allows for creativity in a solution which
might otherwise be complex, or impossible without these many ways.

> With validation being such an important issue to some of these
> software issues, the complexity of proving correctness becomes
> impractical.

I still can't see how, with proper requirements, proving correctness
becomes impractical because there are many ways to solve the problem.

Please draw a distinction between a "bad programming language" and a
programming language which may not be the ideal tool in every
situation.

Perl, as has been mentioned both by you, and historically, was
designed to parse text.  That's it.  It does everything under the sun
now, but it's a damn good language for manipulating text based files.

--
Adrian Chung - adrian at enfusion dash group dot com