Slashdot Mirror
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."
Great, so Perl 6 is legal now. Any chance of seeing her while we still have our youth?
You can start programming in Perl 6 today using Pugs.
-- Ed Avis ed@membled.com
To know what Perl 6 will be like, read the Synopses.
My own reaction was more like, wow this guy really is nuts, but I really want to see what he'll manage to come up with. :-) (and I say that as a professional Perl programmer...)
I believe posters are recognized by their sig. So I made one.
This is all nice, but where's the podcast?
8 of 13 people found this answer helpful. Did you?
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.
"Microsoft killed my company, I hold a personal grudge. I don't use Microsoft products and neither should you."-JWZ
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.
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?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
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.
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."