ancient-languages-perl
Ancient Languages: Perl
I like Perl. It's a language that, like Fortran, Cobol, Ada and Algol, made its mark on the world. It had a unique style, a large following of loyal users, and a lot of important software got written with it.
Languages never really seem to die. Well, perhaps not many people are coding in Algol anymore, but you can still find plenty of resumes on Monster.com with Fortran, PL/1, and so on. When people get worked up enough, they can write a lot of code, and then later it becomes nontrivial to rewrite it to the same specifications in a more modern language. So there's still a market for Fortran programmers working on giant old legacy Fortran code bases. Heck, there's still a market for Perl programmers.
But if I ever start my own company, Perl won't be allowed there, any more than Algol will be allowed there. You'll only be able to use Perl if there's no other option, and as far as I'm concerned, there's always another option.
I've written looooong, passionate essays about Perl that I never actually published. I used Perl for years, loved it, came off the high, raged against the machine for a while, tried to make unreasonable people see reason, and wrote a lot about it. But I'm not going to publish that stuff because, quite simply, I don't care anymore.
You see, someday I will start my own company, and I'll decide my own hiring bar. I'll of course be my own company's chief technical officer (wouldn't you?), so I'll decide how I expect people to engineer their software. And there will be no Perl. So there's no need for me to get worked up about its use at Amazon. Whew. I feel so much better.
However, when I start my own company, I'll have to write up some coding conventions, and someone may eventually ask why they can't use Perl. So today I'm writing a short, dispassionate, take-it-or-leave-it explanation, and I'll point them to this when the time comes. If they're persistent enough, I'll also point them to the door.
These things are so much easier when you just don't care.
Stuff I Like About Perl
Perl's not all bad, of course. It has some brilliant ideas. Ten years ago it was a great language. Today, not so great anymore.
Perl was created by Larry Wall, whom I'll just call "Larry" for this blog. Smart guy. Has some broken mental models, but he's smart.
Perl's best features were things that "mainstream" programming languages didn't have. Lisp, Smalltak, Prolog, and other academic-ish languages all had their own great ideas. But they hid the OS from you, since people weren't sure which OS would "win". And they had rich data structures, but they pretty much ignored the importance of Strings, the ultimate poor man's data structure.
Larry's first great decision was to embrace the Unix operating system in his language. It has wrappers and even syntactic support for lots of Unix stuff. Operating systems are basically big libraries: big complex toys that you can drive around like a forklift if you have the right tools. Perl made Unix kinda fun, even more so than it already was.
Great idea, fifteen years ago. But pretty much all languages have OS-integration facilities these days.
Larry's second great decision was to elevate the String to the status of Citizen, First Class. That's been useful, because Unix's model is to store all of its configuration (and logs, and virtually everything else, even passwords) in plain-text ASCII files. It hasn't worked so well for XML, HTML, and other heirarchical string structures, nor for multibyte, but regexps still have their many uses.
All languages have that stuff now. Perl 5's "extensions" to regexps are now the standard. You would be hard-pressed to find a language these days that doesn't have support for them. (No fair mentioning Emacs Lisp. *sniff*.)
Of course, Perl5 regexps are actually so complex that it's proven extremely difficult to write an interpeter for them. The Java classes implementing Perl5 regexps are about 7,000 lines of code, and if you look at java.util.regex.Pattern.java, you'll get a free peek into the Intern Project from Hell. Damien Conway threw up his hands, or maybe just threw up, and decided to "start fresh" in Perl 6 with built-in syntax for CFGs. Good luck, DC.
What else? There's a lot to like about Perl. In no particular order...
I like having built-in hashes. Larry was smart to have copied that idea from Awk. The Lisp folks are still hurting from that one. Dunno what they were thinking. "Hashtables, we can do" said Zawinski. Like, um, the point is that he should have been saying "Hashtables, we've done." Not to mention that there's no syntax for them in Lisp; everything is (make-hashtable-this) and (update-hashtable-that). It's a real pisser. Lisp does have associative arrays, but they're implemented as O(n) lists-of-lists under the hood, so they're no good for large data sets.
Incidentally, you might think I'm a Smug Lisp Weenie, but I'm not. Lisp is a mess. The Lisp communities are perpetually at war, the languages are creaking with arthritis, and installing any open-source Common Lisp is a serious undertaking compared to installing Perl, which is all conveniently located in one 40-gigabyte binary. I'll have my share to say about Lisp at some point, have no fear. Lisp is an ideal, the One True Amber of languages, but unfortunately all of the implementations so far have been Shadows. If'n ya know what I mean.
Double-incidentally, I'm sure some of you are thinking: "OK, ummm, ah, what should I use? You seem to hate everything." Yep! Sunny G. put it best, actually. He said I reminded him of Dostoyevsky. He says I'm a "tortured soul", which evidently makes me a good blogger, on account of my liver going to crap, or something along those lines. We were having beers at the time, so his exact wording is a bit fuzzy now. But he's right. I do hate everything -- at least all programming languages.
Or perhaps I should say "dislike?" No, I think "hate" will do nicely. All languages suck. At this junction in human history, the best thing you can do as a programmer (other than perhaps write your own language) is not to get too attached to any particular one, and choose them as appropriate for the task at hand, since each language has its niche. Perl's niche, for instance, is in an alcove with a plaque over it at the Languages Museum.
If you really want advice, and you've considered carefully and decided that for some task you need a flexible, dynamically typed language with great string support, great OS integration, and a strong community with libraries, documentation, and so on, use Ruby. Or Python. Or even Guile or Common Lisp, depending on your stomach for parens. But my best advice is to make up your own advice, and follow that.
Let's see, where was I... Oh yes. The stuff I like about Perl. Now I see why I added the padding-paragraphs above; this section is going to be rather short, methinks.
What else, what else... oh yes! I like... wait, sorry, that's Ruby. OK, I'm sure there's something. Unix commands, string processing, built-in arrays and hashes, lots of C-language operators...
Yep, I guess that about wraps it up. Everything else even remotely interesting about Perl has been done better in other languages now.
Insanity is Not Good Business Practice
I could write a fat book about what I don't like about Perl. But I'm halfway through my second glass of wine, and experience shows that this means I'll become cohinernet soon. So I'll go through it fast.
First: Larry is insane. This means more to me than anything in the language itself. I prefer my heroes to have a firm grasp on sanity. I was never a fan of Don Quixote. Larry says God talks to him, and tells him that He hates non-Perl programmers. Larry is a fruit cake, a nut job, crazy as a loon, batty as a belfry. Don't believe me? OK. For starters, go read this speech by Larry Wall:
Perl, the first postmodern computer language
Now consider the ideas Larry would like us to deduce from his little speech:
Other languages are hammers that can hit things and hurt them. Perl is duct tape that fixes things.
Perl is a young, hip, slightly dysfunctional family. Other languages are just dysfunctional families, period.
Perl is cute, funny, fun, smart, and trendy. Other languages are stodgy, boring, depressing, and have no sense of humor.
All of Perl's critics belong to various cults. These cults are trying to turn everyone into mindless robots.
Perl is associated with the Open Source movement. No other languages are, just Perl.
Perl focuses on individual freedom and creativity. Other languages are grim, sterile, cold-war era, industrial Marxist labor camps and slag mines.
Other languages are little babies. Perl is the President of the United States.
Perl is associated with God. Other languages are associated with the Grim Reaper.
Perl is humble; other languages are arrogant.
You can only perform great Good if you're also capable of great Evil. Because you can write the most awful programs imaginable in Perl, you can therefore also write programs that are far greater than those of any other language.
Perl is postmodern, so Perl advocates are allowed to employ logical fallacies, cheerleading, dramatic swings of opinion, fence-straddling, evangelism, and finger pointing as needed in order to defend their position.
...and so on. Woah, did he really say all that? Psh. That's not the half of it. Go back, read it closely, and see for yourself.
Now do a Google search for "perl religion". Looky looky, the first link is a Slashdot interview with Larry entitled: Larry Wall on Perl, Religion, and..., in which Larry talks extensively about his conversations with God, in which God evidently explains to Larry that He only likes Perl programmers. Larry also says that the world will put him up on a pedestal and claim that he is the Renaissance-y-est man who ever lived.
He means that in the most modest possible sense, I'm sure.
OK, enough about Larry. He's not interesting enough to talk about any more.
Snake Eyes
This section is just a snippet from the Perl documentation. I have it all as Emacs Info pages. Ah, how the heart leaps when I say that. Info's nice, to be sure, but its main interest to me is that it's loosely based on Knuth's TEX typesetting program. I've been reading a lot of Donald Knuth lately. I'll have to tell you about Knuth sometime. He's a Cool Guy, and I don't bestow that honorific lightly in his case. I just don't know if I could do him justice. Buy his books, read them. He's a great man.
In any case, here's Damning Evidence, Exhibit B, in the case of Sane People vs. Perl. I encourage you to read it all. Try to understand it. This is the documentation, written by Larry of course, for an operator consisting of two period characters, and we're not talking Rosencrantz and Guildenstern. Good luck!
Range Operator
--------------
Binary ".." is the range operator, which is really two different operators
depending on the context. In a list context, it returns an array of values
counting (by ones) from the left value to the right value. This is useful for
writing `for (1..10)' loops and for doing slice operations on arrays. Be aware
that under the current implementation, a temporary array is created, so you'll
burn a lot of memory if you write something like this:
for (1 .. 1_000_000) {
# code
}
In a scalar context, ".." returns a boolean value. The operator is bistable,
like a flip-flop, and emulates the line-range (comma) operator of *sed*, *awk*,
and various editors. Each ".." operator maintains its own boolean state. It
is false as long as its left operand is false. Once the left operand is true,
the range operator stays true until the right operand is true, *AFTER* which
the range operator becomes false again. (It doesn't become false till the next
time the range operator is evaluated. It can test the right operand and become
false on the same evaluation it became true (as in *awk*), but it still returns
true once. If you don't want it to test the right operand till the next
evaluation (as in *sed*), use three dots ("...") instead of two.) The right
operand is not evaluated while the operator is in the "false" state, and the
left operand is not evaluated while the operator is in the "true" state. The
precedence is a little lower than || and &&. The value returned is either the
null string for false, or a sequence number (beginning with 1) for true. The
sequence number is reset for each range encountered. The final sequence number
in a range has the string "E0" appended to it, which doesn't affect its numeric
value, but gives you something to search for if you want to exclude the
endpoint. You can exclude the beginning point by waiting for the sequence
number to be greater than 1. If either operand of scalar ".." is a numeric
literal, that operand is implicitly compared to the $. variable, the current
line number. Examples:
As a scalar operator:
if (101 .. 200) { print; } # print 2nd hundred lines
next line if (1 .. /^$/); # skip header lines
s/^/> / if (/^$/ .. eof()); # quote body
As a list operator:
for (101 .. 200) { print; } # print $_ 100 times
@foo = @foo[$[ .. $#foo]; # an expensive no-op
@foo = @foo[$#foo-4 .. $#foo]; # slice last 5 items
The range operator (in a list context) makes use of the magical autoincrement
algorithm if the operaands are strings. You can say
@alphabet = ('A' .. 'Z');
to get all the letters of the alphabet, or
$hexdigit = (0 .. 9, 'a' .. 'f')[$num & 15];
to get a hexadecimal digit, or
@z2 = ('01' .. '31'); print $z2[$mday];
to get dates with leading zeros. If the final value specified is not in the
sequence that the magical increment would produce, the sequence goes until the
next value would be longer than the final value specified.
Actually, a lot of Perl documentation is like that. You really have no idea how many times I've wanted to use the f-word so far in this blog. Really, no idea. But I swore passionately to remain dispassionate. So no f-words. Well, "flip-flop", maybe. Heh.
Ot-Nay Oo-Tay Ight-Bray (if you catch my meaning)
OK, enough fooling around. Let's get right to the heart of the matter.
Perl has references.
Not, mind you, the kind of friendly helper-elf style references from languages like, say, every other flip-flopping language in the universe. You see, those references are merely double-pointers, and they're automatically de-double-pointered for you, because the compiler or interpreter in question (along with its author) has what you might call the Humane Instinct. As in: Oh, the Humanity. That kind of Humane. (Glass Three, can you tell?)
Perl's references are basically pointers. As in, C-style pointers. You know. Addresses. Machine addresses. What in the flip-flop are machine addresses doing in a "very high-level language (VHLL)", might you ask? Well, gosh, what they're doing is taking up about 30% of the space in all Perl documentation worldwide.
Being nominally responsible for developer training here, you'd think I might tend to notice when some particular concept, such as Perl's references, takes up 1/3 of the classroom time. And 1/3 of the discussion time. And 1/3 of my farging blog. And you'd be right, you would. They're not pulling their weight. Not by a long shot.
Languages are hard to design. They are. Really. Language acquisition is one of the most fundamental activities of humankind, one of the most researched, yet still among the least understood. It's been studied by linguists, by psychologists, by anthropologists, by neuroscientists, by philosophers. Language is one of the Great Mysteries. How can a set of arbitrary symbols, arranged according to arbitrary rules, imprint images so deeply in our minds? Is there a Universal Grammar, as Chomsky theorized? Is the human brain a blank slate, capable of adapting to any language, or is it hardwired to accept only certain patterns? Is one to believe Wittgenstein's Tractatus, that language is unable to represent the images imprinted on our minds, and is to forever bewitch us with nonsense? Are language designers forever to apologize for their work?
Really. I'm serious. Hard to design. You have to give Larry credit for trying and succeeding so wildly. Larry, here's some credit. Don't let it go to your head.
Every language designer screws up now and then. No exceptions. Gosling says he got the precedence of some Java operators wrong. if (!(that's instanceof Understatement)), I don't know what is. McCarthy frets about all the parens in let clauses. As if those are the only ones to fret about. And Guido has been known to physically murder people who complain about Python's syntactic whitespace.
But Larry outclassed them all. Not only did he make a mistake which, in the grand scheme of things, is to language design what Chernobyl is to backyard barbecue accidents, he won't actually admit it was a mistake. Instead he markets it as your educational problem.
The mistake is that very early on, Larry decided to flatten lists by default. Hence, if you write this:
@x = (1, 2, 3, (4, 5));
It automagically turns into (1, 2, 3, 4, 5). Convenient, eh? Sure it is. If you want to be your own father's sister, it's extremely convenient. If you want every file in your filesystem to be in the root directory, it's darnright useful. It's especially advantageous if you want to collapse the entire universe into a single electron, since that's about all you can do with it.
Oops! Oh yeah, right. Trees. Graphs. Object models. Window systems. Company organizations. Relationships. Meaning and semantics. Heirarchical knowledge representation. Gosh. Forgot all about those. Whoops.
I could talk and talk about it, dispassionately of course, but I just don't care. The long and the short of it is that by flattening lists, Larry prevented the Perl world from creating nested data structures. Before Perl 5 came out, the workaround was to take advantage of Perl's other Great Evil, which is that variables can contain more simultaneous values than Imelda Marcos's closest can contain shoes. So you could build heirarchical data structures by simply hacking the typeglob slot system. Heck, you can do it with Strings if you're determined enough.
To alleviate the situation, in Perl 5, Larry added references, which are sort of like C pointers, but more confusing, and with none of the inherent value of pointers. Then he marketed them a lot, saying things like "references are FUN", and "you can take a reference to ANYTHING", and you are a "COMPLETE DUMBASS if you can't understand references", and so on. He sprayed on some more syntax to cover up the smell, so there are now dual syntaxes for virtually every Perl declaration, as if auto-flattening, pseudo-type sigils and typeglobs weren't bad enough. Perl zombies everywhere dutifully memorized the inner workings of references, which merely furthered their zombification. And that's where it stands today.
Perl works the way you do.
It's All Downhill From There
Perl also has "contexts", which means that you can't trust a single line of Perl code that you ever read. Every operator in Perl (not just the Range operator) has six different behaviors depending on the invisible context in which its surrounding expression is being evaluated. When you evaluate a hash in a string context, for instance, you get back a string that's a fraction, such as "7/10", the numerator of which represents the current number of keys in the hash, and the denominator of which represents of total number of buckets allocated. And so on, and so forth. There are no rules, no heuristics, no patterns. It's pure memorization. Commit the Perl Periodic Table of the Operators to memory, and you're officially 1/1000th of the way down the road to Perl Zombiedom.
Like any well-designed system, Perl of course has hundreds of global variables. They're typically two characters long, the first of which is a dollar-sign, and the second of which is either an ASCII character or a Unicode character. Changing the value of any one of these hundreds of variables changes the meaning of at least 10% of the lines of code in your code base. One can only speculate as to what $ξ does, or $葉 for that matter. I'm sure it's in the docs somewhere.
And Perl itself is the world's ugliest, most un-maintainable binary. Perl zealots have written articles intended to be motivational, but they clearly call out the fact that if Larry ever gets hit by a bus, nobody will be able to do anything to Perl anymore.
Perl 6 is not the answer. Damien gave perhaps the most compelling PowerPoint presentation in the history of technology when he visited us at Amazon 2 years ago. But even if Perl 6 should ever materialize, which is a matter of some debate, I believe it's been too damaged by Larry's broken mental models to be a viable language. It does show tiny hints of promise now and then; back when Damien gave his talk here, I chatted with him afterwards about list flattening, and mentioned that it was the root of all evil. He was a bit taken aback, and said they weren't planning on changing that feature. I read recently that they've decided to change it after all; you'll have to set some godawful global variable, possibly dollar-unicode-chinese-horse-symbol, to turn on auto-list flattening.
The Right Set of Legos
There's still no real hope, though. Perl provides too many specific building blocks and not enough generic ones. Perl 6 will obviously be no exception. Specific building blocks -- i.e., shortcuts -- are nice to have around when you need that particular shortcut. That's how a language gets its reputation, its niche. Perl's shortcuts are all about string processing and list slicing and scripting and so on.
Unfortunately, writing virtually anything "generic" in Perl requires you to be a contortionist, as my Amazon Developers Journal programming challenge about string permutations so clearly demonstrated. Larry provides you with thousands of shortcuts, but there's nothing so fundamental as providing parity across list and string operations, and a full set of consistent higher-order functions that work on every collection type. I guess he forgot that one.
To illustrate just how important this is, let's talk Legos. A programming language is just like a set of Legos, you know. When I was a kid I played with Legos, and built all sorts of pathetic, dumpy little houses and spaceships and stuff. I loved them. Those Legos let me build anything my imagination came up with. Decades later, Legos are still going strong, but they've turned into jigsaw puzzles. You can buy a Pirate Ship Lego set, and with it you can build... a Pirate Ship! And, and, you can move the people around on it! But try building a crocodile and you're screwed, unless the set came with a big misshapen Lego in the form of a crocodile. Of course then you're screwed if you want a lion. And so on.
With the right set (and number) of generically-shaped Lego pieces, you can build essentially any scene you want. At the "Downtown Disney" theme park at Disney World in Orlando, there's a Legoland on the edge of the lagoon, and not only does it feature highly non-pathetic Lego houses and spaceships, there's a gigantic Sea Serpent in the actual lake, head towering over you, made of something like 80 thousand generic lego blocks. It's wonderful.
Dumb people buy Lego sets for Camelot or Battlestars or whatever, because the sets have beautiful pictures on the front that scream: "Look what you can build!" These sets are sort of the Ikea equivalent of toys: you buy this rickety toy, and you have to put it together before you can play with it. They've substituted glossy fast results for real power, and they let you get away with having no imagination, or at least no innovative discipline.
Perl's exactly the same. Perl's success is all predicated on its marketing, nowadays; after all, any idiot can see that there are much better languages out there. Take your pick. But Perl's marketing shows you glossy pictures -- look at our arrays! Our hashes! Our clever contexts and typeglobs and references! Look how postmodern we are! And programmers new to high-level programming ideas (including truly new programmers, and also C/C++ programmers who've spent months writing buggy char-buffer manipulation routines) see the marketing and think: Gosh. A pirate ship. That's soooo cool.
A Farewell to Perl
In the fifteen years since Perl was first introduced, language designers have figured out that (a) Perl had some good ideas worth copying, (b) Perl had many other bad ideas worth nothing whatsoever, and (c) marketing is all-important. Most programmers only ever master one language, and the difficulty of the feat (particularly if the language is insane, in the way that Perl and C++ are insane) makes the programmers never want to learn another language. You need marketing to get adoption. Larry Wall is a formidable marketeer, better at it than most Harvard business school graduates.
I wrote a complete essay about this that I was ready to publish, but I decided it's perhaps a bit too controversial. The gist of it is that languages really are religions, and they maintain their grip on their laity by fear of Death. After programmers spend years memorizing the proper incantations, telling them that their hard-won language is going away is like pointing a gun at their family. They feel that learning another language would take years, during which time they lose their value and could easily become unemployed. It's not just a simple matter of starving -- they could lose their medical insurance, get hit by a car, die on the hospital steps, and their family would starve. When I say languages are religions, it's a pretty serious business. Insecure programmers feel their very lives are on the line. It's no wonder that so much spittle flies when we get into language wars. Thoreau says the mass of men lead lives of quiet desperation. Not programmers, though. They lead lives of really loud desperation.
Desperate or not, those people aren't going to work for me. I demand excellence from my co-workers. The disease, nay, the virus of programming-language religion has a simple cure: you just write a compiler. Or an interpreter. One for any language other than the one you know best. It's as easy as that. After you write a compiler (which, to be sure, is a nontrivial task, but if there's some valid program out there that you couldn't ever write, then you're not justified in calling yourself a programmer), the disease simply vanishes. In fact, for weeks afterwards, you can't look at your code without seeing right through it, with exactly the same sensation you get when you stare long enough at a random-dot stereogram: you see your code unfold into a beautiful parse tree, with scopes winding like vines through its branches, the leaves flowering into assembly language or bytecode.
When you write a compiler, you lose your innocence. It's fun to be a shaman, knowing that typing the right conjuration will invoke the gods of the machine and produce what you hope is the right computation. Writing a compiler slays the deities, after which you can no longer work true magic. But what you lose in excitement, you gain in power: power over languages and over language-related tools. You'll be able to master new languages rapidly and fearlessly. You may lose your blind faith, but you gain insight into the hauntingly beautiful machinery of your programs. For many, it deepens their real faith. Regardless, it lets them sit at the table with their peers as equals.
But I don't care. I'm tired of fighting ignorance. I'm off to find smart people and do great things. Well, it's late, so I think I'll just go read a book.
(Published Dec 04 2004)
Comments
Another terrific essay Steve. I'm citing your blog to potential new-hires as another reason to work at Amazon...
On the clunkiness of the alternatives to Perl...
You include lisp, and with some good reason (The lack of truly polymorphic access to the built-in containers in common lisp is rather annoying. And string support is a bit insane in places.)
But at least lisp lets you _fix_ the things that you don't like, and in a seamless way. It's easy (as Paul Graham is doing in Arc) to write a variant of 'let' that defaults to a single binding and so eliminates all of the parentheses. And if you don't like the default hashtable functions, just write some convenient syntax wrappers.
e.g. Michael Parker has written reader-syntax macros that implement most of Awk in Common Lisp
"Lisp isn't a language, it's a building material." - Alan Kay.
Posted by: Chris N. at December 6, 2004 06:28
(Is it bad form to reply to my own comments?)
I wrote...
>>>The lack of truly polymorphic access to the built-in containers in Common Lisp is rather annoying.
But I just noticed that (coincidentally) Michael Parker has written at least a partial fix for that too:
http://www.geocities.com/mparker762/
>>>Also a generalized reference system, so you can get and set lists, arrays, strings, hashtables etc polymorphically.
>>> This is not yet a full generalized container system, but
it's a handy first step.
If language designers can't be relied upon to get everthing right in every case (as seems likely), then the best alternative is to give the users a way to fix and extend things themselves.
Posted by: Chris N. at December 6, 2004 06:41
But what do you do until that day when you get to start your own non-Perl-based tech company? Is there gritting of teeth involved, or do you just go about your daily business, secure in the knowledge that you will do it differently - someday? I'm being a little cheeky, but it's also sort of a serious question stemming from my newness to Amazon.
I had a whole lot of flexibility at earlier positions, and I used this to my advantage: using Python when I thought it was the right tool for the job, using Ruby for other projects. That worked fine, but these were smaller ponds where I was a relatively big fish. What happens here, where it's a very very big pond indeed?
Posted by: Brian W. at December 6, 2004 09:10
I'd say the ad hominem attacks on Wall were unnecessary, except they seem to form at least 1/3 of your argument. If you had ever met the guy, or attended a State of the Onion talk, you would see how humble this guy is. Expectations are so high for his talks to be hilarious and insightful simultaneously that sometimes he misses both marks, understandably. And, you have to give some slack since the talk was intended to be given only with aural sarcasm and only for Perl & Linux zealots.
Anyway, I think of perl perhaps in a reverse way, trying not to miss the forest for the trees. There are certainly too many quirks in the language, that basically just have to be memorized (list flattening is one of them) - and probably more in Perl than in any other language. Perl doesn't appear to be derived from a minimal set of regular rules; rather it is, but to a language theorist there are so many exceptions as to drive you crazy. Perl is to computer languages as English is to natural languages.
Generally these are the result of well-intended DWIM (Do What I Mean) that has aged poorly. That's why perl has a "cult" - if your DWIM matches well with perl's DWIM, you are a happy camper; if not you are stevey. :) Actually the large number of well-intended yet stupid DWIM's in Perl 5 are the driving force for Perl 6. If it ever arrives, it's anybody's guess whether Ruby programmers will flee to Perl6 the way Perl5 programmers are currently fleeing to Ruby.
Ultimately the productivity, success, and happiness of the people using perl will have to be the judge of the success of the language itself.
I wish your future non-Perl company well. But don't worry about Perl at Amazon. All our programmers who use Perl also use at least 1 other language daily...let's get the same from our Java programmers.
Posted by: Doug T. at December 8, 2004 07:05
Thanks for the well-considered comments, Doug. The essay is just my own opinions, and language discussions always come down to matters of taste, so my responses here are of little worth. Nevertheless...
> I'd say the ad hominem attacks on Wall were unnecessary
I'm afraid they really are necessary. Larry has turned what was a gentleman's war into guerilla tactics. He consistently and cleverly (I never said he wasn't brilliant) slanders other languages and language communities, and encourages this behavior in his lieutenants. He's made logical fallacies fair game, and he regularly crosses the bounds of common decency, so I have no qualms about employing ad hominem in response. I've given it considerable thought, and tried for at least a year to finish this essay. It was only when I realized I have to combat his tactics with my own political commercials that I was able to make progress. So ad-hominem it is. He's crazy, and I'm not going to politely gloss over the issue. Reminds me of this movie dialogue:
Will Graham: I know that I'm not smarter than you.
Doctor Hannibal Lecktor: Then how did you catch me?
Will Graham: You had... disadvantages.
Doctor Hannibal Lecktor: What disadvantages?
Will Graham: Passion. And you're insane.
> you would see how humble this guy is.
What he's like in person is irrelevant. Most of the world hears his message through his writing, as he well knows. His speech is by no means an atypical example of his writing, so his behavior at conferences can only be considered posturing. He is the consummate marketer, after all.
> Perl is to computer languages as English is to natural languages.
This is far and away the strongest argument against Perl. English is a terrible language, desperately in need of spelling and grammatical reform. By anyone's standards, it should be the last model you'd use for a design philosophy. Larry uses "Just like English" as one of his typical silly appeals to nonreason. Not surprisingly, Perl isn't very popular in non-English-speaking countries; they know better.
> Ultimately the productivity, success, and happiness of the people
> using perl will have to be the judge of the success of the language
> itself.
This might be true, if you find a way to include the productivity, success and "happiness" of people who are forced to use it because there's so much of it at Amazon. Many people are miserable about the whole Perl experience, yet Perl's marketing (which is also conducted internally by card-carrying cult members) makes folks feel it's their fault for not liking it better.
> let's get the same from our Java programmers.
Indeed. Everyone ought to be comfortable with at least five languages. Twenty is even better. The one I've been tackling most recently, incidentally, is PostScript. Knowing a whole bunch of languages is very nearly as effective as writing a compiler or interpreter.
Perl, for all its flaws, is still preferable to C++ in most cases.
Posted by: Steve Yegge at December 8, 2004 08:51