Apocalypse 12 From Larry Wall

rheum101 writes "Larry Wall just released the eagerly anticipated Apocalypse12 . detailing Perl6 OO in all it glories. To quote the author -> 'One other note: if you haven't read the previous Apocalypses and Exegeses, a lot of this is going to be complete gobbledygook to you. (Of course, even if you have read them, this might still be gobbledygook. You take your chances in life...).'"

Comments

Many Informative Links

[Pan T. Hose]

I have submitted a story but it was rejected, so please let me resubmit it as a first post instead.

The long awaited Apocalypse 12 by Larry Wall has been just announced by chromatic on perl6-language mailing list. It is one of the most important documents explaining the Perl 6 language design. (All of the previous design decisions are available as Apocalypses by Larry Wall, Exegeses by Damian Conway and Synopses by Luke Palmer, Damian Conway and Allison Randal.) Apocalypse 12 talks about Object Oriented aspects of Perl 6, i.e. about Objects, Classes, Roles (also known as Traits), Multiple Dispatch and also covers some non-OO decisions:

"The official, unofficial slogan of Perl 6 is "Second System Syndrome Done Right!". After you read this Apocalypse you will at least be certain that we got the "Second System" part down pat. But we've also put in a little bit of work on the "Done Right" part, which we hope you'll recognize. The management of complexity is complex, but only if you think about it. The goal of Perl 6 is to discourage you from thinking about it unnecessarily." --- Larry Wall.

(Lameness filter didn't allow me to post the table of contents. Reason: Please use less whitespace.)

You can access the entire document as a print friendly version. The standard version of Apocalypse 12 is divided into 20 parts. Enjoy.

If you are new to Perl 6 and Parrot, then Perl 6 Essentials by Allison Randal, Dan Sugalski and Leopold Tötsch might be a great introduction. The second edition should be published soon.

Looks like progress to me

[moof1138]

I have a lot of Perl code out there that is probably going to take a while to port, but I have to say that a lot of the changes here really do make me sigh in relief. Lots of what Larry was going over here are the bits I am looking forward to in Perl 6. I use OOPerl, but never have really liked it. The object system will finally make a lot more sense, and be a lot more intuitive for those coming from other OO languages. The fact that we will real classes instead of magic packages, we get to use the keywords 'class' and 'method' rather than 'package' and 'sub', we se dots to dereference objects instead of ->, and so on are nice. There still are a lot of the clever perlisms left over, and there are a lot of cool looking innovations in perl 6, and I am happy with that.

Over all I am really excited about Perl 6. I know it will take a lot of relearning, and some code is going to be a bitch to update, but porting isn't necessarily required unless there is a compelling reason to move to 6, and the more I read about the cleaner approaches to old problems in Perl 6 the more I like it. I also expect many of the changes should help raise Perl above some of the criticisms of language snobs.

No switching between $, @ and %

[Pan T. Hose]

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse [emphasis added]

The changes proposed for Perl 6 means no switching between $, @ and % any more.

Thank you!

[Pan T. Hose]

In the name of the entire Slashdot community, I would like to thank Larry Wall for the absolutely amazing work he is doing. Thanks Larry! There are many people working very hard to make our dream come true and give us the most innovative and cutting-edge programming language in existance, which Perl 6 is soon going to be. It would not be possible without all of the Perl 6 and Parrot contributors. Please let us also not forget about brave people who still actively maintain Perl 5 and will keep doing it even after Perl 6 is ready. The Ponie project shows us that Perl 5 is not going away. The work of all of those people is invaluable. And this is all to give us free software development platform of the 21st century, while uniting Perl, Python, Ruby, Tcl, Scheme, Ook, Forth, Befunge, BASIC and many other languages thanks to Parrot, finally allowing them all to seamlessly work together and ending the flame wars between them. Thank you!

oh happy day :)

[Ender Ryan]

Class declarations may be either file scoped or block scoped. A file-scoped declaration must be the first thing in the file, and looks like this:

class Dog is Mammal;
has Limb @.paws;
method walk () { .paws».move() }

Yay! I absolutely _hate_ having to have an extra set of braces around everything in an entire file. I have always enjoyed the way packages, and now clases, in perl are scoped.

I know, seems like such a tiny thing, but dammit, I like to be able to go a bit further before hitting the right margin :) Especially in a language like Perl, with such compact code, lines tend to be pretty long sometimes.

Optional Mandatory Cross-Disciplinary Joke

[moof1138]

The whole doc is really fascinating, and full of witty Larry Wallisms, but for those who don't read it all the way through to the last page, the Apocalypse ends with a 'Optional Mandatory Cross-Disciplinary Joke for People Tired of Dogs' section:


Biologist: What's worse than being chased by a Velociraptor?
Physicist: Obviously, being chased by an Acceloraptor.



Followed by a 'Future Directions' section:

Away from Acceloraptors, obviously.


Larry Wall is so cool.

Dot verus arrow

[JusTyler]

The use of arrow where most of the rest of the world uses dot was confusing.

Perl has always done things in a way that someone thought was 'right' when they coded it, and which isn't necessarily based on standards. I would contest that everyone else was doing it wrong here, and that the arrow makes way more sense, as it implies hierarchy, whereas a dot does not.

Re:Dot verus arrow

[chromatic]

True, the arrow does have a nice visual effect. Of course, it's also two characters compared to one -- and it's nice to make common things short and sweet.

Why is this story not on the front page?

[Pan T. Hose]

Excuse me but I believe this story should be on the front page, should it not? I am sure everyone will agree with me. We all have been waiting for that Apocalypse for over a year now (since March 7, 2003, to be precise). Furthermore, this is undoubtedly one of the most important Apocalypses. Am I the only one who thinks that the future of computing as we know it is at least a little bit more important than some satellite TV pirates or the daily SCO Stock update? I believe this story was not posted on the front page due to an errour. I expect it to be corrected by the Slashdot editors as soon as possible. Thank you.

Everyone is Right

[Pan T. Hose]

ruby? Python? Kid's toys.

Common Lisp. Enough Said. Okay maybe Scheme, if you're a bit of a masochist...

Everyone is right here. There is no one language which is best for everyone. Perl 5, Perl 6, Ruby, Python, Lisp, Scheme... They are all going to target Parrot so we will be able to choose our favourite language and still work together instantiating our objects and even inheriting from each other's classes crossing the cross-language boundaries. A very impressive work has already been done in the 0.1.0 "Leaping Kakapo" version of Parrot. See: Parrot FAQ and the languages directory in the CVS.

Manipulating Arrays of Arrays in Perl

[Pan T. Hose]

I haven't been following perl 6 too closely, is there any word on if Perl will be getting rid of the multi dimensional array hack of having to use references? This is something that dates back to Perl 4. It could have been fixed in Perl 5 but was the whole references thing was introduced for backwards compatability. But so much is changing in Perl 6 anyway it would be nice to be able to do things like @array[6][4][2][5][6] = "whoa!"

See perldoc perllol: Manipulating Arrays of Arrays in Perl.

It does bode *very* well for Perl 6

[Pan T. Hose]

Aha! So even Larry Wall admits Perl is all "gobbledygook"! This does not bode well for Perl 6.

As a matter of fact, it does bode well for Perl 6. Even very well, I might add. As Larry Wall has said in his famous State of the Onion speech on TPC4: "Perl 5 was my rewrite of Perl. I want Perl 6 to be the community's rewrite of Perl and of the community." Also, please let me quote the first Apocalypse: "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. I'm not omniscient, rumors to the contrary notwithstanding. This job of playing God is a little too big for me. Nevertheless, someone has to do it, so I'll try my best to fake it. And I'll expect all of you to help me out with the process of creating history. We all have to do our bit with free will." Now, I can assure you that those four years were not wasted as you seem to imply. I think Larry Wall has used the right words on OSCON 2003:

• We the unwilling,
• led by the unknowing,
• are doing the impossible
• for the ungrateful.
• We have done so much for so long with so little
• We are now qualified to do anything with nothing.

How true...

I gave a bad example

[bangular]

I gave a bad example. Perl doesn't support true multi dimensional arrays. Read http://www.perldoc.com/perl5.8.0/pod/perlreftut.ht ml The values within an array must be scalars. This is something back from the perl 4 days. So in the example I gave, everything deeper than [4] is actually an anonymous reference.

Flex Link

[CaptainPinko]

the actual flex link is http://www.gnu.org/software/flex/manual/html_mono/ flex.html

Troll feeding

[IpalindromeI]

The reason this post seems almost like a good post is that it's a subtle troll.

It shows up in most of the Perl 6 stories.

Slow Languages

[Pan T. Hose]

Everyone is right here. There is no one language which is best for everyone. Perl 5, Perl 6, Ruby, Python, Lisp, Scheme... They are all going to target Parrot so we will be able to choose our favourite language and still work together instantiating our objects and even inheriting from each other's classes crossing the cross-language boundaries.

Wow! What a wonderful and innovative idea, totally unlike anything anyone has done before!

JVM is not exactly language-independent. It is not very well suited for dynamically typed languages such as Perl 5, Perl 6, Ruby, Python and in fact even for languages like Lisp and Scheme. Thought, with few exceptions like immutable strings or some uninheritable base classes, JVM is quite a nice environment for statically typed languages with simple single-inheritance object models like Java.

The Microsoft .Net on the other hand is not very platform-independent and I don't think it ever will be, while still supporting mostly statically typed languages. Besides, it didn't even exist at the beginning of Parrot project...

In any case, none of them runs Perl 5, Perl 6, Ruby, Python, Lisp and Scheme which I was talking about. So yes, Parrot is in fact totally unlike anything anyone has done before. Very true.

As long as you only want to write in slow interpreted languages, it's not a bad idea. Personally when I use Lisp I compile it to native code, and it runs FAST. When I use ML I compile it to native code, and it runs FAST. When I use Perl... I spend several minutes twiddling my thumbs. No thanks.

There is no such a thing as slow language. The only way in which a language per se can be slow is the parsing time. Of course Perl 6 having unprecedentedly rich (and even self-modifying) syntax will always be much harder to parse than Lisp which is basically a manually written parsed tree. However, you will always be able to compile it once and store Parrot bytecode or native binary. Even without compiling it to a native binary, there is JIT engine which can run critical parts of the bytecode as single assembly instructions on harware registers if you give enough hints to the compiler. See the files in parrot/jit directory in the CVS. It is really worth reading.

Re:Haskell - Parrot

[jonadab]

> As a sidenote I might add that Perl 6 will support the functional paradigm.

Perl5 supports *portions* of it already. closures are already fully supported,
as well as list-transformation functions. I suppose you meant that Perl6 will
widen its support so that it can handle full-blown FP with continuations and
the whole works, which matches what I've heard.

> It is just not the only paradigm it will support.

Heckno. Perl will always support contextual programming and imperative
programming; object-oriented programming and functional programming are
both getting huge boosts in Perl6, and there's talk of logical/declarative
paradigm stuff slipping in e.g. from Prolog. Perl is fundamentally a
multiparadigmatic language; you can use whichever paradigm is the best fit
for the problem space of your program, and you can freely mix and match the
paradigms at will, which I do. It's often convenient, for example, to have
an object method accept as one of its arguments a coderef (e.g. to use as
a callback), which can be a closure. Going the other way, a closure (or a
set of related closures) can retain objects and use them to do stuff. I
do this stuff today in Perl5. With Perl, you get the best parts of all
paradigms. This will be even more true in Perl6, which is getting both
real objects *and* continuations, among other things. The support for
contextual programming is also being beefed up; a routine will be able to
return an object that knows how to return one value in numeric context,
another value in string context, and so on. (My personal favourite
four-word quote from the Apocalypse series so far is "interesting values
of undef". If you don't know why this is awesome, you do not yet fully
grok the contextual programming paradigm.)

And yeah, Haskell is more innovative than pragmatic. The innovative things
about Perl are three: context, the CPAN, and assimilation. Assimilation
in this context means that the Perl dev team actively hunts down other
languages and incorporates their nifty features into Perl. There's been a
lot of talk about Smalltalk and Haskell on perl6-language, for example.
One could argue that another way to say this is, "Perl prefers to let other
languages do its innovation for it." But it seems to be a pretty good model.
None of the other languages seem to have all of the nifty features that Perl
has together in one language.

Context IMO is the most innovative thing about Perl. The CPAN also rocks.