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.

Perl6 is a mistake

[rqqrtnb]

I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

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 -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Re:Perl6 is a mistake

[Qwavel]

It seems like you had something interesting to say, and you went to the trouble of writing it, so why wrap it in insults and promotion (ruby). I was looking for something with valid criticisms to moderate up, but you are not it. (Now that I've posted I can't moderate anything here.)

Re:Perl6 is a mistake

[Anonymous Coward]

ruby? Python? Kid's toys.

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

Re:Perl6 is a mistake

[42forty-two42]

The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

Have you read A12 yet? It's not as bad as you think:

class FooBar is Widget {
has $.frobCount = 42;
method frobnicate { $.frobCount++; }
}

my $barfoo = FooBar.new;
$barfoo.frobnicate;
say $barfoo.frobCount; # Prints "43\n"

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!

Re:Thank you!

[Anonymous Coward]

In the name of the entire Slashdot community, I would like to thank Larry Wall for the absolutely amazing work he is doing.

Keep your words out of my mouth, please. This particular member of the Slashdot community has nothing against Perl, but has no intention of ever using it (I prefer to write fast and type-safe code, thank you), and sees no reason to worship Larry Wall for anything he's written since patch(1).

By the way, I see very little that's innovative in Perl 6 - it's a melting-pot combining nice features from many languages, not a research project. If you must drool over Larry's boots, at least drool for the right reasons. ;)

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.

aha!

[shfted!]

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

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.

Re:Dot verus arrow

[Anonymous Coward]

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.

Except that the place you want to indicate heirarchy is with namespace and package membership - and there Perl uses a C++-a-like ::.

The -> or . of OO method invocation represents neither heirarchy nor membership, but message dispatch. That's the context in which an arrow makes sense.

Multi Dimensional Arrays and Hashes

[bangular]

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

Re:Multi Dimensional Arrays and Hashes

[moof1138]

I am not sure I follow you here. Maybe I missed your point, but this runs fine for me:

#!/usr/bin/perl -w
use strict;

my @array;

$array[6][4][2][5][6] = "whoa!";

print $array[6][4][2][5][6];

Re:Multi Dimensional Arrays and Hashes

[jonadab]

A syntax shortcut was added in 5.0 so that you don't have to know about the
references if all you're doing is $foo[$w][$x][$y][$z] = $bar; it just works.
The old Perl4 way of doing things is heavily deprecated and very seldom used.

It is true that multidimensional arrays are implemented using references,
but frankly under the hood so are single-dimension arrays. For example,
in a subroutine the elements of @_ are actually aliases to the arguments
that were passed in. (Now *this* is changing in Perl6, because we're
getting real named, typed parameters; the old Perl5 pill-style function
prototypes are going away, thankfully. However, it will be possible for
a routine to get Perl5-like semantics for @_ if that's what it wants.)

Re:Multi Dimensional Arrays and Hashes

[jonadab]

> However, it will be possible for a routine to get Perl5-like semantics for
> @_ if that's what it wants.

BTW, I think that will be spelled something like this:
sub foo (*@_ is rw) { Subroutine_Code_Goes_Here }

The * flattens any lists or arrays that are passed in, giving you one big list.
@_ is what Perl5 called its arglist variable, so I called it that to match
what it would be in Perl5; you could call it @args or whatever if you prefer.
is rw means read/write, i.e., you can modify it. I could be slightly off on
the exact details here, as I'm not certain rw automatically propagates to all
the elements in the list; that might have to be stated explicitely another way,
I'm not sure. (It's been a while since I read Apocalypse 6, so I'm rusty.)

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.

Re:Everyone is Right

[Anonymous Coward]

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!

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.

Re:Everyone is Right

[be-fan]

I love that I can now use "Lisp is FAST" as an argument against C# and Java :) Oh, how the tables have turned.

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

Re:It does bode *very* well for Perl 6

[shfted!]

Joking aside, I hope the new version does well. It sounds like quite of bit of simplification of things is being done, in that things will be easier to do. I've not hacked in the language myself, but I do respect its flexibility and utility.

Re:It does bode *very* well for Perl 6

[smittyoneeach]

Isn't that bulleted statement due to Churchill?

gobbledygook

[Arngautr]

If I read something associated with PERL and it didn't look like "gobbledygook" I would be concerned.

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

Who cares!!!!!!!!!

[Anonymous Coward]

Isn't PERL dead??

OT: Haskell

[r6144]

Well, if you want a innovative language (rather than a pragmatic one), Haskell should definitely not be left out. Granted, it may be a little hard to use if you just want to write real-life programs (quite a lot of computer-science stuff are involved just for mutable state), but its interestingness beats OCAML and even Lisp if you are getting tired of 20 slightly different imperative languages. The language is also well supported in the free software community.

Of course, I'm not disparaging Larry's work here. Perl is a good and pragmatic language, and I'm glad to find it getting rid of the historical ugly parts..

arrow direction confusing

[dankelley]

What confuses me is the direction of the arrow. The notation

my $point = Point.new(x => 2, y => 3);

just sort of reads wrong to my eye. Writing

x <= 2

is easier (again, for my eye), perhaps because it echoes other languages (perhaps a bad criterion), and mathematical notation (probably a good criterion).

I'm sure there is a way to visualize this syntax, but as it's written, it looks to be storing the value of x in the container 2.

PS. I should note that I've never used the OO aspects of perl. I use only perl4 features; since I use other languages for OO work, I've not had the need to learn the perl way. So my comment might be useless; I'm sorry if so.

Re:arrow direction confusing

[JusTyler]

Now that really is a good point, and not one I've considered before. I was specifically talking about method invocation though.. i.e.

$x = new Whatever;
$x->doSomething();

But thanks for bringing that other point up, you're on the money.

Re:arrow direction confusing

[hummassa]

I like a lot some of the new syntaxes for this:

my Point $p .= new :x(2) :y(3);

%reserved_words> = 1;

Re:arrow direction confusing

[Anonymous Coward]

<= is the well known "less or equal" operator. IThe problem with people commenting Perl6 is that they propose microoptimization before even trying to get the big picture. The arrow is not new to Perl even if Perl6 gives it a new slightly different meaning: it is a pair constructor

Interesting notes on Parrot

[Pan T. Hose]

Please let us all keep in mind that only three years ago Parrot was merely an April Fool's joke (and quite brilliant at that). See the original Perl and Python Announce Joint Development press release on use Perl, the interview with Larry Wall and Guido van Rossum on Perl.com and the O'Reilly book announcement: Programming Parrot in a Nutshell by Guido van Rossum and Larry Wall. Does anyone remember the Perl + Python = Parrot Slashdot story? I am sure that back then absolutely no one was expecting that it might all come true some day. That's amazing how much has happened during those last few years.

Haskell -> Parrot

[Pan T. Hose]

Well, if you want a innovative language (rather than a pragmatic one), Haskell should definitely not be left out. Granted, it may be a little hard to use if you just want to write real-life programs (quite a lot of computer-science stuff are involved just for mutable state), but its interestingness beats OCAML and even Lisp if you are getting tired of 20 slightly different imperative languages. The language is also well supported in the free software community.

Haskell is very interesting indeed. And there are already plans to write a Haskell compiler targetting Parrot. (The relative interestingness is a very subjective matter, though.) There is already a Scheme compiler written by Juergen Boemmels and Jeffrey Goff (version 0.0.11 is "Functioning, as far as implemented. Lists and functions are working but many functions are missing implementation.") so Lisp, OCAML and Haskell compiler writers will have some interesting prior art to base their compilers on. I really look forward to having as many languages targetting Parrot as possible. The very recent ONLamp article, Building a Parrot Compiler (It's not just for Perl 6 anymore) by Dan Sugalski, is a great start for anyone planning to write a Parrot-targetting compiler. That's pretty amazing that three years ago Parrot was only an April Fool's joke...

Of course, I'm not disparaging Larry's work here. Perl is a good and pragmatic language, and I'm glad to find it getting rid of the historical ugly parts..

As a sidenote I might add that Perl 6 will support the functional paradigm. It is just not the only paradigm it will support.

Any examples?

[Pan T. Hose]

By the way, I see very little that's innovative in Perl 6 - it's a melting-pot combining nice features from many languages, not a research project.

Could you be more specific on which exactly innovative features are you missing in Perl 6? It is not too late to suggest them.

Re:Haskell - Parrot

[smittyoneeach]

C++ has been getting functional of late, if you're into Boost.
Perhaps there is something to this bit about all roads leading to Lisp.
I'm curious to see how well Parrot, Python, and Boost::Python will get along, myself...

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:Slow Languages

[ajs]

There is no such a thing as slow language.

I disagree. Any language which removes basic assumptions made by lower-level languages (e.g. that my int won't become a string when I'm not looking) will "slow" the language.

Perl 1..6 makes many tradeoffs which require that it be slower in execution than, for example, C. But that's not all bad. It gives you a level of semantic flexability that you don't have in those lower level languages. Granted, you pay for it, but I think the price is worth it.

As an example of what I mean

my int $x=1;
my int $y=2;
my int $z = $x + $y;

What's the result? In your model, we would agree that the reuslt must be an integer, and specifically 1, but that's (woefully), not the case. You can't know that another thread hasn't womped the contents of $x and replaced it with a high level object that is "sort of 1" by the time the third statement executes. Worse,

my int $x = foo();
my int $y = bar();
my int $z = $x + $y;

Here, we don't even know if we're dealing with integer addition! If $x is a URI, then hold on to your seat and enjoy the ride, but you're not going to be sure of the result.

Perl and picoJava

[jamckeon]

The problem is with picoJava which is the basis of the Sun microJava 701 chip. It is a single chip CPU with two bus interfaces, one for the 64 bit wide memory bus and one for the 32 bit wide PCI bus. Like the Pentium II and the UltraSPARC II, it has a split level 1 cache on the chip, with up to 16 KB for instructions and up to 16 KB for data. This is something the Perl community must address and soon.

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.

Very True and Insightful

[Pan T. Hose]

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.

Closures are already supported indeed, but Perl 5 lacks the essential built-in support of lambda calculus. It will change in Perl 6. As Larry Wall has said on perl6-language mailing list on December 2002, "About the only things that have to be truly built-in to Perl 6 are lambda and the regex engine. Everything else is negotiable. (I'm counting method dispatch under 'lambda', of course..." Perl 6 thus will fully support the functional programming paradigm. This is great news for anyone seriously into computer science in general and artificial intelligence in particular.

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

I can only agree wholeheartedly.

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.

Perl is a truly postmodern language in that regard. It has started as a duct tape of Internet and is inevitably becoming the most powerful Swiss Army chainsaw ever known to man.

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.

Very true. For example, the Roles in Perl 6 are inspired by what is called Traits in this research paper presented on the European Conference on Object-Oriented Programming only months ago. It is quite an innovative idea and as far as I know it has been only implemented in Smalltalk as an experiment made for that very paper.

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

It most definitely rocks indeed.

Re:Very True and Insightful

[chromatic]

Actually, we were talking about Roles (though not calling them that) before that paper was written. It was good fortune that two members of the design team caught Andrew Black's presentation of the paper and sent it along to Larry with a note saying "This must be a good idea; Smalltalkers are thinking about it too!"

Interesting

[Pan T. Hose]

Actually, we were talking about Roles (though not calling them that) before that paper was written. It was good fortune that two members of the design team caught Andrew Black's presentation of the paper and sent it along to Larry with a note saying "This must be a good idea; Smalltalkers are thinking about it too!"

That makes Perl 6 even more innovative than I was previously trying to demonstrate. Are there any other areas of Perl 6 (other than Rules, for regular expressions were always cutting-edge in Perl) which might be examples of true innovation unheard of in other languages? All of the new dispatch mechanisms and hyper operators seem like good candidates.

What a Shame...

[Pan T. Hose]

The long awaited Apocalypse 12 finally gets published and what we as a Slashdot community are doing? We completely ignore it and post a story about some God damned satellite TV pirates, a stupid 419er Lost in Space, the daily SCO Stock update and literally dozens of absolutely unimportant stories on the front page instead! We even ask "Is Experience in Programming Worth Anything?" on the same day and than we completely fail to help people get said experience. Meanwhile on Perl6-Language mailing list:

Austin Hastings:

If it's not totally obvious to everyone, you should download a copy of A12 (I like the "printer-friendly" all-in-one-page version) as a hedge against the almost-inevitable slashdotting.

Larry Wall:

Or not...

Perhaps slashdot has decided they don't frontpage PhD dissertations. :-)

John Siracusa:

Yeah, but did you see the story about that awesome new D language? It has a native "dictionary" type!

Larry Wall:

Hey, it supports C syntax, so maybe we could compile Parrot in it. :-)

I think all of us should be ashamed. All of us. I have tried but failed. My post saying that this story should be on the front page has been even moderated as "Redundant." Just like every single Slashdot user, I am also partially responsible for this shameful incident. I can only say that I am very sorry and I do really hope it will not happen again, in the name of the entire Slashdot community which should be covered in shame.

You disagree?

[Pan T. Hose]

I disagree. Any language which removes basic assumptions made by lower-level languages (e.g. that my int won't become a string when I'm not looking) will "slow" the language.

You may disagree, but as far as I know, even though Perl 6 removes those very assumptions by default, one is still free to explicitely impose them nonetheless, is one not?

As an example of what I mean

my int $x=1;
my int $y=2;
my int $z = $x + $y;

What's the result? In your model, we would agree that the reuslt must be an integer, and specifically 1, but that's (woefully), not the case. You can't know that another thread hasn't womped the contents of $x and replaced it with a high level object that is "sort of 1" by the time the third statement executes.

I was under the impression that in Perl 6 (or in "my model," if you will) int means a promise to the compiler that you are not going to store anything which is not integer and Perl's optimizer can use Parrot's Ixx register or some compact representation in the case of arrays.

Worse,

my int $x = foo();
my int $y = bar();
my int $z = $x + $y;

Here, we don't even know if we're dealing with integer addition! If $x is a URI, then hold on to your seat and enjoy the ride, but you're not going to be sure of the result.

We know, for you have used explicit int (not Int, mind you). Please read Apocalypse 2 by Larry Wall:

"[...] there will also be lowercase intrinsic types, such as int, num, str and ref. Use of the lowercase typename implies you aren't intending to do anything fancy OO-wise with the values, or store any run-time properties, and thus Perl should feel free to store them compactly. (As a limiting case, objects of type bit can be stored in one bit.)"

I am not aware of any changes to this decision but I might not be up to date with everything posted on the mailing lists. Could you please quote the relevant portion of some later text you are basing your knowledge on? Thank you. And excuse me if I had spread misinformation.

Re:You disagree?

[ajs]

You are correct... most of the time, and Larry corrected me on part of this. But even then, you're not REALLY dealing with an int, you're dealing with a PMC that stores an int along with garbage collection information, a vtable that keeps track of how to modify it, etc. The JIT might find a way to optimize it down to a hardware int in some circumstances, but I would not hold my breath.

Really?

[Pan T. Hose]

But even then, you're not REALLY dealing with an int, you're dealing with a PMC that stores an int along with garbage collection information, a vtable that keeps track of how to modify it, etc.

Really? I thought that the whole point of integer registers in Parrot was to not use PMCs (and the overhead thereof) for integer (and floating point, for that matter) computations, wasn't it? Aren't vtables used for PMCs only? Otherwise I wouldn't see much point in having separate sets of registers and in fact wouldn't see Perl's future in any computationally sensitive environment which I was really hoping to use it for and which I am only now starting to realize how utterly naïve it might sound for anyone knowing Parrot internals. As much as I hate to admit it, Java starts to look better and better for number-crunching the more I know about Perl and Parrot internals, so all of those people I was trying to convince might have been right as it turns out. Thanks. How do you garbage-collect integer registers, anyway? Sorry for so many questions but it is always a good time to learn something. Thanks a lot.

Re:Really?

[ajs]

I thought that the whole point of integer registers in Parrot was to not use PMCs

Integer, string, and float registers are really for internal use by compilers. Anything that you expose to the user as a variable is going to have to go in a PMC. While it might be shadowed in an int register for performance, in most cases you won't be able to avoid the allocation of a PMC. At least that was Dan's take at the talk he gave on Parrot internals.

It's nice to say "this is just an int, I can tell that by looking at the code", but in many dynamic languages, you can pull the rug out from under such assumptions at run time, and Perl is certainly one such. Perl 6 in fact has a well defined way to walk up the stack and modify existing code, it's how you write "use" (remember all of Perl 6 will be written in Perl 6).

This is the price you pay for using a dynamic language.

That said, a PMC is only heavy-weight in terms of construction and destruction. When working with a PMC, there's just an extra pointer dereference that the machine has to make, so it's no more costly than the C:

for(p->i=0;p->i<10;p->i++) {
t += p->i;
}

Larry Wall?

[Pan T. Hose]

You are correct... most of the time, and Larry corrected me on part of this.

You mean Larry Wall? I didn't know he reads my posts... Thanks, Larry!

Re:Larry Wall?

[ajs]

No, he corrected me on the p5l mailing list on this same point. See my reply to another post in this thread for info on exactly how.