State of the Onion 11

chromatic writes "Larry Wall's State of the Onion 11 address is now online. Every year, he describes the state of Perl and its community through metaphor and analogy. This year, Larry explored the history of scripting languages, from their dimly-lit beginnings to their glorious future. Along the way, he also describes several of the design principles invoked in the design of Perl 6. 'When I was a RSTS programmer on a PDP-11, I certainly treated BASIC as a scripting language, at least in terms of rapid prototyping and process control. I'm sure it warped my brain forever. Perl's statement modifiers are straight out of BASIC/PLUS. It even had some cute sigils on the ends of its variables to distinguish string and integer from floating point. But you could do extreme programming. In fact, I had a college buddy I did pair programming with. We took a compiler writing class together and studied all that fancy stuff from the dragon book.'"

scripting

[Lord Ender]

I really wish the term "scripting language" would die. Can't we just call them "very high level" languages, instead? Isn't that sufficient to distinguish the Perls, Pythons, and Rubys of the world from the "high level" languages like C and C++? It is perfectly possible to compile Python programs, for example, to a pyc binary. They aren't any more "scripts" than a.out. The difference between "very high" and "high," to me, is the fact that dynamic datastructures (lists, hashes) are native, so programmers don't have to worry about mundane memory address and pointer nonsense.

Re:scripting

[Ed Avis]

Python, Perl, Lua etc. are very high level languages, at least from a slightly old-fashioned perspective that regards assembler as the baseline and something like C or Pascal as high level. But there are other very high level languages which are not scripting languages, for example Haskell, Erlang, Prolog, C++ with insane template nonsense, even SQL and XSLT. So the term scripting language is still useful I think. The definition is a bit fuzzy, which is what Larry points out in his talk.

Fine by me

[winkydink]

Perl 5.8 does everything I need it to. There are other languages I use when Perl doesn't do what I need it to. I don't need one language for all of my needs.

I view Perl 6 as an continued employment mechanism for those who write books about Perl and teach Perl to others.

Re:Yup... and he doesn't apologize for it

[rubycodez]

getting it right???? Perl 6 is a pathologically overcomplicated mess of anything and everything Larry saw in other better designed languages over the last decade, all mixed up with no rhyme or reason. It's like a swiss army knife with condiment and shaving cream dispenser, cell phone and vibrating butt plug. The specs are a nightmare to read, the syntax takes 25% more effort to construct something compared to other scripting languages, and there's no end in sight. Time to realize Perl 6 is like the Ripley-Alien clone freaks, only merciful thing would be to hit it with a flamethrower and start over.

Thanks, and see ya!

[stuntpope]

Thank you, Mr. Wall, for providing a language that caught my interest and led me into a profitable career.

However, I moved on several years ago. One of those Python guys inspired negatively by Perl. Much of what keeps me away from Ruby, in fact, is the Perl resemblance. I still have a legacy Perl application to maintain, but I don't do any new Perl work.

I'd think a regular "State of the Onion" pronouncement would be an avenue to discuss where we are today, and where we are headed, with Perl. Instead, it's a rambling short history of "scripting" languages, and a rundown of various language design choices with "Perl 6 will have [x]" statements.

I guess I really don't get the purpose of the essay.

As to TMTOWTDI, I've concluded TOABWTDI (There's Often A Better Way To Do It).

Re:Perl 6: The Language of the Future (... Forever

[krog]

Or, conversely, you could blame yourself for not knowing the language you're trying to work on, rather than blaming your colleague for knowing it.

I'm not saying that ugly Perl doesn't exist, because it sure as hell does. Perl does not enforce any coding standards at all on its programmers, so undisciplined coders will write undisciplined code, but I'd rather be in Perl's side of the enforcement continuum than, say, Java's or Python's side.

Re:Perl 6: The Language of the Future (... Forever

[timster]

You said that it's OK for Perl to have an excessive number of features, because you don't have to know them. I'm pointing out that the truth is that you do have to know the whole language to use it. So no, I don't have to "blame myself for not knowing the language", I blame the language for being poorly designed.

Re:Thanks, and see ya!

[kisrael]

I'd think a regular "State of the Onion" pronouncement would be an avenue to discuss where we are today, and where we are headed, with Perl. Instead, it's a rambling short history of "scripting" languages, and a rundown of various language design choices with "Perl 6 will have [x]" statements.

I guess I really don't get the purpose of the essay.

I think the purpose of the essay might be to be a rambling short history of "scripting" languages, and a rundown of various language design choices with "Perl 6 will have [x]" statements.

It was also (IMO) a damn fine read, with lots of intriguing rhetorical flourishes (I also learned a little C. [...] That's because a little C is all there is) and thought-provoking concepts, like how most human languages can express anything, but they differ in what you MUST express.

I think most people have a rough idea where Perl is now (present, though likely slipping as a % of interesting code being written) and where it's going (a guess about how the new perl 6 would be received when it finally shows up)

As to TMTOWTDI, I've concluded TOABWTDI (There's Often A Better Way To Do It).

Better than Perl, or in general?
If the latter, well sure... there will almost be another way that is better in some subset of the parameters you could use to measure "Betterness". One tradeoff you always have to make is how much time and conceptual effort do you put into optimizing that...

Re:High level != "automated memory management"

[smittyoneeach]

Can we please stop bashing C++ memory management?

No.
If we don't insist on treating the tools themselves as the end product, then how will we perpetuate mis-information, and sell "new" products, which are, dared we look at them objectively, just re-shufflings of what has come before?

Re:scripting

[Yvanhoe]

Perls, Pythons, and Rubys are interpreted languages as opposed to compiled languages. A .pyc is not an executable file.
Every people use the term differently. Here is mine : I am doing a script when I give directives to launch programs or functions written in another language. When the CPU spends 90% of its time outside my program, I consider that this is a script.
Python's philosophy is that it is a scripting language in the sense that if you spend more than 10% of your CPU time interpreting some python code, you are doing something wrong. They encourage you to rewrite these image processing functions in C/C++ if you are serious about performances.

And yes, given this definition, one can write scripts in C.

Worst presentation in a while.

[harrkev]

Is it just me, or is this his worst presentation in a while? I think that I missed last year's, but I remember thinking that a couple of his presentations were quite original. There is the one where he based his entire presentation on an optical-illusion picture (three years ago, as I recall), and one where his presentation was based on the default Red Had screensaver collection (two years ago, if I am not mistaken). I had always thought that listening to him present one of these would be kind of like geek-stand-up-comedy. This one was downright plain by comparison.

Re:Fine by me

[TheLink]

There's one big limitation I find with Perl 5.8. It's slow. Don't get me wrong it's fast enough in many cases.

BUT if it was 20-30 times faster people would be able to use it for a lot more stuff where they'd otherwise have to resort to stuff that involves a lot more work :).

Parrot hasn't been very impressive, and ponie is dead anyway.

Yeah I know python is a bit faster and cleaner but so far it doesn't seem like a huge improvement.

I've looked at Lisp and I've come to the conclusion that:

Lisp is powerful for all the code you write, unfortunately you still have to write a lot of that code yourself.

In contrast Perl is powerful because of all the code you don't have to write. :)

Re:scripting

[Reality Master 101]

It doesn't. It does, however, require a 32 bit integer data type (which the OP said). It doesn't. It does, however, require a 32 bit integer data type (which the OP said).

Close, but not correct. C requires *at least* 16 bits for a short, and *at least* 32 bits for a long. It actually doesn't require an exactly 32 bit integer datatype. Well, to be really pedantic, the C Standard specifies a range of values that a datatype must support, so technically a binary machine is not required.

Put up or shut up, please

[coryking]

I'm disappointed with the state of perl. I used to be a huge perl nut and have a major project that is all mod_perl. But I'm growing increasingly fustrated by the lack of modern programming tools, especially compared to other modern languages. Even PHP has a better choice of editors. Heck, I can write syntax colored, intellesense'd python in Visual Studio!

Perl6 is a text book example of why rewrites are bad. While these people are busy writing the Programming Language to End All Programming Languages, .NET has stolen the market for the very thing these people where trying to make. Pugs, or parrot or whatever, sounds a heck of a lot like .NET/Mono. By the time Perl6 gets out, if it ever does, nobody will care about it because the open source market will be dominated by Mono. At this rate, the perl crew might be better served by just compiling down to MSIL and leveraging Mono for cross-language compilation.

So please, put up or shut up.

See also: Netscape.

Re:scripting

[Chandon Seldon]

Hand compiling is only moderately more complicated for Perl than it is for C. Just as the C function turns into a specific pattern in assembler, the various things that Perl provides can be turned into assembler patterns too. The stuff that Perl does for memory management implicitly is only moderately more complex than the stack manipulation that C does implicitly for lexical variables. Even the two data structures that Perl provides - vectors and hashes - are just very simple data structures that would always translate into the same simple pattern of assembler.

Basically the only thing that cleanly differentiates a language like Perl from a language like C is the "eval" function - which requires access to a Perl interpreter/compiler to work.