Most of what I have to say about this has already been said by other
people, but since this post is addressed specifically to me I'll respond
nonetheless.
[long fullquote deleted - please quote only the parts necessary for
context]
Certainly my opinion is only my opinion. But in my opinion it is not
true that "one language isn't better or worse than the other."
Brainf*ck, Whitespace, and Unlambda, for example, were specifically
designed to be bad languages, and they are.
Agreed.
Perl was not specifically designed to be a bad language, but it is
(IMHO of course) for many of the same reasons that the aforementioned
languages are bad.
I don't think so. It doesn't meet your aesthetic criteria, but it is a
powerful programming language which can be used to write everything from
simple throwaway scripts to large, complex software systems, in a
readable, testable, maintainable way.
It is true that the syntax is rather complex - probably one of the most
complex ones in popular programming languages. This is intentional:
Firstly, because Larry tried to throw all the good bits from lots of
programming languages in (when I first encountered Perl I called it
"the PL/1 of nineties"), and partly because he modelled it after natural
languages, so like natural languages it has a complex, irregular,
context-sensitive syntax with lots of shortcuts. He probably went too
far - Perl syntax could be cleaner and less visually cluttered without
losing expressivity.
Lisp is the opposite - it has an extremely minimalistic syntax, and for my
taste it goes too far in the direction of simplicity and purity. A lisp
program may be easy to read for a lisp compiler, but it isn't easy to
read for me. I need more visual structure.
You write:
Maybe I don't qualify as a journeyman I can't follow that Perl code, and
for exactly the same reason that I can't follow Brainf*ck code: too much
punctuation. What does !~ mean? What do the curly braces denote? What
is /\d/? And if I don't know the answers, how do I look them up? (Yes,
I tried Perldoc. It didn't help.)
Well, all of these are described in perldoc, so I don't understand why
reading it didn't help.
The Lisp code, by contrast, has only three items of punctuation that I
have to understand: parentheses, double quotes, and the colon. All the
rest is English words. Some of those words might be mysterious (like
CONS) but at least I can plug those into a search engine to obtain
additional clues. And the double quotes mean exactly what they mean in
common usage, so that leaves only two punctuation marks to deal with.
That doesn't necessarily make the language easier to learn or read.
On the contrary, I think lisp offers too few visual clues - everything
looks the same to me. (but then I've never used lisp in anger, so in
part this is simply because I'm not used to it)
Also, others have mentioned this but it's worth reiterating: you've
taken actual working Perl code and compared it to a Lisp example
specifically designed to be pathological.
While Carter's code wasn't specifically designed to be pathological it
was pretty bad, too.
But how would the same code look in well-written Lisp? (Ben already
showed well-written Perl).
No, Perl uses sigils to indicate a variable's data type, not a token's
usage. Except that it doesn't.
Right. It doesn't do that but for a completely different reason:
The sigil has (almost) nothing to do with the variable's data type.
Instead it is an article, like in many European languages.
English is a bad example, because it has only one definite article
(the), so let's use Italian:
il - singular male
la - singular female
i - plural male
le - plural female
Gender doesn't have any meaning in Perl, but we can distinguish between
singular ($) and plural. And there are two types of plural - ordered
(lists, arrays: @) and unordered (hashes: %).
So $ denotes singular:
$ x - one x
$ a[2] - one element (with index 2) of the array a
$ h{'k'} - one element (with key 'k') of the hash h
@ denotes an ordered plural:
@ a - the whole array a
@ h{'a', 'c', 'b'} - the elements with keys 'a', 'c', 'b' of hash h, in
that order.
% denotes an unordered plural:
% h - the whole hash h
Note that I have used $ with a scalar variable, an array variable and a
hash variable and I have used @ with both an array variable and a hash
variable. So they clearly don't "indicate the type of the variable".
I have written a space after the sigil to emphasize that it is a "word"
in Perl's grammar and not a part of the variable name. Normally you omit
the space.
(Side note: Sigils are used differently in Perl6)
It distinguishes between scalars, lists, and hash tables,
Yes, but in a different way than you seem to think. Also, these three
are rather fundamentally different (although awk and JavaScript seem to
think that hashes and arrays are the same thing).
but not between integers, floats, and strings.
Right. It doesn't do that. Should it? From a performance POV maybe - a
4byte int takes a lot less memory than a perl scalar value. But from a
correctness POV using representative types doesn't buy you much - you
may represent both the area of your living room and the milage of your
car as a floating point number but that doesn't mean that the sum of
both makes any sense. For that you need a much more strict type model.
It distinguishes between strings and regular expressions,
No, not really. At least not any more than it distinguishes between
numbers and strings. And that distinction is relatively recent.
but not between strings and code.
Huh? Yes, it does. You can compile a string into code, but you'll have
to do that explicitely.
It has all kinds of weird punctuationy things that you can't look up,
like $@ and !~ and <>.
Of course you can look them up. All of them are documented and the Perl
docs aren't that bad (although I agree that they could be better). You
can't use google to search for them, but the same is true for any
keyword or variable name which happens to be a common English word
(although for opposite reasons).
It fails silently where it should produce errors.
That's debatable. Perl is in the C tradition of returning an error value
instead of throwing an exception, but that is only "silent" if the
Programmer carelessly ignores the return value.
It violates universally accepted conventions
about what, for example, double quotes mean. For example, this:
print "The widget costs $12.75.";
The actual behavior of that code snippet is not justifiable under any
sane language semantics.
"Universally accepted" is rather strong given that most shells, most
templating languages and many scripting languages use a similar
expansion mechanism.
The expansion mechanism in Perl has a few shortcomings, but the fact
that Perl has such a mechanism is a feature, not a bug. Apart from a few
pathological examples like the one above, simply embedding variables or
(very) simple expressions in a string is less cluttered and easier to
read then constructing the string with concatenation operators or
formatting functions. And Perl *does* have simple strings, you know.
hp
