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."

Re:Summary

[NickFortune]

I was disappointed. Larry usually does a better job of connecting the off topic stuff pack to Perl. This time he had maybe five or six puns and that was about it. The main thing I took away from it was the big slides with whatever. That and the theme of "learning not to care"

It all read to me as if he's disengaging himself from the Perl development process and looking forward to spending more time on Real Life. Good luck to him, if so; he's surely earned some time off to spend with his family.

Pity about the speech though.

Re:Larry is boring

[melonman]

The large square panels are presumably slides from his live presentation. They aren't supposed to stand alone, in fact I suspect that the whole presentation would make (as much) sense without any of them.

Personally, I find Wall's prose simply wonderful: I've been known to read entire chapters of the Camel book just for the asides. I think that to judge this presentation you have to imagine the equivalent speech about "the future of typing in C++" or "the evolution of the object model in java" and ask yourself if anyone would be awake by the end of page one. Wall is one of the few people I've come across who stands far enough back to get beyond "Side Effects Good/Bad", "Parentheses Good/Bad", "Strict Typing Good/Bad" and so on.

And at least the man does seem to have a nodding acquaintance with other languages. Try Learning Java [google.fr] for the other approach, where the opening chapters compare Java with other languages, and point to several weaknesses or omissions in perl. Unfortunately, perl does all the things the author thinks it doesn't, and it did some of them before Java had crawled out of the C.

Death Valley

[kahei]

There's a certain stage, for some projects, at which people realize that the Great Next Version, if it ever comes, will be too little too late, and that the action has moved elsewhere. For Perl that was 3-5 years ago. For Ruby, 2-4 years ago. For countless non-public projects, it happens; gradually, progress meetings become a bit of a joke, the smart staff get moved elsewhere, and Project Star (there's nearly always a project called 'Star') becomes something that still exists on someone's budget, but which nobody really expects to have to pay attention to. Sometimes there's a meeting about it and a status report tha reads like a State of the Onion; a bit of waffle, a few in-jokes, some words of encouragement, and then back to doing something else.

Sometimes, this does _not_ happen. Vista (which by rights should have entered the Death Valley last year) and Java (which should have entered it after 1.2) manage to escape this fate; disappointment after disappointment they somehow stay in the spotlight, stay relevant in hearts and minds.

The question is what to do with a project in Death Valley. In a company, someone usually eventually rolls out _something_ and declares victory so that everyone can forget about it. In open source, though, they _never_ administer the final blow. Look at CVS -- it's been in Death Valley for so long, people are beginning to think that _Subversion_ is old hat! Sure, people _use_ it, if they haven't moved on to something else yet, but the last interesting CVS news item was probably in the late 90s... and yet it jogs along... and now Perl jogs along beside it, in the gated retirement community of Open Source.

I'm not saying it's a bad thing, but it is a definite difference between OS and commercial software; you get far more resources spent on the 'long tail' of a project's life in OS.

6 - compelling reason?

[scottsk]

What Perl 6 needs, and I haven't seen yet, is a compelling reason to switch. It may be better under the covers, but Perl 5 works great from a user's perspective. In fact, I've been using 4 and 5 over the past decade and a half, since '91, to craft almost everything. It's part of my nervous system. I've internalized it.

So why would I switch to Perl 6? I'm just not hearing compelling reasons other than they've randomly changed a bunch of stuff so what I know doesn't work anymore or isn't optimal. The installed base of Perl 5 users is Perl 6's biggest enemy.

This would be like changing vi keys to make them conform to the CUA standard or Emacs - it might be progress, but people are used to vi qua vi in its historical form and don't want progress because the standard keys are in their nervous systems now.

Re:Death Valley

[Anonymous Brave Guy]

You seem to equate a project that is no longer being significantly or quickly developed with a project that is pointless. Some of us would call tools like Perl 5 and CVS "tried and tested", "stable and reliable", or perhaps even "established standards".

Now, me, I've followed Perl 6 development from a safe distance, reading the odd article here and there, but not spending too much time on all the details. I get the feeling that it's going to be too complicated to be worth the effort to switch, but I'll reserve judgement until there's a stable, polished implementation to experiment with.

However, that didn't stop me using Perl 5 to develop a whole load of scripts to drive a new database system I was writing last weekend, or for that matter to write a couple of 50-liners to process some diagnostic output from the app I'm developing at work yesterday. I don't care that I didn't use the latest AJAXified web 2.0 technologies; I had a job to do, and Perl 5 let me do it quickly and correctly, which is all I ask of a programming tool.

Incidentally, if Perl had its day 3-5 years ago, and Ruby 2-4 years ago, what do you think are the cutting edge programming languages of today?

Re: Summary

[jonadab]

> 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.

Ah. What you've missed is that this is Larry's State of the Onion speech. If you want to see details such as how Perl6 will respond to certain challenges, what paradigms the language supports and how it supports them, and so on, you subscribe to the mailing lists or at least read the Synopses. If you just want to be entertained for a few minutes, you listen to the annual State of the Onion.

good summary

[oohshiny]

Sadly, I think that photo essay just about sums up the state of Perl these days.

Hint: pictures of the grandkids is not what people with deliverables and deadlines want to see.

(I probably started using Perl more than 15 years ago. Perl was the best thing since sliced bread then, because it provided a cleaner and easier to use alternative to writing scripts in combinations of shell, awk, sed, tr, and a few other command line tools.)

Dream on

[joe_n_bloe]

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.

Having worked in a production environment where hundreds of thousands of lines of Perl written by fewer than 50 developers have run with extreme reliability 24x7 for years, supporting a company of tens of thousands of employees worldwide, I feel confident in saying "you have no idea what you're talking about."