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.
Shoeboy, I love you. -- Heidi
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 :-)
And with the language changing, maybe we can get away from reference counting, and then there won't be any need for the C++ features that led me down that path in the first place.
PS: There are no 't's in my name.
Having read the article, I didn't get this at all. He is planning on forcing it for those who write modules and classes, but for the quick-n-dirty, it won't be forced.
And I imagine that once you get up to the level of project where you need to write your own modules, you probably would be using strict and -w anyway, for sanity sake if nothing else.
Zapman
Chip Saltzenberg was trying to have Perl 6.0 be in C++.
Think of the disaster that would have been.
"What do you mean, Perl will no longer install on my Solaris box? I don't have space for C++ as well as C. ARGH!"
C++ is still not protable across platforms in any sort of reasonable sense. It would have been nice if it was.
Luckly Chip got talked out of it. (Probably with a big stick.)
"Trademarks are the heraldry of the new feudalism."
Perl was designed to mirror human languages, not computer languages. (C++ may not have been designed in this way, but it certainly has evolved in a very similar direction.) You're not expected to completely understand the language, you're expected to quickly learn a fairly small working set of features, then slowly grow that knowledge as you grow in the language. Like english, or any other human language, both you and the language constantly grow to handle new problems and solutions. This is part of the reason Perl and C++ are so popular, they're living languages with practical goals. They don't force certain designs and strategies on you, they try to let you work with them as you will.
Search 2010 Gen Con events
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
> "You must use warnings and strict everywhere except your main module" is not free and fun.
Oh please. You don't have to use the warnings or strict. Most one-liners don't. You can still express conditionals and looping in at least a half-dozen different ways. You practically have to use strict in CPAN modules (though there's no hard requirement) because it's widely distributed code that could choke if someone did use strict and you code didn't conform.
This is nothing like Python, a language that has never heard of a pretty-printer, and thus hardwires one into the language definition itself.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
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.
You're right. I was thinking to myself: "What, ANOTHER Perl Apocalypse????"
If tits were wings it'd be flying around.
What is the name of the library? I love the signals and slots from Qt, but haven't gotten into GTK programming.
If tits were wings it'd be flying around.
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.
Ah, but they die to be reborn into the kingdom of god/heaven/etc.
I'm not a xtian, I don't play one on TV..I just felt it necessary to point this out -- it *isn't* a bad thing (they way they wrote it)
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.
In apocalyptic literature, 7 is the number representing perfection, while 6 is the number representing imperfection.
:)
Larry, I think number theorists would crack that, contrary to general belief, the number 6 is one of those most significant and rarest of numbers belong to the perfect number category. Those number have their divisors added up to themselves (6=1+2+3). The other perfect number is 28 (28=1+2+4+7+14). Perhaps someone will be able to point out the others.
But whatever the perfect number, I am sure that Perl 7 will be more pearly than Perl 6
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.
"What I look forward to is continued immaturity followed by death."
Example: Perl's pitiful documentation compared to Python's rich, perfect, strait-from-the-mounth-of-god, Guido himself documentation.
Either you jest or you display ignorance. The perl distribution comes with tons of doc. Try issuing perldoc perldoc. You can use perldoc -f function_name_here to get information about any perl function and perldoc module_name_here to get documentation about any module for which the author has provided it (which is most of them if not damn near all of them).
More to the point, try man perl - each of the 70 sections is its own extensive man page, covering references, objects extensions in c - you name it it's probably there.
Oh, and how extensible is Perl? I never heard of an applet written in Perl.
What do these 2 sentences have to do with each other? many meabytes of perl extensions can be found at CPAN - I don't believe I've ever wanted to do something that wasn't made much easier by something that was already there. What does writing applets have to do with exensibility? perl is quite extensible in both perl and c. And there is a project to compile perl source to java bytecode, tho I'm not sure if it's still active. But client side applets aren't my main concern. I don't think they're flavor of the week anymore, anyhow.
--
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
I think it's great that Larry is taking the time to be the visionary and leader on Perl, and providing so much of himself in what goes into Perl 6.
And I think equally important is that O'Reilly are basically paying Larry to do it. As far as I know, Larry's been getting a paycheck from ORA for just doing the Perl stuff that he does, not unlike Damian Conway getting a paid year sabbatical to be Damian.
That salary for Larry has to be some of the best investment in the community and infrastructure of software development yet, and I cheer Tim & co. for doing it.
--
I have thought about this sometimes and haven't come up with a definite solution because there eally isn't one. But I think that most languages in widespread use are good, but have some flaw in them.
I think that java approches being a really great language, but stops short because it is so god awful slow. It is also very verbose and although I like it, it doesn't go as fast as perl,python, or php. What it does have is stability, consitency, and standard libraries that come with every runtime environment. If perl 6 had classes remenicent of pythong, came with a full featured standard GUI (TK is quick,dirty, and fast but doesn't compare to the feature set of swing), standard thread, standard complex sound IO, and standard socket set that's more straightforward, I would never use anything else. I know its alot, but if that was there, then I think the language would be much more complete, then other stuff could be added with modules.
This Wiki Feeds You TV and Anime - vidwiki.org
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....
it starts with non package?
Sure that works. Sure.
But wouldn't it make the language a lot more readable to start with a new line like:
perl 6.0
Then newbies would be more likely to guess why their perl5 compiler/interpreter croaks??
No of course not. That would make no sense. They wouldn't have to buy a book from a certain well known publisher to use Perl...
So I'm cynical. Call me cynical.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Man, did you -read- the Apocalypse?
Larry wasn't talking about making functions return the current, bloated implementation of objects -- he was, instead, talking about adding a new implementation of object (based on a C struct) to perl, and having them return those -- implemented well, this shouldn't be much slower than the current (parsed) implementation such things, especially since often what you'll lose in having to make sub calls for stringify and numify you'll win by not having to translate the original structs in the first place.
An object is just a concept, not an implementation.
Josh -- (of NY.pm)
Second, Perl5 is already ebject oriented. But the OO stuff is kind of kludgy and particularly unieldy when dealing with class hierarchies. I cannot see how moving OO features to the core, as I understand is planned, and cleaning up the way inheritence is handled based on Perl5 experience can make Perl6 worse than Perl5. This is not adding features, this is correcting suboptimal design.
-- look, cheese ahoy!
Seems to me the opposite is true. Right now using objects and packages incur high overhead. Moving the inheritence code from the interpreter to the core ( which is compiled) should eliminate some of it and improve performance of OO perl code. The basic issue is that we are not talking about adding OO to perl but about correcting a faulty OO implementation. You ask what is wrong with thingies and packages. basically, IMHO, performance and the inhereritence mechanism. If Perl 6 improves on these issues it will be a Good Thing.
I certainly see the danger of screw-up, and simulating java performance will be a disaster. But we ought to give Larry Wall some credit ;-)
-- look, cheese ahoy!
But nowadays, I'm bored stiff with (programming for) the web, and likewise, my interest in Perl has waned. Also not unimportant, stuff like PHP has basically taken the crown from Perl where it comes to web development.
This is not to say that Perl doesn't have a place. Perl lends itself extremely well to perlish things. It's just that the excitement surrounding Perl seems to have diminished.
And so sometimes I cannot help but wonder whether this longish and rather dramatic prelude to the start of the preliminary design for Perl 6 is really not just a way to try and summon some lost Perl spirit; to try and recapture some of the excitement of yore.
Does the world really need another Perl? And if yes, what should it provide? The answers to that last question seem to oscillate wildly between grand visions of syntax independance and mundane matters such as thread support.
Frankly I think neither answer is very exciting. Grand visions are a dime a dozen, and thread support is just thread support.
The bottom line, I guess, is whether Perl 6 will succeed in targetting an application, or whether it will just succumb to change for the sake of change.
Let's just hope for the former.
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.
I have to say, though: of the currently popular scripting languages, Python seems to closest to becoming a real programming language, and it's still retaining its original utility and simplicity. What Python is missing at this point is a new implementation that provides incremental compilation to efficient native code, plus a few language cleanups to go with that.
And the sad reason that the great technically superior languages aren't used by more people is basically because not many other people using them. Face it, the average programmer is basically a herd animal. With the adoption of new languages we have the chicken and the egg problem... which is very hard to escape from (except through superior marketing (as in the case of Java) or with an 800 kilogram gorilla promoting the language (i.e. Microsoft and their ridiculous languages). To paraphrase Guido "Dylan is like Python, but so much more".
Wouldn't you rather have me?
I know I'm better then Heidi just ask my ex boyfreind
I fucked Heidi's camel once!!
I fucked Heidi's camel once!!
and he was more of a man then Kara's boyfriend!