Perl's State of the Onion 10

chromatic writes "Larry Wall's annual State of the Onion addresses cover subjects such chemistry, science, music, lingustics, and screensavers. They occasionally discuss Perl too. This year's, State of the Onion 10 compares raising children into productive adults to guiding the development and design of a programming language. Perl turns 19 soon; Larry says that she'll truly grow up with Perl 6."

Comments

Summary

[kestasjk]

An interesting and fun read, it lists and explains the challenges being faced with Perl 6 very well. Unfortunately it doesn't explain how Perl 6 will respond to those challenges; just that Perl 6 will be WOP (whatever oriented programming), which is more than a little vague.

After having read it I get the feeling Perl 6 is having an identity crisis, but that Wall knows what he's doing.

Larry is boring

[Eivind]

Larry Wall is just boring.

He tries desperately hard to be creative, funny, surprising, to add new perspectives.

Yet, when it comes down to it, he ultimately writes 5 pages of nonsense. He really does say amazingly close to nothing in all those pages. No. A large white square with the literal text "Whatever" in the middle doesn't really tell anyone anything significant.

And no. The skills needed for successfully managing a family and raising children doesn't, infact, have much in common with those skills needed to develop and maintain a programming-language.

Every time I read something from Larry, I become happier that I left Perl for good several years ago.

Re:Larry is boring

[mrsbrisby]

I become happier that I left Perl for good several years ago.

We're glad you stopped programming.

And no. The skills needed for successfully managing a family and raising children doesn't, infact, have much in common with those skills needed to develop and maintain a programming-language.

I think programmers understood that he wasn't suggesting otherwise.

See, there are a lot of programmers (especially those that learned in the last 5 years, but plenty still that have been working in software development for longer) that programming constructs are taxonomic so e.g. an Apple is a Fruit which is an Edible, or Apple follows the protocols (interface in Java-speak) [hasColor,hasShape,somewhatRound], and that if we can just classify everything, programming would only have to tackle new patterns and problems that have never been tackled before.

These people are, however, wrong. Just as it is with kids, exceptions and special-cases are the norm, so it makes sense to acknowledge this.

A large white square with the literal text "Whatever" in the middle doesn't really tell anyone anything significant.

People have a lot of crap to do, and most of the things that they have to do, they accept a very fuzzy concept of how fast, or how clean that it has to be. They just want it done. Perl has always been good at filling that. The naysayers like to talk about what kind of a niche that is, and clarity or raw performance is much more important, but the reality remains that these niche exceptions and special cases are just so-common that they need a readily available system for dealing with them. Some people call it a programming language. Others call it Perl. Others say "whatever".

What you meant to say is it doesn't tell you anything significant. That's a completely different thing, and it might have to do with you not being a programmer.

Operator Error

[Killer Eye]

While indeed Perl operators are becoming more "consistent" among themselves, I think Perl's decision to undefine decades-old comforts like the ternary operator (?:) and bit shifting () is a huge mistake. If a language wants to change these things, the results should be clearly *more* intuitive, not just different. Take Python, which recently added the following style of ternary operator: "x = 1 if cond else 2". Yes, it's not "?:", but to me it's a lot easier to understand than the equivalent Perl operator. The fact that Python was able to add a feature by reusing keywords is even better.

Some Perl 6 additions will prove quite useful, like the zip() function (which Python has had for some time, incidentally). Some changes are moderately useful, but it is difficult to see how they are superior to Perl 5 (like getting rid of the "_" short-cut for stat calls in favor of sequencing calls). But a lot of the stuff just doesn't seem to warrant all the effort to change scripts: programmer time is expensive, and is wasted twiddling ASCII characters just because the language wants to use new characters to express *exactly the same concept*.

In my case, I will probably look at my array of Perl scripts, and I will probably decide it is easier to finally switch them over to Python or another superior language. At least then, I will gain something for my trouble.

Re:Death Valley

[6031769]

I agree with you entirely that the longer the "Next Great Version" takes the less will be the interest when it finally arrives, and that's generally a truism as well as applying specifically in this case.

What differs with Perl is that Perl5 is such a good language (for those who actually use it) that its use and development will probably continue apace (as they have during this whole Perl6 dev cycle). I really like Perl, but the Perl I like is Perl5. By trying to turn it into an "all things to all people" language with the transition to version 6, it will doubtless lose a lot of that. If Perl6 ever does really officially see the light of day, I very much doubt that I will spend much time using it. Rather, the established Perl5 (and there is a hell of a lot of it about) will continue to be my primary focus.

There are other examples of this, of course with "classic versions" of several apps (and even OSes) being run after newer versions have been produced because either the newer versions add no value or increase bloat or just take the system farther from that which it used to be (Yes, I'm talking about you, AutoCAD). There are also plenty of folks still using (even deploying) Apache 1.3 today and many of them have good reasons for doing so.

So my point is that even though the direction and implementation of Perl6 may be flawed, it does not by any stretch mean the end of Perl as a useful and productive language with widespread appeal.

Re:Perl 6 might be great... not.

[grinder]

Hypocricy? I don't think this word means what you think it means. Could you explain what you think is so hypocritical about this design decision?

From what I understand, the Perl6 operators were chosen according to Huffman compression principles. Frequently used operators became shorter, less frequently used operators became longer.

The bare colon operator turned out to be much more useful elsewhere. The dash-arrow operator was initially borrowed from C++, but these days, most dynamic languages all use dot for the same purpose.

This sound more like pragmatism than anything else.

The version after Perl 5 is Python

[Animats]

Perl 6 is a step forward from a language design perspective. A big step forward. Such a big step that, if you're going to change, you may as well go to Python and dump the Perl uglyness.

The real problem with Perl is that it's a good language for small programs, but 10,000 lines of Perl is a mess unless you're a very disciplined programmer. The "there's more than one way to do it" is hell on maintenance programmers, because they have to know everything in the language to read code. Nor is reading Perl easy. I used to need three different Perl books when doing maintenance programming, because no one book, including Larry Wall's, covered everything in the language.

Perl made the Web happen in the same way that Basic made the PC happen. We're grateful to Larry for giving us this tool. Now it's time to retire it and look at the pictures of the grandkids. Thanks.

Re:The version after Perl 5 is Python

[chromatic]

I think you have a typo. Let me fix it for you:

... but [the equivalent in any language of] 10,000 lines of Perl is a mess unless you're a very disciplined programmer.

Assuming, as a rule of thumb, that a line of Perl is equivalent to ten lines of C, would you expect an undisciplined programmer to maintain 100,000 lines of C code with ease? Me neither.

The "there's more than one way to do it" is hell on maintenance programmers, because they have to know everything in the language to read code.

No, they only have to know the idioms used in the code to read that code.

Suppose you take a job as the Mandarin-to-English translator for a large set of documents. It helps if everyone wrote at a sixth-grade reading level. It helps if every writer used the same local dialect. It helps if you can read Mandarin. If none of those are true, you and your employer have a severe problem.

I don't see why programming is any different.

Re:Me too!

[singollo]

I realize there is a range of acceptable criticism within a community, and Perl has a community that is probably more inclusive than most. However, "show me the patch" is a bit of a cop out. Don't get me wrong; it is a defensable position, but a willingness dismiss everyone without a fix makes it more likely they will go elsewhere. Look at (Common) Lisp.

P.S.
I love Perl and Lisp, but people tend to get defensive about sore spots. I sometimes think that it would have been easier on everyone to introduce Perl 6 as "concept car", rather than an upgrade path.