Re: Perl's warts

Let's start out with an honest examination of the author's valid points:

Perl is Unix distilled. Things like fork instead of threading, the IPC model, lots of functions, and a strong command-line, text-processing-filter heritage do come from its Unix background. On the plus side, learning Perl is a good way to pick up a lot of useful Unix constructs.

Many functions are tied to their C counterparts. Just try to do any socket programming or file locking without man pages handy. Granted, there are modules to make this easier, but they still require at least passing familiarity with the C library.

Dereferencing gets messy with multi-level structures. Using temporary variables helps here, and it's nice that you can drop the -> for multilevel structures, but wrapping layers of context braces around things gets old.

And where the author is wrong:

Spaghetti Symbols. If the author is surprised that you don't use %hash{key} when accessing a hash element, he doesn't understand the symbols and shouldn't be talking about them. Period.

It's hard to read code other people write. If the author has never encountered coding standard wars in any other language, he has very limited experience. Apparently, even languages like Java and Python allow programmers to choose their own variable names -- and they don't even have to make sense with regard to the problem domain and overall metaphor! Clearly, this is too much flexibility for a programming language.

You have to read documentation to discern the arguments a subroutine expects. This is only a problem if you don't have code like the following:
```
sub this_subroutine_takes_no_arguments_and_returns_nothing {
    # do something here, but nothing useful
}
[download]
```

It's hard to install software on client machines. Though how he intends the client to install his software without being able to install any software is beyond me. (Yes, I'm being facetious.)

Update: I snipped a snipe at Python. It was unfair. If you're really curious, frag quotes part of it below.

Comment on Re: Perl's warts Download Code

Replies are listed 'Best First'.
Re: Re: Perl's warts by frag (Hermit) on Mar 22, 2001 at 04:09 UTC
but he offers no specifics and obviously has a bias toward Python. So be it. I honestly don't see this "bias" as being towards Python given the mild contents of the single paragraph where he mentions it. Not to mention this line from the first page: "But nothing is flawless — indeed, not even Perl." Unless that was sarcastic, but it doesn't seem like it to me. Anyway, it seems to me that whenever Perl gets critiqued, it's the same arguments that get raised (or 'misraised', such as criticisms against implicit variables). It seems like we need a Perl advocacy document (faq, howto, manpage, pod, something), to expand upon the bits of perlfaq1 that address this sort of thing. http://www.perl.org doesn't seem to have this sort of straight-forward doc on hand, just a few points directed towards IT managers. -- Frag.	[reply]

Replies are listed 'Best First'.

Re: Re: Perl's warts
by frag (Hermit) on Mar 22, 2001 at 04:09 UTC

but he offers no specifics and obviously has a bias toward Python. So be it.

I honestly don't see this "bias" as being towards Python given the mild contents of the single paragraph where he mentions it. Not to mention this line from the first page: "But nothing is flawless — indeed, not even Perl." Unless that was sarcastic, but it doesn't seem like it to me.

Anyway, it seems to me that whenever Perl gets critiqued, it's the same arguments that get raised (or 'misraised', such as criticisms against implicit variables). It seems like we need a Perl advocacy document (faq, howto, manpage, pod, something), to expand upon the bits of perlfaq1 that address this sort of thing. http://www.perl.org doesn't seem to have this sort of straight-forward doc on hand, just a few points directed towards IT managers.

-- Frag.

[reply]