Posted
by
CowboyNeal
on Friday September 29, 2006 @02:05AM
from the that-time-of-year dept.

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

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.

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.

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

As a Perl programmer, I have to ask: why? I don't want Pugs, I want Perl 6! The last thing I need is another language to clutter things up. I'm not going to go about converting Perl 5 scripts to Pugs then having to convert them over to Perl 6. Or is LW going to wave a magic wand one day and Pugs will magically transmogrify into Perl 6? I love Perl, I really do -- it's the Swiss Army knife of languages, good for just about anything you can think of. Whether there is a Perl 6 in the future is really irrelevan

Umm... what? Pugs is an attempt at a reference implementation of... Perl 6. If you write code and it runs in Pugs, then it should run in any other Perl 6 implementation. Unless, that is, I'm missing something...

Well I can be just as pedantic as you if you will; stack-based 'structs' (perl arrays and hashes) don't use dots at all; they're indexed by [] and {}, respectively. 'heap-based' structs (pointers) _do_ use '->' and are mirrored perfectly adequately in perl with the use of the same operator for references. So there.

He's saying that they're changing one bit of syntax to conform with what people are used to in other languages while totally corrupting something else that was perfectly consistent with what everyone else already knew.

a person who acts in contradiction to his or her stated beliefs or feelings"

i.e. saying "-> becomes., like the rest of the world uses." and then changing the ternary operator from something everyone else uses to something completely different.

Changing -> to . has other repercussions, too. In case you'd forgotten, "." was already used for concatenation. So, now concatenation now becomes "~". But wait, ~ was already used to bind scalars to a p

Fine, but by that definition everything in the design a programming language is arbitrary, so that's a fairly useless description. I thought you meant the capricious or random definition, which (while incorrect in this case) actually means something in context.

The basic problem is that the old ?: operator wastes two very useful single characters for an operator that is not used often enough to justify the waste of two characters. It's bad Huffman coding, in other words. Every proposed use of colon in the RFCs conflicted with the ?: operator. I think that says something.

If you haven't been keeping up, one of Larry's basic premises in Perl 6 is to improve the "Huffman coding [wikipedia.org]" of the language: things that people use every day shoul

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

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 yours

If $_ is behaving in an unexpected way, I use variable names. K&R is almost completely useless IMO because it hardly mentions any of the optional extras like, um, input and output. If you want to implement encryption, K&R gives you a totally generic and unbelievably low-level set of tools to do it with. The Camel book points you to CPAN. The difference is best measured in man-months...

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.

It's really touching, all that stuff about raising a family that he goes into, but (while Heidi might be strangely attractive) does he realise how ugly his kids might be? Course not, he's a father.

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?

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.

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.

Well, to play devils advocate, how often do you find yourself using the terniary operator or bitshifting in Perl? What if you could, instead, leverage those tokens for other, more commonly used op

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.

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

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?

Hm, well, I don't really like cutting edge things, because I'm very lazy, and because so many things go from 'cutting edge' to 'dead' with no in-between. But in terms of where the interesting effort is going, I personally tend to think:PHP -- I know, I know. But there's a great deal of interesting webby work happening in it, especially if you like CMSes / knowledge sharing tools.

C# -- Tons of stuff going on, a very powerful platform that is only just beginning to be explored, and then of course the fact t

I feel like repeating my previous comment. Who says PHP is dead? That same database system I mentioned before has to provide some web access. After looking at the available options, it made far more sense to code that up using PHP than using "pure CGI" with a language like Perl. Again, it may not be the flashiest language on the planet, but it got the job done efficiently and effectively.

Who said anything about "pure CGI"? If you could do it in PHP, you could have done it in half the number of developer-hours with Jifty or Rails or that Django thing, or you could have done it more powerfully and reliably with Catalyst or Struts, or... whatever. PHP isn't an efficient or effective solution to the problem -- any problem really, when compared to other tools that are available; it survives because people are under the misapprehension that it is.:)

Your implicit assumption is that I am incompetent. I suggest to you, with no malice intended, that you will gain more from your experiences on boards like this if you seek to find out someone's level of competence before judging them.

In fact, our entire web site is already generated using a customised, home-grown framework based on XML/XSLT and standard scripting tools, which serves our needs far better than any of the cookie-cutter frameworks you mentioned. All we needed was a way to drop a quick databas

How does your level of competence enter into anything that I said at all? Why should I care whether you invented the internet or you're a complete idiot? I wasn't discussing you. I was discussing programming problems and solutions. Although I do wonder a little bit how your system could be so good and not support having a little data-driven table dropped into the middle of an existing application.:)

How does your level of competence enter into anything that I said at all? [...] I wasn't discussing you.

I'm sorry. When you wrote:

If you could do it in PHP, you could have done it in half the number of developer-hours with Jifty or Rails or that Django thing, or you could have done it more powerfully and reliably with Catalyst or Struts, or... whatever.

in response to my personal example involving PHP, I assumed that you were in the same conversation as the rest of us. As I have explained, I most c

COBOL... lessee, you're a bank shuffling billions of dollars around every day, reconciling accounts after business has closed. You've got a pile of 30-year-old continuously maintained COBOL doing the shuffling and adding up those BCD dollar and cents.

And then a whizzkid from down the corridor in the website support office suggests you abandon all that working, time-tested code and rewrite it all in some open-source incredibly cryptic code that looks like line-noise, that doesn't support native BCD, that...

COBOL was designed around the flawed idea that programming languages should be similar to natural languages. This, of course, makes about as much sense as the idea that computer mice should be similar to the kind of mice that nibble on cheese.I agree that you need some kind of fixed-point representation for dollars and cents. In any civilized language, you would simply create a class that handles fixed-point math, and use that wherever you need fixed-point math. There isn't really any need for BCD-- it's ju

I like your description of "the gated retirement community of open source." There are definitely some projects that seem to fade away. Sometimes this is because the developers move on, and sometimes progress just seems to grind to a halt.Don't underestimate the inertia of established technologies, though. Some people are still using some variant of FORTRAN, the original compiled language developed in the 50s. Other organizations got stuck at the COBOL stage. There's still a small market for VAX gurus, VMS p

Firefox replaced it (from part of the same codebase - and note the JWZ doesn't say the code was bad) arguably precisely because they did exactly what JWZ says mozilla should have done and didn't - ie. shipped product early and often.

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.

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 ever

Actually, I think Perl6 will ultimately be a much better language in which to design large systems. It's object system is much more powerful (with Roles, which as I understand it act like a combination of interfaces and mixins), which will make it easier to build more modular software (P5's package system is useable, but let's face it, it's not particularly clean). Plus, things like optionally stricter typing and DBC-like functionality mean (hopefully) fewer bugs.Additionally, P6 expands Perl's functional

...with Roles, which as I understand it act like a combination of interfaces and mixins...

That's not really it. Mixins and interfaces are cut-down, minimal, crippled implementations of roles. A role-based system offers both mixins and interfaces trivially, but mixins or interfaces offer poor emulations of roles. Does that make more sense?

Actually, I think Perl6 will ultimately be a much better language in which to design large systems.

The problem is that people who think that Perl is not good for designing large systems have long since moved on to other languages. People who think that Perl5 is great as is are not going to like the Perl6 features. So Perl6 ends up pleasing nobody.

Perl5 serves a useful niche. I still reach for it when I want to code up something quick and dirty. The Perl development community should have focused

The Perl development community has welcomed patches for nearly 19 years now. I believe you forgot to preface your humble opinion with "In my humble opinion as a non-contributor and someone who has used the work of hundreds of contributors (who know much better than me and thus may very well be in very good positions to disagree with my humble opinion) for many years for free...."

(Being one of those hundreds of contributors, I laugh when you say "simple" an

How frequent is it? I could come up with a whole article full of criticisms of Perl 5's design and implementation (What is Perl 6 [perl.com] is a start). I wouldn't have seen everything Larry has seen, for example, but he's a lot better at designing languages than I am.

My experience is that a lot of project have wishlists with big and small items. Granted, the big items tend not to be radical rethinkings (as in the case of Perl 6), but I'm not sure it's as insular as you might think.

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 P

I don't mean to say that the only acceptable form of contribution is a patch. A bug report, a test, a question for the FAQ, a helpful answer on a mailing list or forum, a piece of documentation, an article, a tutorial, a book, or anything else constructive is absolutely fine.

Complaining in a completely unrelated forum without any apparent understanding of the issues or willingness to be a part of the community (by contributing anything) is completely useless. I don't see why the people who do contribute

Me too,:-)I use Perl 5 mainly for quick and dirty scripts. Most of the time I find a good CPAN module to begin with. I won't use it for large scale projects. I find rather difficult for Object oriented programming. I tried it on a middle-size project. the Bless thing is difficult to understand. The syntax is too weird for me. This part of perl5 looks more like hack than an useful and an efficient tool. I find it extremely difficult to track bugs during the development process for example.

Context: I've been professionally programming Perl for years now. I prefer Python.If you try Python again, and try to find ways of using the extra features it has that Perl either doesn't have, or are borderline impossible to effectively use, you'll actually get a better understanding of some of the value of Perl 6. Perl 6, at least on the feature checklist, will blow past Python if it manages to come out reasonably soon. (Whether or not it will be more useful remains to be seen, but I'm comfortably open-mi

I like the idea of implementing iterators in Perl, but you may be short-changing their usefulness. Look at the following script:open FILE, ";

When an iterator(filehandle in this case) is evaluated in list context, in this case the context is "print LIST", it will iterate until exhausted and return a list. So this should print out the entire file whose name is passed in as the first argument. So, as you can see, an iterable object can be passed easily as a list. I hope that points you in the right direction

In other words, you can't pass that iterator around. Instead, Perl expands it fully into a list, and passes the list around.That's not passing an iterator, that's passing a list. Perl turns it into a list at the earliest available opportunity because nothing can handle getting an iterator. One of the key characteristics of an iterator is that it doesn't suck the entire file into memory all at once, even if you pass it into something else.

To the best of my knowledge, you just can't quite get to Python cleanl

OK, that's what I get for taking people's examples at face value and not checking them.I've played around a bit more and found that while (my $val = <@something>) mostly does what I'm looking for, but I'm still not seeing an obvious way to take <@something> and get a reference to that iterator that I can pass somewhere else through syntax, rather than wrapping it in my ArrayIterator blessed-scalar class. Which means I still can't see a clean way to write a function to take an array or an iterato

... there's a fundamental disconnect between "arrays" and "iterators" that is just barely enough to keep you from using one as the other routinely, which is what you need for extensive library support.

You're right about that. It's probably too late to fix that in Perl 5, though that does give me an idea.

I'd sing your praises and be happy to be wrong.I'll freely admit that I haven't thought the whole thing through and I'm not a language designer, but I'd submit having <> working on references to arrays the same way that it does on normal arrays would get me at least most of the way there, allowing me to pass a scalar that provides an overloaded <> or a ref to an array and have the behavior flattened. Currently, that's a "Not a GLOB reference" error.

Well... there's the lazy evaluation and autolambda stuff that lets us steal some more of the best tricks from the functional programmers. There's the junctioning and type inferencing stuff that opens up something vaguely like logic programming. There's the OO and metaclass stuff that gives you a consistent object model, roles, multimethods, contract programming... the ability to have stricture like the Java folks do (Perl 5 offers a good number of opportunities to impose stricture, but when it comes to OO,

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 arodla

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

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.

And so what exactly became a cleaner and easier to use alternative to writing scripts in combinations of shell, awk, sed, tr, and a few other commandline tools?

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.

Programming is different. Your example of needing to know local and dialectical idioms is misleading, because programming language idioms are more abstract and harder to learn than natural language idioms. (I assume you didn't intend the more general use of the word "idiom.")

A natural language idiom is essentially an item of vocabulary. "Flying off the handle" is a natural language idiom idiom; it is complete and includes no new systematic way to vary its meaning. A programming language idiom has any

Your example of needing to know local and dialectical idioms is misleading...

Perhaps I was a bit unclear. I didn't mean only the idioms of the language, but also the idioms of the problem domain. I'd make a terrible programmer for insurance or payroll software because I've never worked in either industry.

That's something no language can completely solve, and yet another thing that depends on the discipline and standards of the entire team who created and maintains the software.

I know a lot more about perl and about python, but I've just spent half an hour looking around, and I can't find anything remotely resembling CPAN, which seems like one extremely good reason to stick with Perl. The nearest I can find is a static list of modules on the python.org site that, in total, is about a tenth the length of the CPAN list of XML-related modules alone.

CPAN is another reason why your "10,000 lines of code" thing doesn't work. Larry Wall's "laziness" principle says that you use other peo

10,000 lines of Perl is a mess unless you're a very disciplined programmeryou say that like 10K of undisciplines anything isn't, I know people who can turn 1,000 lines of COBOL into a mess. Programmer discipline isn't a function of the language used.

That sounds reasonable, however because perl is so flexible the intent of a programmeris 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.

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

Ruby and Python have the same problem Perl5 does. Not that they will be replaced, but that after their one, big innovation, they aren't really going anywhere.

Ruby, for instance, still doesn't have a bytecode engine, much less real compilation. I thought it was beautiful, but the beauty is skin-deep -- it's a bastardization of lisp in perl's clothing. I haven't looked at Python in awhile, but I'm guessing, in terms of power and readability: perl5 < python < ruby < perl6.