Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Perl's State of the Onion 10

CowboyNeal posted about 8 years ago | from the that-time-of-year dept.

126

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

cancel ×

126 comments

Sorry! There are no comments related to the filter you selected.

Legal, is she? (3, Funny)

Qa1 (592969) | about 8 years ago | (#16242027)

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?

Re:Legal, is she? (5, Funny)

Anonymous Coward | about 8 years ago | (#16242111)

Perl just turned legal? Great. Perl has been fucking me for the last 10 years, and now I hear this. Honestly, Larry told me that she was 35! I didn't know.

Re:Legal, is she? (1)

RuBLed (995686) | about 8 years ago | (#16242145)

It's like a SIMONE [imdb.com] thing. Besides do you think Larry would do that favor for slashdotters considering our current reputation of... oh nevermind...

summary: (-1, Offtopic)

larry bagina (561269) | about 8 years ago | (#16242045)

Heidi is now a MILF.

Re:summary: (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#16242239)

hahaha

your nick rhymes with... gary zagyna!

aahahahahhahaahahahaha :'-}

Guys... (-1)

Anonymous Coward | about 8 years ago | (#16242073)

This is rilly boring. Someone submit something interesting

Summary (2, Interesting)

kestasjk (933987) | about 8 years ago | (#16242147)

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.

Re:Summary (3, Informative)

Scarblac (122480) | about 8 years ago | (#16242367)

To know what Perl 6 will be like, read the Synopses [perl.org] .

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

Re:Summary (2, Insightful)

NickFortune (613926) | about 8 years ago | (#16242479)

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: Summary (2, Insightful)

jonadab (583620) | about 8 years ago | (#16243695)

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

More useful stuff about Perl 6 (4, Informative)

Ed Avis (5917) | about 8 years ago | (#16242301)

You can start programming in Perl 6 today using Pugs [pugscode.org] .

Re:More useful stuff about Perl 6 (1)

Billosaur (927319) | about 8 years ago | (#16243701)

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 irrelevant because I bet I'll be maintaining the vast abundance of Perl 5 code for many years to come before most places even think of converting.

Re:More useful stuff about Perl 6 (1)

Abcd1234 (188840) | about 8 years ago | (#16243921)

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

Re:More useful stuff about Perl 6 (1)

dkf (304284) | about 8 years ago | (#16244041)

I've also always regarded Perl as the swiss [swissarmy.com] army [wenger-knife.ch] knife [swissarmy.com] of scripting languages too.

Re:More useful stuff about Perl 6 (1)

arodland (127775) | about 8 years ago | (#16245833)

Your statement is akin to "I don't want gcc! I want C! You expect me to write my programs for this free gcc crap? What, will RMS just wave a wand someday and gcc will be C?"

Perl 6 might be great... not. (2, Informative)

VGPowerlord (621254) | about 8 years ago | (#16242365)

Perl 6 may be great. However, having read some of the docs, I don't think so.

For example, here's two choice quotes from the Perl 6 operators [perl.org] page.
  • -> becomes ., like the rest of the world uses.
  • The ? : conditional operator becomes ?? !!.

Hypocrisy in action, folks.

Re:Perl 6 might be great... not. (1)

bytesex (112972) | about 8 years ago | (#16242873)

-> becomes ., like the rest of the world uses.

I don't get it - the rest of the world doesn't use C or C++ ? Is that what you're saying ?

Re:Perl 6 might be great... not. (1)

revlayle (964221) | about 8 years ago | (#16244307)

only for a pointer to a class instance/struct. for straight up heap-based class and struct expressions... we still use "."... a LOT

Re:Perl 6 might be great... not. (1)

bytesex (112972) | about 8 years ago | (#16248625)

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.

Re:Perl 6 might be great... not. (1)

osgeek (239988) | about 8 years ago | (#16248151)

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.

Re:Perl 6 might be great... not. (5, Interesting)

grinder (825) | about 8 years ago | (#16243541)

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.

Re:Perl 6 might be great... not. (1)

Scaba (183684) | about 8 years ago | (#16246317)

Hypocricy? I don't think this word means what you think it means.

Hypocrisy? I don't think this word is spelled like you think it's spelled.

Re:Perl 6 might be great... not. (1)

VGPowerlord (621254) | about 8 years ago | (#16249553)

The Merriam-Webster definition for hypocrite [m-w.com] puts it best:
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 pattern match. So those now change from =~ and !~ to ~~ and !~~.

I really doubt that the Huffman Compression principle states that changing one operator should change two other frequently used operators simply because "the rest of the world" uses said operator.

It also strikes me as a really stupid idea to arbitrarily change operators people already to something completely different between versions of a programming language. I've never seen it done before Perl 6. Have you?

Re:Perl 6 might be great... not. (1)

chromatic (9471) | about 8 years ago | (#16249653)

It also strikes me as a really stupid idea to arbitrarily change operators...

Good thing it's not arbitrary then.

Re:Perl 6 might be great... not. (1)

VGPowerlord (621254) | about 8 years ago | (#16249745)

3 a : based on or determined by individual preference or convenience rather than by necessity or the intrinsic nature of something
So, yes, arbitrary [m-w.com] .

Re:Perl 6 might be great... not. (1)

chromatic (9471) | about 8 years ago | (#16250559)

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.

Re:Perl 6 might be great... not. (0)

Anonymous Coward | about 8 years ago | (#16243753)

Perhaps you don't like those operators, but it's hardly a fundamental language issue. It's not something that could make a language "good" or "bad" at any rate.

Re:Perl 6 might be great... not. (0)

Anonymous Coward | about 8 years ago | (#16245105)

-> becomes ., like the rest of the world uses.
-> is the infix dereference operator, btw.

And no, not all the world uses . or -> to access object members. I'm using generic functions [gigamonkeys.com] with method specialization. Dispatch on more than one argument, baby!

Re:Perl 6 might be great... not. (1)

I Like Pudding (323363) | about 8 years ago | (#16247515)

> The ? : conditional operator becomes ?? !!.
> Hypocrisy in action, folks.

I agree. The new ternary syntax is going to be easily confused with the ORLY?? and OMG!! operators.

Re:Perl 6 might be great... not. (1)

CTachyon (412849) | about 8 years ago | (#16248425)

To quote Larry in Apocalypse 3 [perl.com] :

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 should be easy to type, and things that people use infrequently should be harder to type. There's only a finite number of punctuation marks to use for operators, so something has to give.

For instance, the change from -> to . is a big win because method calls are heavily used. The change will save a bit of typing, cut down on typos (>-, -. and the like), and help the C++ and Java refugees figure out what's going on. However, in the process it ousts the string concatenation operator, which gets stuck playing musical punctuation since it's not as frequently used.

Similarly, the change from (?:...) to [...] is a big win. In a regex, non-capture grouping is an extremely common operation, but it looks like line noise in Perl 5. You can just use plain parens to create capture groupings, which are easier to type and read, but now your regex uses more memory to run and might take much, much longer to run. (We're talking about optimizations that can cut match time from days to seconds in some extreme cases. Captures don't actually fit very well into the finite automaton model that underlies the regex.) In comparison, while character ranges are still occasionally useful, they're going out of fashion thanks to Unicode, and they're hogging some valuable punctuation real estate. The change from [A-Z] to <[A-Z]> or <Upper> [perl.com] , while breaking compatibility in a major way and making character ranges less handy, frees up some punctuation to make other things more handy (and gets rid of the ugly \p{Property} construct to boot).

Finally, to address your main complaint, the change from a ? b : c to a ?? b :: c frees up both the question mark (possibly for a new boolean cast operator) and the colon ("Larry's First Law of Language Redesign: Everyone wants the colon") while making an ugly and infrequently used operator look more visually distinctive and less confusing to read. That's a huge win in my book. It's not hypocrisy; it's what Larry's been promising all along for Perl 6.

This may sound like a troll, but... (-1)

Anonymous Coward | about 8 years ago | (#16242493)

seeing this disjointed, random rant about everything and anything explains a whole lot about the mess of a "language" (in reality, a glorified regular expression parser shotgun-wed to a scripting shell like BASH). The whole article is just the rantings of a crazy man.

"Anonymous cowards like the "told you so" part as long as it doesn't include the "I." Anonymous cowards don't have an "I," by definition."

Told you so.

Re:This may sound like a troll, but... (-1, Troll)

Anonymous Coward | about 8 years ago | (#16242695)

Yay, perl-loving mods hate me now. Good. Take your line-noise "language" and go away, and come back when you grow up enough to use a real language.

You heard me.

IAWTP [nt] (1)

James A. V. Joyce (798462) | about 8 years ago | (#16243167)

I'm listening to the motherfucking DOORS

Larry is boring (2, Interesting)

Eivind (15695) | about 8 years ago | (#16242547)

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 (2, Insightful)

melonman (608440) | about 8 years ago | (#16242609)

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.

Re:Larry is boring (0)

Anonymous Coward | about 8 years ago | (#16243307)

've been known to read entire chapters of the Camel book just for the asides

I'm sure if you read it just for the asides it's wonderfully entertaining. However, when you've inadvertantly shot yourself in the foot for the fifth time that day, you're looking at something representing random characters, and you try reading it just to find out what the fuck is going on, the jokes become a lot less funny. If $_ is behaving in an unexpected way, Bilbo Baggins' family tree is the last thing on your mind. In a situation like that, something like K&R C is exactly what you want.

Every time I think about Perl, I thank my lucky stars I don't use it any more.

Re:Larry is boring (1)

melonman (608440) | about 8 years ago | (#16246869)

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

Re:Larry is boring (1)

jerald_hams (725369) | about 8 years ago | (#16244805)

Come on: "Here's a mommy and a daddy truck. They live on a truck farm, and raise little trucks." You don't think this is adorably funny.

Anyways, I'm sure Perl is also quite happy that you left.

Re:Larry is boring (0)

Anonymous Coward | about 8 years ago | (#16245731)

Come on: "Here's a mommy and a daddy truck. They live on a truck farm, and raise little trucks." You don't think this is adorably funny.

Dude...if that's your idea of funny, then you really need to get out more.

Re:Larry is boring (2, Interesting)

mrsbrisby (60242) | about 8 years ago | (#16249807)

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.

Debugging (2, Informative)

cerberusss (660701) | about 8 years ago | (#16242691)

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.

Perl is so damned ugly though (1)

tygerstripes (832644) | about 8 years ago | (#16242773)

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?

(Disclaimer: this is not a comment on Perl's functionality.)

Podcast (3, Funny)

cerberusss (660701) | about 8 years ago | (#16242819)

This is all nice, but where's the podcast?

Operator Error (4, Interesting)

Killer Eye (3711) | about 8 years ago | (#16242845)

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:Operator Error (1)

TheLink (130905) | about 8 years ago | (#16243619)

I'm actually waiting for parrot and ponie, not perl6. Then hopefully perl5 will run faster.

Unfortunately ponie seems to have got stuck or something.

Then if there are some things that perl5 doesn't do well, maybe you switch to perl6.

Or python ;).

Re:Operator Error (1)

ctzan (908029) | about 8 years ago | (#16247915)

ponie is officially dead [google.com]

Re:Operator Error (1)

Abcd1234 (188840) | about 8 years ago | (#16244037)

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 operations?

Yes, I understand this means Perl 6 requires a greater mindshift because it doesn't follow other languages and inherit C-like syntax. OTOH, who says C is the best? Why is '??!!' worse that '?:'? Heck, I would argue that '??!!' is easier to visually parse, because the character delimiters are very clear (searching for the ':' in a complex terniary expression can be a bit of a chore, depending on how nasty the original programmer was).

So I would hardly call this a "huge mistake". Will it be a bit annoying to adapt to? Sure. But learning new programming languages (even somewhat unusual ones) should be fairly easy for any experienced developer... it's just syntax, after all.

At least then, I will gain something for my trouble.

Well, ideally Perl 6 *will* be the superior language, though that remains to be seen...

Re:Operator Error (0)

Anonymous Coward | about 8 years ago | (#16246277)

I think Perl's decision to undefine decades-old comforts like the ternary operator (?:) and bit shifting () is a huge mistake.


Hear, hear! Why even use a ternary operator if the regular if-expression is enough?

(let* ((my-number 2)
              (result (if (equalp my-number 2)
                                      'foo
                                      'bar)))
    (format t "Hello ~A!~%" result))

Death Valley (2, Insightful)

kahei (466208) | about 8 years ago | (#16242895)


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.

Re:Death Valley (2, Interesting)

6031769 (829845) | about 8 years ago | (#16243039)

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:Death Valley (3, Insightful)

Anonymous Brave Guy (457657) | about 8 years ago | (#16243533)

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:Death Valley (1)

edremy (36408) | about 8 years ago | (#16245417)

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?

Visual Age COBOL [flexus.com] Get with the times man- everything old is new again.

Re:Death Valley (1)

kahei (466208) | about 8 years ago | (#16245491)


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 that so many projects are being ported to it and that 2.0 was so different from 1.1 tends to generate activity as well.

Java -- the language of academia -- so many algorithms are developed as Java and then repackaged or ported to other environments that Java continues to be the key place to look in a lot of disciplines.

C -- still your one stop shop for system programming.

C++ -- still your one stop shop for financial programming, game programming, and other areas where systems are both complex and performance critical, and also perhaps the language with the highest quality of technical software engineering being done in it (boost).

In other words, it's not the newest and most interesting languages that have interesting work done on them. It's the same old languages as ever. I guess the relative newcomer is C#.

I know what you mean about Perl5 vs Perl6 -- just because Perl6 is in Death Valley doesn't say anything bad about Perl5. All the same, I get the impression that PHP kind of stole Perl5's web crown at some point.

Re:Death Valley (-1, Troll)

arodland (127775) | about 8 years ago | (#16245939)

You're kidding, right? PHP is dead. It's just going to take a number of years before the people using it realize that. Nothing truly important is going to happen with PHP, because it's the wrong kind of lanaguage, with the wrong kind of community. Perl, Python, Ruby, even Java are non-toy languages with truly amazing web stuff going for them; PHP is for the kids, always has been, always will be -- even if some people are under the temporary delusion that it's more than that.

Re:Death Valley (1)

Anonymous Brave Guy (457657) | about 8 years ago | (#16247345)

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.

Re:Death Valley (1)

arodland (127775) | about 8 years ago | (#16252089)

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

Re:Death Valley (1)

Anonymous Brave Guy (457657) | about 8 years ago | (#16253881)

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 database-driven table into a web page, where the rest of the page is already generated by that existing framework. I did this in PHP in about five minutes, and two of those were modifying the build scripts to put .php files in the right place. I couldn't have achieved the same results with any of the other technologies you mentioned without (a) rewriting most of the system from scratch, and (b) learning more about one or another programming language with which I'm only passingly familiar at present.

Maybe PHP isn't an efficient or effective solution to any of your problems. That's fine, go ahead and use whatever tool is best in your circumstances. Maybe if we were designing our whole system from scratch, with no existing framework, we'd have chosen another option as well. But in our current circumstances, PHP was just what we needed: a simple way to embed a little database scripting into web pages that are already generated using our existing tools.

Re:Death Valley (1)

arodland (127775) | about 8 years ago | (#16254179)

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

Re:Death Valley (1)

Anonymous Brave Guy (457657) | about 8 years ago | (#16255123)

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 certainly could not have achieved the same results in half the number of developer-hours with any of those other tools, for at least two good reasons. Moreover, the project I mentioned is a simple counter-example to your general claim that PHP is not an efficient or effective solution to any problem.

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

I appreciate the smiley, but... It did support that. That's my point. For the avoidance of doubt, the SQL queries involved are the most complicated thing, well beyond the scope of the convenient one-liners typically offered by $TRENDY_FRAMEWORK. The few lines of PHP required in most of the pages to generate the various tables were about as simple as scripting gets, and slotted right in to the existing framework we had in place. Are you really arguing that it would have been more productive for me to recreate our entire existing database with a Rails-friendly schema, redesign an entire on-line, operational web site to use RoR conventions, translate all of our templates into suitable .rhtml files and the like, and then write essentially the same logic (SQL query/ies -> loop -> output table) in Ruby anyway? I'm good, but I'm not sure I could do that in five minutes.

Seriously, this kind of argument, and the kind of general "PHP sucks" statements you made elsewhere, don't sound like the thoughts of an objective observer who's interested in picking the right tool for the job. They're more like the rants of someone who once worked on a bad project and blames the tool, or the evangelism of someone so enthusiastic about his favourite framework that he sees it through rose-tinted glasses.

Re:Death Valley (1)

FrostedChaos (231468) | about 8 years ago | (#16249423)

Yeah, PHP is strictly worse than Perl.
PHP is "training wheels without the bike."

Unfortunately, bad programming languages never really die. Even COBOL is still leaving its trail of slime at some mega-corporations.

Re:Death Valley (2, Informative)

0xABADC0DA (867955) | about 8 years ago | (#16245953)

Smalltalk and LISP, obviously. Like Merlin, they were born fully formed and age backwards, getting more and more relevant as time passes.

Re:Death Valley (1)

Abcd1234 (188840) | about 8 years ago | (#16244065)

This could also be related to good ol' Second-system Syndrome [wikipedia.org] , of which I suspect Perl 6 is suffering, at least in part.

Re:Death Valley (1)

arodland (127775) | about 8 years ago | (#16247333)

No, Perl 1-4 was the First System. Perl 5 is the Second System. Perl 6 is the Third System.

Re:Death Valley (0)

Anonymous Coward | about 8 years ago | (#16244315)


FWIW, Mozilla was in that stage for quite a while. One of the founders of it quit [jwz.org] because they didn't ship on his imagined time frame.

They didn't get to Mozilla 1.0 until three years after that.

So, they should have just retired the product, right....?

Re:Death Valley (1)

mrsbrisby (60242) | about 8 years ago | (#16249399)

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.
Maybe. But exactly how much time passed between perl4 and perl5? How about if we talk creation (i.e. the ability to create code in the respective languages)?

It's amazing that people think we've been waiting for a while for Perl6. People have been writing in perl6 for a while, it just so happens that more still write in perl5. As it was, several years after perl5 showed up, we still saw perl4. I think that this better reflects where we are with Perl6.

Given however, that like perl5 was to perl4, perl6 is more so like perl5 than perl5 is, we likely will be able to treat perl6 as /usr/bin/perl - something people most certainly have not been able to do- even between what would otherwise appear to be a minor version (python2.2 scripts not running on a 2.3 or 2.4 interpreter, for example).

Best thing to do is not worry about it. If you want to say there's nothing to see here, then at least qualify it by pointing out there wasn't anything to see with perl5 either.

Re:Death Valley (1)

FrostedChaos (231468) | about 8 years ago | (#16249829)

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 programmers-- you name it. No doubt academics will be the last people to abandon Java. I expect a lot of perl 5 code will keep chugging along for years-- maybe even decades, hidden here and there in server rooms around the world. Hell, bash scripting is still around, and that's about the worst language ever-- even BASIC might be better.

Computer enthusiasts tend to evaluate computer technologies in terms of how productive they are. But to corporate leaders, often the only really important number is the cost of switching. As long as that is high enough, it's better to keep patching and duct-taping the stuff you've got, rather than putting out the money for a new system. It might take years to see the benefits from a new system, and corporate leaders are often under pressure to show short-term results.

As long as there is enough money behind projects, they will NEVER die, no matter how boneheaded they may be. The next version of Windows will NEVER "enter Death Valley," because Microsoft needs to release something new, to get that nice load of cash from product upgrades, and to justify charging OAMs the Windows tax. Here on slashdot, we know that Windows 2000, XP, and Vista, are really just the same OS, give or take some candy-coated graphics and bloatware. But most consumers just buy the latest thing.

People in the know, and smart businesses, know that there's certain products and technologies that are just deprecated for new development work. For example, why use CVS, when Subversion is all that and the bag of chips. Why use PHP, when it's just a broken subset of Perl. And why use Excel macros when you have... anything else. But to pointy-haired bosses, the world is a lot less clear.

Perl version should stay below 2 times Pi (1)

wysiwia (932559) | about 8 years ago | (#16243061)

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

6 - compelling reason? (5, Insightful)

scottsk (781208) | about 8 years ago | (#16243107)

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.

Me too! (1)

DG (989) | about 8 years ago | (#16243641)

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

Re:Me too! (1)

Abcd1234 (188840) | about 8 years ago | (#16244237)

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 capabilities, adding things like continuations, which could allow for Seaside/Rails-like webapp development.

Lastly, Perl6 could end up being one of the few mainstream languages with parallelization semantics defined right in it's core, which means all these multicore machines that are coming out could be more easily leveraged.

Re:Me too! (1)

chromatic (9471) | about 8 years ago | (#16248677)

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

Re:Me too! (1)

Raenex (947668) | about 8 years ago | (#16255115)

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 their efforts on refinements, not changing its identity. Simple stuff like moving more functionality into the standard library.

Re:Me too! (1)

chromatic (9471) | about 8 years ago | (#16255435)

The Perl development community should have...

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" and dare you to prove it.)

Re:Me too! (1)

Raenex (947668) | about 8 years ago | (#16255829)

I don't have humble opinions, and I don't avoid critiquing stuff even when I have not contributed. I'm sure you're no different.

Re:Me too! (1)

Evangelion (2145) | about 8 years ago | (#16244667)


There are some [perl.com] good explanations around about why they're rewriting perl.

FWIW, this is set of features that are being implemented in Perl 6 that Perl 5 lacks:

explicit strong typing
proper parameter lists
active metadata on values, variables, subroutines, and types
declarative classes with strong encapsulation
full OO exception handling
support for the concurrent use of multiple versions of a module
extensive introspection facilities (including of POD)
LL and LR grammars (including a built-in grammar for Perl 6 itself)
subroutine overloading
multiple dispatch
named arguments
a built-in switch statement
hierarchical construction and destruction
distributive method dispatch
method delegation
named regexes
overlapping and exhaustive regex matches within a string
named captures
parse-tree pruning
incremental regex matching against input streams
macros (that are implemented in Perl itself)
user-definable operators (from the full Unicode set)
chained comparisons [wikipedia.org]
a universally accessible aliasing mechanism
lexical exporting (via a cleaner, declarative syntax)
multimorphic equality tests
state variables
hypothetical variables [perl.com]
hyperoperators (i.e. vector processing)
function currying
junctions [perl.com] (i.e. superpositional values, subroutines, and types)
continuations [wikipedia.org]
coroutines [wikipedia.org]

Re:Me too! (1)

Jerf (17166) | about 8 years ago | (#16244813)

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-minded about that. Whether or not Python will also catch up in its own way, potentially before Perl 6 comes out, also remains to be seen; there has been longstanding interest in the Python world in many of the "optional static typing"-sort of things that Perl is adding, and Python will have the advantage of being able to see how Perl 6's design seems to be working out. Anyhow....)

Python generators seem like a gimmick until the day you write a useful generator that would be literally 5 times longer and more complicated without the generator support. In the latest Python, these have been updated to full co-routines (although it was already possible to do the same thing by making a generator out of a method of an instance, this is somewhat cleaner and the interface will be shared and that's good). I believe Perl will be picking up this feature and more.

Python's class system is a lot cleaner and I've found that once you wrap your head around metaclasses, they are a type of magic that can give a module an amazingly clean interface.

And one of my long-standing complaints about Perl is that its hashes can only use strings as keys; the ability to directly and fully use objects as keys is incredibly helpful. (I know there are some modules to try to fake that in Perl but they always seem to have dangerous "gotchas".)

The other nice thing that Perl 6 can offer that you can see in Python is simply that when these features are integrated and specified in the language, you can use them more fully to your advantage. You can write an iterator in Perl 5 and overload the <> operator to iterate on it, and I do. But libraries don't take iterators, they take "lists" or "hashes" or whatever. In Python, because the iterator support is built in, everything that in Perl would take a list for the purposes of iterating on it takes an iterator instead, which turns out to be incredibly flexible as you can now feed that function not merely an array, but an iterator that may pull things off the network, or feed it processed hash keys or values, or every process every node of a complicated data structure. (I've used that latter trick several times in a program with a tree-basis; create an iterator and specify the iterator's characteristics, then let the iterator worry about traversal while some other function does something to every node in the iterator, like save it to a file.)

Perl 6 should be able to do all of these things and more, and believe me, if it ever comes out it'll offer real value once you learn what's going on. Expect it to take probably a couple of years for the community to fully work out which patterns are the best.

In the meantime, Perl 6 is useless until it comes out. I hope it does, because it would definitely make my resume look a little more relevant.

Re:Me too! (1)

cerelib (903469) | about 8 years ago | (#16246645)

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. Context sensitivity is complicated, but it is what makes Perl especially powerful.

SORRY, FIXED CODE (1)

cerelib (903469) | about 8 years ago | (#16246767)

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

Re:Me too! (1)

Jerf (17166) | about 8 years ago | (#16247401)

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 cleanliness. In Python, "for x in y" implicitly calls "iter(y)", and iter() on something that is already an iterator returns the iterator itself. Thus, "for x on y" is actually pretty powerful. So far as I know, there is no equivalent Perl formulation, because you can write "for my $x (@TrueList)" or "while (my $x = <$MyIter>)", but there is no syntactic way to unify that into the Python equivalent without an explicit check or wrap. (And I have a "ArrayWrap" iterator that lets you write "while (my $x = <$ArrayIter>)", although if $x might be an "undef" that you want that gets tricky; Python has better support there, too.)

I'd accept "while (my $x = <$UnblessedArrayRef>)" and live with the undef issue (I can guarantee no undef until the iterator is exhausted), but that doesn't work. (Just checked.) In Python the equivalent is still "for x in y". If I want to pass something an iterator that may either come from a list or a DB query, I have to manually wrap the list. (And I do that pretty frequently.)

And since I have DB queries that may be large and I really, truly want to iterate, not pull the whole list down in memory (when the list is already in memory, I've either already guaranteed the list is short or already paid the price), I don't have the option of just blowing the thing out to an array.

Perl has iterator support, but it's much thinner than Python's, and surprisingly it's more a syntactical problem than a language capability problem.

Re:Me too! (1)

chromatic (9471) | about 8 years ago | (#16248721)

In other words, you can't pass that iterator around.

Indeed you can. You don't get the iterator as the return value from a read operation on the iterator, but who would expect that you do?

See the book Higher Order Perl for far more examples.

Re:Me too! (1)

Jerf (17166) | about 8 years ago | (#16249739)

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 iterator without writing a ref($it) eq 'ARRAY' check, which is still enough to keep libraries from supporting iterators in general, and the perl modules I'm seeing say that there hasn't been a consensus on what to do about this point, either.

It's the little things that add up; 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.

Re:Me too! (1)

chromatic (9471) | about 8 years ago | (#16249787)

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

Re:Me too! (1)

Jerf (17166) | about 8 years ago | (#16250037)

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.

Enough that I'd wipe off the language support part of the advantage, anyhow. (Libraries would take some time but that's inevitable.)

Re:6 - compelling reason? (1)

arodland (127775) | about 8 years ago | (#16247105)

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, it's all out the window. You can't enforce anything and if anything goes wrong, it will go wrong at runtime). Instead of regexes, you can use the new Rules system that's not only a zillion times more powerful, but also not complete punctuation soup, and a whole lot easier to write. What else am I forgetting? Plenty, I'm sure.

Speed. (1)

SanityInAnarchy (655584) | about 8 years ago | (#16252055)

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.

hopefully (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#16243435)

the final post

Perl is so 90s (0)

Anonymous Coward | about 8 years ago | (#16244657)

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.

Re:Perl is so 90s (1)

SanityInAnarchy (655584) | about 8 years ago | (#16252129)

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.

The book (1)

rduke15 (721841) | about 8 years ago | (#16245829)

And here is the draft cover of the Perl 6 book [alma.ch]

The _real_ perl news this week... (1)

prufrax (521403) | about 8 years ago | (#16245959)

Nick Ing-Simmons Dies [perlfoundation.org]

good summary (2, Insightful)

oohshiny (998054) | about 8 years ago | (#16246147)

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

Re:good summary (1)

mrsbrisby (60242) | about 8 years ago | (#16249303)

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?

Re:good summary (1)

oohshiny (998054) | about 8 years ago | (#16255299)

There half a dozen mature, widely used post-Perl scripting languages; take your pick.

The version after Perl 5 is Python (4, Interesting)

Animats (122034) | about 8 years ago | (#16247813)

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 (2, Interesting)

chromatic (9471) | about 8 years ago | (#16248775)

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:The version after Perl 5 is Python (1)

try_anything (880404) | about 8 years ago | (#16255035)

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 number of opportunities for parameterization and may require learning new language concepts that were not necessary to understand before. So the difference is between learning syntax (and language features) and learning vocabulary. With that established, I think there are three drawbacks to having such a rich set of language syntax and features that users consistently find themselves confronted with novel "idioms":

First, syntax and features are harder to learn than vocabulary. Vocabulary is provided in lists for memorization; grammar is described at great length (or defined mathematically) and cannot simply be memorized in bulk. Learning new syntax requires establishing a new habit of thought, which must be practiced and reinforced before it can be used naturally. New vocabulary items (classes, functions) are just as easily forgotten but much more quickly grasped. (That is, unless the language requires the use of mind-bending vocabulary, like Haskell Monads.)

Second, language syntax or vocabulary can be designed for straightforwardness and quick learning or for power in the hands of a master. Perl language features, especially the ones that one tends to encounter for the first time in unfamiliar code, are of the latter kind. (Not that Perl is unusual in this... quite the contrary.) One can't simply look them up, read the definition, and return to work thirty seconds later.

Third, good practice dictates that a programmer document any language extensions (syntax or vocabulary) that he or she defines and expects others to understand. Appropriate documentation is provided given the expected knowledge of the users. Standard language features are exempt from this practice, however, leaving the users of source code to find their own documentation, which will likely be the standard documentation of the language feature in its full generality, the grokking of which may in itself be a larger project than the perusal of the original code should have been.

It is my opinion, based on a few efforts to use Perl 5 as a scripting and glue language, that Perl repays only those who consistently use the language and have no reservations about getting deeper and deeper into it. It is not possible to exclude or ignore the full diversity of the language when estimating the cost of using Perl, because circumstances can and eventually will force you to learn every feature. This happens even if you do not modify or support other programmers' code, because documentation -- of libraries, of programming techniques, of the language environment, and of language features you do want to use -- so often takes the form of code. What you learn and do not use in your own code, you may forget only to be forced to relearn it later.

This is a drawback of the language, but not necessarily a flaw that needs to be corrected. The same thing is true of C++, which I use quite happily because I accepted (and continue to accept) the necessary commitment. The size and complexity (aka "diversity") of the language is a burden as well as a treasure chest. It is simply the downside of a language design choice which should be noted as part of the essential personality of Perl, as it is for C++.

Re:The version after Perl 5 is Python (1)

try_anything (880404) | about 8 years ago | (#16255159)

"Flying off the handle" is a natural language idiom idiom

Oops. I meant nothing special by "idiom idiom;" it's just a typo that slipped through.

Re:The version after Perl 5 is Python (1)

melonman (608440) | about 8 years ago | (#16249181)

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 people's modules whenever you can, and the result is often a script consisting of a list of includes of well-documented third-party modules followed by a very short piece of code that uses those modules.

Re:The version after Perl 5 is Python (1)

budgenator (254554) | about 8 years ago | (#16251063)

10,000 lines of Perl is a mess unless you're a very disciplined programmer
you 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.

Re:Huh? (1)

texwtf (558874) | about 8 years ago | (#16255669)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?