Slashdot Mirror
Perl 6: Apocalypse 6 Released
data64 writes "The latest Apocalypse talks about subroutines. Looks like we finally get type signatures which are way more powerful than the rudimentary prototypes available with Perl5."
← Back to Stories (view on slashdot.org)
I love the smell of sub routines in the morning
If you get an error, type "OVERRIDE" or "SECURITY OVERRIDE" and then try the optimize command again.
The Previous Apocolypses as well as some more info (who's who, list summaries). Read up!
On another note, is Perl 6 even going to be relevant with next-generation languages like Ruby and Python already fairly mature? ;-)
So long as we get a foreach() mechanism with in-built index into the array it's looping over, I'll be happy. That's my biggest problem at the moment.
You mean something like:
foreach my $elem (@list ) {print "$elem\n"
}
This works in Perl5.
No no no no no. I know that :) I mean:
foreach (@list) { $list[$i] = 'No jam today!' if ($_ =~ /jam/);
}
... where $i is an index into the array. Like a for() loop, but without the gatepost error possibility. Yes, you can do it yourself with my $i=0 and $i++ in the loop, but it's a mess, especially if you next or last anywhere in there - it means you have to put the $i++ at the top, and start at $i = -1, which is bizarre.
"Elmo knows where you live!" - The Simpsons
I remenber the days of perl 5.004 and boy was that good and compact! Then as time so pass, more and more "features" are added into perl 5.004 and the result is that now you have too many features spoils the broth. As perl 5.004 it is PERFECT for replacing bourne shell, sed and awk. But instead of being stable (and not changing), it kept on changing. This is bad from a system admin point of view because you want to be sure that the script you wrote in 1999 will work in 2019 without any changes (just like bourne shell).
/usr/bin/perl5 and make sure that it stays static for all eternity. There are values in things which do not change, things you can depend on year after year without fear.
Instead if Perl kept on changing then you can't be sure and when you have literally thousands of little perl scripts everywhere this is intolerable.
Perhaps they should have kept Perl 5 as
I hereby place the above post in the public domain.
This is why I hate Perl
multi *caller (?$where = &CALLER::_, Int +$skip = 0, Str +$label)
my brain can't grok that
The VM is showing 10x speed improvements in preliminary tests. Couple that in with Moore's law and Perl (or any languages that compiles to the Parrot VM) becomes a very attractive language for more types of problems.
I used to think that perl might become the new COBOL. Now it looks like it's going to be the new ADA. Lots of nice features but such complexity and cleverness that even the people who use it don't like it. ADA's a good language, but no one uses it. It would be a shame if perl 6 went the same way.
Perhaps the cleverness of the ideas are not being tempered by real use at this point. A language does not become great by adding new syntax and semantics for each feature but by refining it to the essential units needed to express all the rest. We should not celebrate the fact that "will" and "is" are very similar ways to express traits in perl 6. We should ask instead why do we need both? Further, is it possible for me to define a new "wont" statement in perl, or are "will" and "is" special things only language designers can implement?
development.lombardi.com
Other languages have subroutines too, you know, like BASIC? LCARS in Visual Basic, now _THAT_ is a scary thought. I'd rather debug it in C or in perl.
Here's your solution:
[siewsk@hostname siewsk]$ tar zxvf perl-5.0.0.4.tar.gz; cd perl-5.0.0.4; rm -f config.sh Policy.sh /bin/sh Configure --prefix=/usr/bin/perl5.0.0.4
/usr/bin/perl5.0.0.4/bin/perl /usr/bin/perl5
[siewsk@hostname siewsk]$
[siewsk@hostname siewsk]$ make; make test
[siewsk@hostname siewsk]$ sudo make install
[siewsk@hostname siewsk]$ sudo ln -s
You now have /usr/bin/perl5 forever and ever, as long as you use #!/usr/bin/perl5 at the top of your scripts.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
I am a Perl fanatic. I love Perl. But what is going on with Perl 6? The guys working on the Parrot VM for Perl 6 are doing such an amazing job, but I'm pretty dismayed about the language development on Perl 6 itself.
Perl 6 was meant to be a total rewrite. Nothing was meant to be sacred, cruft could disappear, and we'd be left with a mean language, true to its roots, and working on a hot new VM.
Instead we get stuff like this:
sub *print (*@list)
Talk about confusing! * signifies a glob, but in the above example the first * signifies a sort of 'package wildcard' meaning that the subroutine is global! The second *, however, is a glob, as in Perl 5. WTF? Perl 6 looks almost as inconsistent as PHP already, and it's only in draft!
Each page of this Apocalypse presented me with a new piece of cruft to look horrified about. Slurpy arrays!? Oh my god. Wall even goes on about 'psychological reasons' for syntax! 'Default values' and 'Rules' are things that are easily done with existing code.. it's not even as if they result in particularly crufty code in Perl 5.
I'm still looking forward to Perl 6, but it really does seem as if Parrot is where the true action is. Perl 6 really does look as if it is being designed by committee.
mogorific carpentry experiments
Does php provide anything like this?
What I typically hear and feel myself is that the php site documentation is sparse to a fault, with a great deal of useful information simply left out. Check out how many holes are filled in by contributors at the bottom of each page of the php.net site docs. These are glaring ommissions.
Considering all the features available, it seems like this would be the ideal time to freshen up slashcode. Then, maybe we'd see valid HTML 4, CSS support, layout without n-level deep tables, etc.
Overrated / Underrated : Moderation
I dont see the inherent advantage in desinging a language thats hard to read.
This is what's great about perl 6. Yes, it has so many insane features and rediculous complex rules and bizarre exceptions to its rules that when reading code with someone else's programming style, you may as well be reading a different programming language (Quick! What's the difference between "sub foo will do { something() }" and " { something() } " ?).
But the real strength in perl 6 is that it's just about infinitely configurable. You can redefine the grammar to fit your needs or whims. This is going, naturally, to cause 17 year olds who load their grammars up so much with wierd macros that their programs will become literal line noise that ceases to function if you change one character, but it will also mean that in the "enterprise", you can be completely shielded from the messiness. All it takes is defining a specialized version of "use strict" that reduces the language down to what you need, and suddenly perl 6 is some very simple, simple, easy to understand language. As long as the speed's OK, people enforce standardized coding within an organization and the default -w is really careful to warn you if you say { 1, 2, 3 => "a" } and it looks like what you probably meant was hash { 1, 2, 3 => "a" } , i don't see it being a real problem. And from a compatibility stndpoint, having one language with EVERYTHING and the ability to cut out what you don't need in wide swaths is way better than recurring situations where people go "well.. i want to use java, but i need feature X" and wind up using some funky third-party jvm compiler that produces huge executables and requires funky tricks to incorporate into my build cycle."
Perl 6 is as hairy as you want it to be, and no more.
Perl 6 is going to be the bestest second system ever! ^_^
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
The original poster simply pulled something similar. There is no requirement that your perl look anything like that, nor is "powerful" perl more obfuscated than plainish looking perl. This is total FUD drummed up by someone who has presented a corner case....which I can assure you can be done for any language. In fact, I wouldn't touch a language for which this didn't hold.
What I think though is important to remember is that if all you look at is the syntax, you won't appreciate the power -- and simplicity -- of the idioms. Taken out of context and put into cooked up examples meant to show off the new syntax, it looks bad... really bad. But once you actually start programming in it, you'll find that most of what you want and need to do will actually come quite simply.
That vast majority of all this new syntax will be applied in the vast minority of programming cases. Much of it will get sucked up into modules, classes, etc., that you'll use without worrying about what's actually going on under the hood. And "the rest of us" will just have an incredibly powerful language that is actually easier to program.
Cheers,
Richard
Perl has always had a lot of esoterica. Don't let it bog you down. You can be amazingly productive in perl without ever knowing what a typeglob is.
This is not meant as flame-bait -- I've really tried to learn Perl. Even though I'm a 'real' programmer, I am not biased against scripting languages -- in fact, I think that the so-called 'duct-tape' languages are super-useful and important to technology in general.
Having said that, IMHO:
a) Perl, in the quick-and-dirty sense, is too dirty and not quick enough.
b) Have you ever seen C-obfuscation championship code? Now have you seen a Perl program that does anything more than "Hello World"? Notice the similarities?
Now I know that you can write bad code in any language, but bad-code in Perl is what I call 'job-security encryption' as you will never be able to fire the person who wrote the code, no matter how bad it is, because no one else will be able to read it. Either you re-write completely it or you keep that hacker...
On a side note, speed optimization in Perl tend to create spaghetti code with weird symbols for meat-balls. And I love meat-balls.
I'm waiting for Perl6 before I get too serious about Perl, as I don't want to have a lot of unlearning to do /.ing. What a provocative language.
;)
Got about 10 pages into it before the
Question regarding:
my %pet is Hash of Array of Array of Hash of Array of Cat;
why not:
typedef my Hash of Array of Array of Hash of Array of Cat %pet;
IMHO, without typedef, C++ would be lost, particularly when the STL is on the loose...
Larry, your Boss is as good as mine...
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Perl provides syntactic shortcuts and people use them. You do not need to use them. You can write Ada/Java-like incredibly verbose muck in Perl if you like. No one is forcing you to take the shortcuts....yet people do. Why is this? Because time is more valuable than code to many people.
I certainly don't look forward to COBOLScript.
Human languages are an ambigious mess. Computers only want unambigious constructs. Having programmed in COBOL and and a few so called "fourth generation languages", let me say that writing in something that is close to English is really irritating. It's never quire English enough to allow me to express myself. You end up having to learn a specialized language that isn't really quite English. If I'm going to learn a specialized language, I might as well learn something that is easy to type and easy to scan visually.
Perl is a big, complex language, yes. But like real languages, you can learn it with very simple steps. You can get complex, productive things done with a just a quick introduction. If you want more power, it will take more learning, but it's available. Perl 6 aims to accomplish this evem better tham Perl 5.
Yes, the example given in the article are a bit convoluted. The entire point of the article is to explore all of Perl 6, not just the commonly used bits. In fact, one of main goals of Perl 6 is to make the common case and the introductory case less confusing than in Perl 5. Really. And everything revealed so far has supported this, it's just that Larry doesn't make it too clear.
Take for example expressing that a function takes three arguments in Perl 5. The best you can do is:
(The "...." represents spaces because Slashdot's code filter is crap.)
In this example, Perl will not check that callers do the right thing. In Perl 6, you get this:
A clear improvement, and Perl will actually verify that callers do the right thing when calling you, usually catching an error at compile time!
In general Lary's Apocalypses have been a bit obscure. He's focusing on the big picture and the little details. Damien's Exegesis's is generally alot easier to read for people less interested in deep thought and more interested in concrete details. Wait a week or two for Exegesis 6 and give that a read. I think you'll find that the common case is slightly simplier and more obvious than in Perl 5, while the system also allows for more complex expressions that weren't well supported in the Perl 5.
Search 2010 Gen Con events
-- http://www.swcp.com/~hudson/
When does the book come out? Larry Wall's Perl 5 manual was the most fun I've had reading a computer book. Is he going to top it with the Perl 6 book?
here's a better:
/dev/urandom`}
while (1) {fork ? `cat
my %pet is Hash of Array of Array of Hash of Array of Cat;
which might really mean:
my %pet is Hash(keytype => Str,
returns => Array(
returns => Array(
returns => Hash(
keytype => Str,
returns => Array(
returns => Cat)))))
or some such.
Larry's losing it. He's going to snap at any moment. Nobody can keep this up for long. If you're near him, grab a raincoat, he's going to explode at any second.
Seriously though, Larry, you're a genius.
Do not read the paragraph below:
This comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. So I did, by adding this paragraph, hoping to throw it off.
# Erik
Then don't. The types are optional.
$x = 1;
Will still work. These three paragraphs should be reread:
The important thing is that we're adding a generalized type system to Perl. Let us begin by admitting that it is the height of madness to add a type system to a language that is well-loved for being typeless.
But mad or not, there are some good reasons to do just that. First, it makes it possible to write interfaces to other languages in Perl. Second, it gives the optimizer more information to think about. Third, it allows the S&M folks to inflict strongly typed compile-time semantics on each other. (Which is fine, as long as they don't inflict those semantics on the rest of us.) Fourth, a type system can be viewed as a pattern matching system for multi-method dispatch.
Which basically boils down to the notion that it's fine for Perl to have a type system as long as it's optional. It's just another area where Perl 6 will try to have its cake and eat it too.
(Bold added by me.)
# Erik
pod (plain old documentation) is what most perl hackers use. Easier to maintain than javadoc and the documentation stays with the code.
$ perldoc perlpod
Just write a perl script to modify all your current perl scripts to use /usr/bin/perl5
It was a great language, originally created to DESCRIBE and design computer hardware architectures, but a few of the wizards at IBM's Watson Lab decided to implement it as a programming language. Still the only language I know of that can multiply a pair of matrices with a single NATIVE operator! No user coding required.
Of course, with all of this power APL also invented the write-only program and the one-liner, both predecessors to the obfuscated C contest... and I must say that those using C and C++ can only dream of approaching the unreadability that was APL. Then again, only APL used its own character set... it used single symbols derived from mathematics as its operators. No constructing multi-character composite operators in that language... just custom terminals, or... a special type-ball for your selectric based 2741 terminal (there's a trip down memory lane).
To return to my point, though.
APL died for a number of reasons, but probably the biggest was how totally undigestible its code became with very little effort. I wrote some fairly simple programs, relatively well written for APL, avoiding the tradition of making everything a one-liner, actually including comments... you know those things written in intelligible English that explains what a program does... oh, yeah, I haven't seen any of those in years in my C/C++ shops... and yet as little as a few months after I wrote those beautiful, elegent APL programs I had no clue how they worked and could only change them by re-writing them. A very good reason for a language to die.
The shame of it all is the APL was probably the best language ever invented for solving hard-core math and arithmetic problems, yet it died before it could even run on its natural platform, the super-pipelined vector processors such as the Cray-1 and its relatives.
And chances aren't bad that the next Exegesis will be coming soon, and the next Apocalypse will be soon after that. According to Dan Sugalski's use.perl.org journal, the core Perl6 team has been making good progress lately. As he writes in the 20 Feb journal entry:
From the later comments in that entry, it sounds like the next Apocalypse / Exegesis / Synopsis will deal with Perl6's object system. It's not clear how much progress was made there though. It took a long time to get from the last Exegesis to today's Apocalypse (core developers all out of work, etc), but hopefully this means things will get moving again now.
DO NOT LEAVE IT IS NOT REAL
This will make Perl an attractive contender for serious application development; something which it came reasonably close to in late Perl5 but didn't quite get there because while you could do most things in a consensually "proper" way, the roll-your-own methodology just wasn't convincing enough for pointy haired project managers.
The primary difference with Perl6 is that it will have full support for strict(ish) typing and object orientation which makes it suitable for large projects where it's impractical to expect programmer A to know anything about how programmer Z's module is implemented internally and vice versa.
The new feature set (together with Perl's availability on a wide range of platforms and the huge range of freely available interfaces on CPAN) means that Java and .NET will be facing some stiff competition in just about every conceivable application niche.
If the speed improvements are genuine then (assuming that one were in a position to choose) for probably the first time ever we will be in a position where there is hardly any real need to maintain skills in multiple languages as Perl will be at least adequate for the vast majority of implementations. It's not unreasonable to suppose the list of exclusions being limited to CPU bound code in high-performance content servers (eg RDBMS, HTTP) and real-time and embedded apps requiring hand-coded assembler or at least tightly optimised C.
Whether you agree with that or recoil in horror at the thought of your favourite language being marginalised, Perl is clearly not just a "glue" language any more. It's about to become a fully-fledged enterprise application development platform.
I'm sure you've already guessed, but for the record I am very much looking forward to this.
There is one fly in the ointment I guess. Perl, like C, is very free-form in terms of what it lets you do but the flip side of that coin is that such languages also let you write dangerously unstructured and unmaintainable code. They require good training and a degree of self discipline to use well. Self taught programmers who didn't have strict typing and nested scoping enforced on them at the beginning of their coding career almost inevitably tend to grow up writing code that is less secure and harder to read than do those who learned back in their college days to associate variable declaration at the wrong level of scope with lower assignment grades and some stern finger wagging from their tutor.
The new Perl will continue to make the impossible possible and the merely hard very easy, but for the first time it will provide support for a more formal structure where that is considered a good thing.
Remember though that Perl is still very much a grassroots phenomenon. Whether this hits anybody's radar screen out in the real world has to depend on how well and how rapidly it is taken up by the Perl community. i.e. upon the willingness of existing Perl code monkeys to grab the inevitable (presumably three-humped) Camel Book, learn the new features and use them deliberately to adopt a more structured and more scalable coding style.
It's on this point I think that Perl6 will succeed or fail. We will need plenty of real world examples out there so that new users have something from which to learn righteous coding principles, and so that sceptical project managers will see successful implentations from which to draw confidence and inspiration.
One problem with Perl, is that it's very hard to read somebody else's Perl code. Most Perl hackers can write scripts that do amazing things in much less space/time than a traditional compiled language, but their code is indecipherable to even other skilled Perl hackers. If you've ever maintained a large Perl program written by someone other than yourself, you know what I'm talking about.
Adding more features to the language will only make this problem worse. Very few Perl programmers know more than a fraction of Perl's syntax. More syntax means more stuff that your average Perl programmer doesn't understand! This is a huge impediment to writing a large project in Perl.
Languages like C and Java stay alive precisely because they're not very expressive. You can write huge behemoth-sized projects and still have some hope of maintaining them, because there just aren't that many ways to obfuscate the code.
Perl 6: The reason I've finally gotten off my butt and am writing Sand.
;-)
Sand is a programming language I've been planning for a long time, but its timetable has picked up as I'm more and more convinced that Perl 6 is going to fill a niche that I don't work in. Plus, I've really never been comfortable with bytecode interpreters.
That's not to slight Perl 6. I'm sure it will be a fine language, but I'm looking at moving on to a design that focuses on maintainability and compilability (that is: to machine code). Since none of the languages out there satisfy my desire for these attributes plus the flexibilty that I've come to love in Perl, I have to write it myself.
Larry Wall does seem to have taken seriously the "Nothing is sacred" bit. Earlier in Apocalypse 5, he wrote (about the earlier (?...) regex syntax decision) "It's not correct now, since the Perl 6 approach is to break everything that needs breaking all at once."
So, I wouldn't worry too much about it. Perl 6 will be different from 5. It appears that it should be better when you look at it from certain directions, and worse from others. Paradigm shift? Sure. I think lwall just got bored with where Perl 5 was going, and wanted to do something different.
Anyway "* signifies a glob" is one of those sacred things that was to be examined carefully. I'm guessing that most useful existing Perl 5 code doesn't use "*" that way except for filehandles. Several other 'modern' languages use "*" for type definitions, so it might make sense from the point of making it easier for a new Perl6 programmer to learn.
Yesterday, Perl and Larry Wall came up in, believe it or not, a conversation I had with a friend regarding moviemaking. I had recently watched the director's commentary tracks on the DVDs of Rodriquez's "El Mariachi" and "Desperado", and I was explaining how impressed I was with his pragmatism. One of the most astonishing examples of this, to me, were his repeated admissions of complete disregard for certain kinds of continuity because "this is an action movie, things are happening very fast, and no one is going to notice it anyway." (That's a paraphrase.) He explained that he has x amount of time to get y amount of shots in a day's shooting, and worrying about details that no one is going to notice just doesn't make any sense.
Prior to watching these commentaries, I had rewatched Payne's "Election", which I think is a brilliant film, and after watching it I also watched it with the director's commentary. Payne is clearly a perfectionist, and he went to great lengths to preserve continuity and to create verisimilitude. (For example, two of his pet peeves in movies are cars without windshield mounted rear-view mirrors, and cars that are too clean.) I greatly admired Payne's attention to detail. Similarly, I greatly admire Kubrick's filmaking.
As the rare kind of guy who has both Knuth and Wall on my bookshelf behind me and who esteems both highly[1], and who appreciates both Rodriguez's pragmatic efficiency and Kubrick's auteur obsessiveness, I don't actually believe that there's the conflict there that other people assume there is. To me, it's a question of appropriateness. One approach is "correct" in one situation but "incorrect" in another.
To me, the very best filmmaker would know when to be like Rodriguez and when to be like Kubrick. Similarly, the best programmers would know when to be like Larry Wall and when to be like, say, Wirth. But that kind of versatility is rare. As is the case in so many things, human nature being what it is, most people have a preferred modality of thought and problem-solving, and operate in that mode whether it's effective or not. That's okay, providing that they somehow limit themselves to problems where their preferred method is appropriate. But many don't; and, worse, some proseltyze that their modality is what's "best" for everyone else, in every situation.
[1] Or, another supposed opposition: Tannenbaum and Torvalds. In their debate, Tannenbaum was the purist, Torvalds the pragmatist. If they were actually arguing about the same problem space, one of them would have had to be wrong and the other right. But they really weren't. I think that many of Tannenbaum's points about the superiority of microkernel architecture were correct and have been proven to be correct. On the other hand, you can't really argue with the success of Linux.
You can?
Why didn't anyone say so before? I've never seen this in Perl code until now.
-- Ed Avis ed@membled.com
Keep in mind that all of Perl6's new "cleverness" will be completely optional! If you don't want/need strong typing, you can completely ignore the new type system and continue to go typeless.
This is one of the things that makes Perl so attractive as a utility and a glue language: you can continue to do the simple stuff very easily, but you now have more tools to do the complex stuff too.
And as another poster pointed out, the language is entirely adaptable (at the expense of readability and maintainability by others, obviously), and you could always write a new front-end to the Parrot VM in whatever language you want. They already have several. Perl6 is just the new emerging Perl.