Slashdot Mirror
Larry Wall on the Perl Apocalypse
raelity writes "Larry Wall provides some insight into the design of Perl 6 on www.perl.com. "People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.) What I will be revealing in these columns will be the design of Perl 6. Or more accurately, the beginnings of that design, since the design process will certainly continue after I've had my initial say in the matter." " This is a really interesting article and worth reading if you're at all into Perl. Full of Wallisms, entertaining and insightful.
Hey, that's cool. It does what Microsoft .net does, but better. At least it might.
One of the major ideas of .net is not SOAP (dunno why MS marketing makes such a hype about that), it's that you can write code in one language and use it in another because all languages use the same framework. So you can write an object in C# and use it (even subclass it) in another .net-enabled language. In .net, data types and class libraries aren't part of a programming language, only syntax and concepts are. Actually the framework is quite powerful, it can even be used for functional programming languages etc. (the downside is that only a limited subset will become a standard). That's Java, but better, if Microsoft gets things right.
How's that related to perl?
Hmmmm. Now what's that? If the semantic model is powerful enough (i.e. provides enough support to implement different programming language concepts on top of it), that's .net, but better.
I was already worried that a large part of the open source community would ignore .net, but it seems that they're about to accidentally develop an alternative that's even better. I seriously hope the Perl developers realize this possibility :-)
I guess I don't understand why people need to call other people "funny" because of they're beleifs.
It's my belief that I should quack like a duck while juggling bowling balls while completely naked, in the middle of Times Square.
That's funny. It might be my belief, but it's still funny. The two are not mutually exclusive.
I also think it's funny to take "apocalypse," which is commonly defined as the end of the world, all living things die, etc., etc., and redefine it to be a good thing. In the strict sense, Larry Wall is right. Merriam-Webster says:
apocalypse
Etymology: Middle English, revelation, Revelation, from Late Latin apocalypsis, from Greek apokalypsis, from apokalyptein to uncover, from apo- + kalyptein to cover -- more at HELL
Date: 13th century
1a: one of the Jewish and Christian writings of 200 B.C. to A.D. 150 marked by pseudonymity, symbolic imagery, and the expectation of an imminent cosmic cataclysm in which God destroys the ruling powers of evil and raises the righteous to life in a messianic kingdom b capitalized: REVELATION 3
2a: something viewed as a prophetic revelation b: ARMAGEDDON
But I think it's funny to take the opportunity to take what everybody thinks of as a bad thing and turn it into a good thing, in the Christian definition. That's the Christian thing to do, I guess, is recruit more Christians. Larry Wall took advantage of an unusual opportunity to do so, and I think it's funny.
-Waldo
If you like the signals/slots idea of Qt and other such interesting extensions to the language, check out OpenC++ here. It lets you extend the C++ compiler in C++ (plus a little). ColdStore uses it to implement orthogonally persistent and runtime-introspectable classes by simply declaring a class as cold class foo instead of simply class foo. You can change damn near any aspect of the language, including adding extra member access declarations -- like "signals:" and "slots:"
MUCH cleaner than moc.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
All in all, this first introduction to LW's ideas for perl6 sounds pretty good. I'm looking forward to more details about what he plans to do with references. Blurring the difference between an array and an arrayref, as he proposes, seems like it could be either the biggest fuckup, or the biggest improvement to the perl language. I can't wait to read the proposed new semantics and see how it's going to work.
This probably goes together with giving prototypes and typed arguments to functions and methods; I wonder if perl6 is going to need an 'apply' function, to pass a list of arguments to a function (as opposed to passing the list as a single argument), like Python does. As a perl programmer, at first it sounds bad to me, but I could possibly be convinced that it's worth it.
Finally, I'm a bit skeptical about the idea of compiling perl into jvm or C#/IL. Despite all claims to the contrary, I don't see these bytecodes being generic enough to implement all of perl's functions (including its amazingly extended regexp engine) with reasonable efficiency. The OO side (integrating objects and mapping methods and properties) isn't really the problem, but I just don't see a JVM-compiled perl module using C-based extensions from CPAN, and I don't see all CPAN modules giving up C integration either. All in all, I think the perl interpreter should remain C, with a good C-based extension model (more like SWIG, and losing the "XS" obfuscated lossage), and work together with the JVM and IL interpreters, supplementing them at the C level to run perl code.
Does anyone know a person who is both an expert (*complete* fluency) in both C++ and Perl? I have a feeling that these two languages are too large to be contained in a human head at the same time.
Perhaps we will have to evolve super-intelligent Khan-like coder clones in the future, using nanotech, Beowulf clusters, and in-dash Atari 2600 emulators.
I think you may have read it wrong. He was simply stating the way that perl6 modules would be declared is different than perl5 modules.
Nothing was added, just changed.
The quote follows:
A closely related question is how Perl is going to recognize when it has accidentally been fed Perl 5 code rather than Perl 6 code. It would be rather bad to suddenly give working code a brand new set of semantics. The answer, I believe, is that it has to be impossible by definition to accidentally feed Perl 5 code to Perl 6. That is, Perl 6 must assume it is being fed Perl 5 code until it knows otherwise. And that implies that we must have some declaration that unambiguously declares the code to be Perl 6.
Now, there are right ways to do this, and wrong ways. I was peeved by the approach taken by DEC when they upgraded BASIC/PLUS to handle long variable names. Their solution was to require every program using long variable names to use the command EXTEND at the top. So henceforth and forevermore, every BASIC/PLUS program had EXTEND at the top of it. I don't know whether to call it Bad or Ugly, but it certainly wasn't Good.
A better approach is to modify something that would have to be there anyway. If you go out to CPAN and look at every single module out there, what do you see at the top? Answer: a ``package'' declaration. So we break that.
I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. If you want to write a Perl 6 module or class, it'll start with the keyword module or class. I don't know yet what the exact syntax of a module or a class declaration will be, but one thing I do know is that it'll set the current global namespace much like a package declaration does.
--
A mind is a terrible thing to taste.
"A mind is a terrible thing to taste."
First of all, it's sad that Slashdot couldn't hold notable members of the Perl community. Makes me a bit wistful to look over the nearly content-free posts on this topic and remember Abigail's scathing and 100% accurate flames, and Tom Christensen's odd and brilliant posts. Assholes, maybe, but their minds are unparalleled and their writing incisive. They're sorely missed in a discussion like this.
In any case, Perl is in good hands. Require strict and warnings for modules makes sense. Leaving room for Perl to grow is a good thing. Making everything an object that is free to return in scalar context adds flexibility while giving functions the freedom to behave as they see fit.
Most of all, these principles are in place before the major work of adding full Unicode support and meta-languaging begins. There's a firm hand on the tiller, and Larry seems as up for the work as he ever has been.
You mean Perl and Python coming together to become Parrot was just a joke?? I had totally believed it seeing as it was on Slashdot and all....
Larry is out of his mind. He's creating perl++ and he's accepting the anti-UNIX pro-BLOAT RFC's. I confess I never expected that from him.
- Everything will be an object.
This is ridiculous. I always chose C over C++, now I'm choosing perl5 over 6. Period. I'm a perl5 monger(brasilia.pm.org) now. There'll be perl6 mongers. I'll call them the PERL BLOATERS. I can write better perl with perl5.
- 'package' means perl5 otherwise 'use perl6';
A FCKING PATCH. MICROSOFT STYLE, LARRY. Go for it.
- Perl will stay perl.
Uhuh. And we're all stupid and can't tell. Perl 5 is PERL, 6 is PERL++.
Conclusions
Yeah, just like Samba we're going to see 2 perls from now on. I'm sticking with 5. Most will move to 6.
Fine with me. Just glad I dig perl 5. If others agree just show you do by writing better perl 5!!!!
Broken Hearts are for Assholes. - Frank Zappa
"People get scared when they hear the word Apocalypse"
Some people get scared when they hear the word Perl...
I am disappointed by the fact that Perl can not deliver compiled code. The help blurb on the Perl executable says that the compiler option is experimental! When will this not be experimental?
"sweet dreams are made of this..."
I think this article is interesting in that it gives some rare insights into language design. You always hear people complaining about why didn't x (where x is C++, Java, Perl, etc) do this or that? Why this feature or syntax? Here Larry points out some trade off that may not be obvious to "end user". And all written in a easy to understand language called English too ;-)
While this is not a complete redesign, it is not everyday you get to see just exactly one design an programming language used by millions of people. Good stuff, definitely stuff that matters. This is a must read for people interestined in programming language. I am really looking forward to the next one.
OT: The design of Perl6 is somewhat similar to the kernel: anyone can submit rfc (patch) and Larry (Linus) has the final say on what goes it. (No, I don't know where I am going with this either :-)
====
Codeala - Just another mindless drone
Threading - MP3::Napster, a popular module written by Lincoln Stein requires a threaded perl interpreter; I happen to use this module for my project (spam, spam [grin]).
More perl ports - I would like to see perl ported to PalmOS; some nodes on PerlMonks reveal that there is a lot of interest in this; Although I sometimes wish they would take a look at the projects on handhelds.org.
Dusk begins to realize that he is ranting....
Anyway, I am sure that I will be pleased with the results; Saint Larry will not let us down :)
My guess it that Python porters were able to overcome this obstacle by writing much of Python in Python itself, hence Pippy.
Once Perl 6 is released, though, the Perl community will be able to quickly play catch up, and get a port out rapidly. Woohoo!
If ya can't beat 'em, clone 'em.