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?
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.
// MD_Update(&m,buf,j);
You can start programming in Perl 6 today using Pugs.
-- Ed Avis ed@membled.com
For example, here's two choice quotes from the Perl 6 operators page.
Hypocrisy in action, folks.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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.
What I would really REALLY like to come with Perl isn't about the language itself, but about the tools.
Perl has a really nice debugger, but you can't use it for debugging scripted web pages. There are solutions, but mostly they're not provided with the standard Linux distributions. I'd like some sort of online solution that doesn't require lots of configuration.
8 of 13 people found this answer helpful. Did you?
Honestly, if I plugged my mouse into the keyboard port and spat the input into a text editor, it'd look like Perl. I know that's an incredibly immature way of looking at a language but, dammit, even Assembly is prettier! Should that really be the case?
(Disclaimer: this is not a comment on Perl's functionality.)
Meta will eat itself
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
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.
Whence? Hence. Whither? Thither.
This was a joking target in the development process for Perl6. It seems Larry will finally archive this goal even if he probably never intended. Larry changed Perl from 5 to 6 in a way too many people got sick and stayed with Perl5. Essentially there are now two distinct Perl dialects which will hamper it's success so there won't be a reason for passing the 2 time Pi limit.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
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.
I'm completely on board with this attitude.
I **LOVE** Perl 5. It is, without question, the most useful and most powerful programming language I have ever encountered, and that includes C, C++, various assemblers, Pascal, FORTRAN, Java, REXX, Ada, Python... all the languages of the week. I keep coming back to perl because it is so damn useful and because it is so elegant (when used correctly - bad perl is really, really bad).
My productivity would be a tenth what it is today if not for perl. I use it for everything from quick and dirty hacks all the way to major enterprise support applications.
And I've seen Larry give "State of the Onion" presentations before, in person - and he's brilliant. Perl5 is the masterpiece of a genius.
But Perl6... I don't get it. It seems like so much has been changed, just for the sake of change. If Perl5 is English, then Perl6 feels like Esperanto.
I see no compelling reason to ever switch to 6 from 5 - unlike the switch from 4 to 5, which added a ton of real improvements.
DG
Want to learn about race cars? Read my Book
Perl has had its day. It was something special a few years back when it was seemingly the first big, really usable, dynamic scripting language. I think it could have had a future, if they hadn't gone into this whole Perl 6 fiasco. I mean, I can't see how anyone is going to wait around for... what... 4 years or something now, and it's still not generally available?! Plus, most businesses have never been big on adopting new technology which Perl 6 will be, so even once they release it it'll probably be 2 to 3 years before there's much chance of seeing it in the wild. Meanwhile, Ruby and Python have been moving along and gaining all of the Perl dropouts. I gave up on Perl about the minute they started with Perl 6. Man am I glad I did. I couldn't stand the thought of programming in a language that was guaranteed to be replaced (Perl 5) while waiting years for something that may or may not be better (Perl 6) but that would certainly be different enough to cause me to have to relearn things and port my old stuff.
And here is the draft cover of the Perl 6 book
Nick Ing-Simmons Dies
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.)
Okay, it looks like /. strips stuff out of plain old text. Let's try this again using (LT) and (GT) instead of the less than and greater than markups:
open FILE, "(LT)$ARGV[0]";
print (LT)FILE(GT);
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.
Parrot will be much faster than Perl5 is now, and you will be able to run all your old Perl5 code with Ponie.
Parrot may also become the standard VM for "dynamic" languages, like Python and Ruby, and there are already many implementations of many languages running on Parrot.
This means that you can learn Perl6 slowly, and only use it for new code, and delay rewriting your old code for as long as possible. But there are many other reasons Perl6 will be not just good, but amazing, if I'm to believe what arodland is saying.
Don't thank God, thank a doctor!
That sounds reasonable, however because perl is so flexible the intent of a programmer
is much more difficult to decipher because there are so many ways of accomplishing the same thing. It truly lends itself to spagghetti code in a way other languages don't.
I wish that weren't the case. It's definitely possible to write good, maintainable perl. But it's the exception, not the rule. 10000 lines of the average perl program are much harder to read than the equivalent in e.g. python.
Just my experience.
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."