Perl 6 Essentials 172
| Perl 6 Essentials | |
| author | Allison Randal, Dan Sugalski, and Leopold Totsch |
| pages | 208 |
| publisher | O'Reilly |
| rating | 9 |
| reviewer | Jay Bonci |
| ISBN | 0596004990 |
| summary | A solid look ahead at Perl 6, and a reference for Parrot developers |
Make no mistake, Perl 6 isn't here yet, but it's coming. The book starts with a good explanation of "the plan"; chapters 1-3 deal with the history, goals, and design considerations of the project. It's a good conceptual overview of the process about how it has been run so far, and how it seems to be continuing. Chapter 3 is of special interest, as it showcases some of the in-depth thought that has been poured into the project. Though we all aren't language theorists, it helps allay some of the fears that change brings while being completely fascinating reading.
This first part of the book isn't very useful without a fairly solid Perl 5 background. It wastes no time in chapter 4 discussing syntactical differences in the v5 to v6 transition. Programmers should be pleased with the practicality of the approach to the new language, as it refers to the new structures and features, and how they solve simple workarounds that Perl veterans are used to in Perl 5. Currying, multimethods, class definitions and structures, new operator syntax, and the dynamics of the new regular expression engine (now called rules) are all touched on, and their values made obvious to the reader.
The last three chapters are for those interested in Parrot development and those who wish to port languages to Parrot. (There are active projects to port Python, Ruby, and even .NET to Parrot.) The section has a slight perl slant to it, but is really about the interpreter and compiling / running Parrot code. It is a fairly complete reference to the different parts of PASM (Parrot Assembly Language), and its role in porting languages to use Parrot. A comfort with assembly language basics is assumed in these sections, as the syntax and concepts of registers and machine code are made easier with general assembler familiarity. This part was somewhat dry for me, as it reads more like a reference than anything else, but it covers the topic fully without droning or leaving anything out. Examples are abundant and range from the simple, to the integrated, and are enough to get people started programming and writing tests with Parrot bytecode.
It should be noted that this book is valid and accurate now, but any development project can make changes quickly. There are places where the authors have admitted that a feature isn't in stone, and is possible to change. According to chromatic, an editor for O'Reilly, the plan is to update the book once a year until Perl 6 is released. Until then, a great place to keep up to date for the casual observer is at the p6p digest. This book goes down a lot easier than the Apocalypses, RFCs, and Exegeses, and I'd heavily suggest it to anyone who is serious about being ready for 6 or joining in on development . I preordered it from Amazon when I saw it was coming out, and am quite happy with my investment.
Table of Contents- Project Overview
- The Birth of Perl 6
- In the Beginning . . .
- The Continuing Mission
- Project Development
- Language Development
- Parrot Development
- Design Philosophy
- Linguistic and Cognitive Considerations
- Architectural Considerations
- Syntax
- Variables
- Operators
- Control Structures
- Subroutines
- Classes and Objects
- Grammars and Rules
- Parrot Internals
- Core Design Principles
- Parrot's Architecture
- The Interpreter
- I/O, Events, Signals, and Threads
- Objects
- Advanced Features
- Conclusion
- Parrot Assembly Language
- Getting Started
- Basics
- Working with PMCs
- Flow Control
- Stacks and Register Frames
- Lexicals and Globals
- Subroutines
- Writing Tests
- PASM Quick Reference
- The Intermediate Code Compiler
- Getting Started
- Basics
- Flow Control
- Subroutines
- IMCC Command-Line Options
- IMCC Quick Reference
You can purchase Perl 6 Essentials from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
slashbot book review (Score:2, Informative)
Re:Off Topic but figure I would ask your perl guys (Score:3, Informative)
If you are looking to convert perl source into java source, then you are probably totally out of luck though.
Re:Off Topic but figure I would ask your perl guys (Score:1)
Re:Off Topic but figure I would ask your perl guys (Score:2)
You wouldn't want non-OO Perl being directly converted into Java equivalence anyway-- the whole point of OO design is to abstract things and make it easier to maintain and modify the source code after it has been created (software engineering practices). A sloppy program-ported version of your Perl code into JSP or whatever would probably be a NIGHTMARE to support.
Re:The Superiority of PHP over Perl (Score:3, Informative)
>can't create Node classes, for example, usefull in a linked list) and
>because it lacks pointers. Some of you may notice that PHP lacks
>pointers, but look deeper! Behind the scenes, hidden from the user
uh.. some might even notice that Perl does NOT 'lack ponters' -
what do you think all those \$a, \@b, \%c are ????
sigh...
Re:The Superiority of PHP over Perl (Score:2)
Re:The Superiority of PHP over Perl (Score:1)
Well, this seems to be the main reason behind all those "Perl is unreadable" complaints:
People who don't know Perl have more trouble reading Perl code than people who don't know, say, Python, have trouble reading Python code...
Re:The Superiority of PHP over Perl (Score:1)
complain that the language is "strange". If
I know Chinese, I would insist that the language
is just natural.
Perl takes years to learn. That is why it is
so powerfull. Can you imagine how usufull
French would be if you could learn French withing
days? Simple languages are practically useless.
Re:The Superiority of PHP over Perl (Score:1)
Perl takes years to learn. That is why it is so powerfull. Can you imagine how usufull French would be if you could learn French withing days? Simple languages are practically useless.
I was trying to say just that. I was criticising people who don't know Perl yet depreciate it because it looks "stranger" to them than e.g. Python looks to people who don
Re:The Superiority of PHP over Perl (Score:1, Funny)
Random selections of characters aren't they ? Oh shit, we're talking Perl arent we
Re:The Superiority of PHP over Perl (Score:1)
Re:The Superiority of PHP over Perl (Score:1)
You're full of it it! \$a isn't a pointer, it's a reference... Oh wait, nevermind. :-)
Re:The Superiority of PHP over Perl (Score:5, Insightful)
Perl is vastly superior to PHP for these core reasons:
*Perl is more standardized, due to it's greater history.
*Perl is installed on a larger variety of systems and comes in some version on almost all unix systems
*Perl has better DB support, DBI & it's associated DBD modules, it doesn't rely on DB-specific commands, it uses a standardized Database Interface module thus making porting between DB servers exceptionally easy.
*Perl has structures, objects, plenty of OO support, it's not wonderful but I can accomplish anything I need. Nested Hash Tables are a true god send. Complex data structures are easy in Perl, not so in other languages.
*Perl has better string manipulation
*PHP used Perl as part of it's basis
*PHP embeds itself into HTML which violates the OSI model for programming, by not abstraction the presentation layer.
And so on...
I'm too tired.. someone else finish this punk off.
Re:The Superiority of PHP over Perl (Score:2, Interesting)
"* Perl is more standardized, due to it's greater history."
Not really sure of the point you're trying to make here. Niether project really has a standards body behind it. Perhaps you mean Perl is more accepted.
"* Perl has better DB support..."
Granted, although PHP provides a DB abstraction layer in Pear now, which all good PHP coders should be using...
"* Perl has structures..."
Some would say this
Re:The Superiority of PHP over Perl (Score:1)
Re:The Superiority of PHP over Perl (Score:5, Funny)
- Don't forget that Perl is bright blue, while PHP is dark green. If you have an aversion to bright blue, you should definitely code in PHP.
- Three out of four gnomes script their underwear-cart code in PHP; Perl gets sticky on hot days.
- Perl behaves badly under zero-gravity conditions; PHP will actually make your computer lighter. The benefits of this should be obvious to everyone.
Really, there's no competition. PHP is the obvious choice - and its emissions are less fattening, too.
I Too Have Switched (Score:1)
What I miss about Perl is being able to write obfuscated spagetti code so unreadable that I had no idea how the code functioned 3 months late
Re:I Too Have Switched (Score:1, Flamebait)
Sounds like you should try out Python.
Re:The Superiority of PHP over Perl (Score:1, Informative)
* Ease of use. I knew Perl before I tried PHP, so I can't really say which is easier. Both were very easy because I knew
Re:The Superiority of PHP over Perl (Score:1)
Re:The Superiority of PHP over Perl (Score:1)
So barring expertise in the subject, people are not allowed to post their experiences of a given language? Interesting. Let's discuss your knowledge of the following language: English.
By all means, fish where you like.
Don't you hate condemming posts full of asinine errors?
cheaper (Score:2, Informative)
Even cheaper than that! (Score:1, Redundant)
http://www.bookpool.com/.x/t2y2rmrlx8/ss/1?qs=per
$15.50USD
Where's the BitTorrent Link? (Score:1, Troll)
Even cheaper than amazon (Score:1)
Perl 6 plan over three chapters? (Score:2, Funny)
So that's what... like 100 pages of the string "Smoke crack" repeating?
print "Smoke crack" x 1000000 .. hey, that was pretty easy.
Cheaper at Bookpool (Score:5, Informative)
They're also doing a free shipping deal.
Re:Cheaper at Bookpool (Score:3, Informative)
Besides it shows that there is a "used" copy on amazon for $12.99.
Re:Is there anyone out there (Score:1)
I don't absolutely hate it, but I think that it is pretty bad. I wrote pretty readable perl when I was active (I like to think), but you could do some really horrible stuff.
I particularly don't like the automagic variables springing up all over the place and don't get me started on "bless" and the class system.. gha... I've even had it commented to me that I could use $_ where in fact I had opted to be explicit, which really irked me. "You want me to make the code less readable?"
And all that bullshit ju
Re:Is there anyone out there (Score:5, Insightful)
If, in response to your message, I say "You obviously never knew perl very well to begin with", it is very easy to use the context of this post to know that "You" refers to the author of the post that I'm replying too.
In the same way, in a statement such as
foreach ( @array ) { print }
It is extremely obvious, to anyone who actually knows perl, what "print" is refering to.
Saying "you can do some really horrible stuff" in Perl in fact tells me that you probably don't know much about programming, at all. You can "do horrible stuff" in *any* programming language. Over the years I've seen more than my fair share of horrible C, C++, Java, Ruby, Python, Smalltalk, PHP, and yes, even Perl.
I currently am working on a Perl project that is up over 250,000 lines of code, and has been in development for two years. The code is all maintainable, and easy to understand, even for new people starting on the team with no prior knowledge of the code.
Maybe you just suck.
Mod parent up! (Score:3, Interesting)
Absolutely true. People are always complaining that Perl alows a person to write obfucated code. What about C? The C programming language allows a person to write obfucated code as well. In f
Re:Mod parent up! (Score:1)
'C' (and to some extent C++) is just as bad - if not worse. I spent 10 years working in 'C'/C++ and when I was working with it I thought it was the best thing ever. It's only
Re:Mod parent up! (Score:2)
Umm... if you're in a project that has 250,000 lines of code, and you *don't* have a "good development process in place and good common practice amongst your programmers", you're already a lost cause. The language the program is written in probably won't make much of a difference...
Re:Mod parent up! (Score:2, Funny)
Re:Is there anyone out there (Score:3, Insightful)
The only thing that's obvious to me is that the code example you gave is a poor way to write "print @array;" The urge to be clever is way too prevalent in Perl.
Re:Is there anyone out there (Score:2)
Re:Is there anyone out there (Score:1)
Re:Is there anyone out there (Score:2)
Re:Is there anyone out there (Score:2)
Rate foreach print list
foreach 107043/s -- -82%
print list 592417/s 453% --
It's 5x faster AND more readable to use print LIST. If you want to persist in the delusional use of overly clever constructs without a good reason, be my guest, but you are just making your life more difficult along with the lives of anyone who has to use or maintain your code. BTW, none of this shou
Re:Is there anyone out there (Score:2)
come on. get a hold of yourself.
Re:Is there anyone out there (Score:1)
Sorry, wrong. (Score:4, Insightful)
Haha (Score:2)
Re:Is there anyone out there (Score:1)
OK then: print for @array; #the idea here is that we're printing something, not that we're doing something with each element of an array, so let's get the print at the front if we can.
To my way of thinking, changing default values of those kinds of global values (like $,) is a bad idea and should be confined to very specific blocks as needed by using local. That way people can use built-in functions in other pieces o
Re:Is there anyone out there (Score:3, Informative)
Have you tried 'use strict'?
What's wrong with bless? It's just a way of telling Perl what class an object belongs to. Any OO framework needs something equivalent. C++ does it at compile time, but I think the Perl approach is cleaner because a distinct keyword (bless) performs a distinct operation (marking the class of the object.)
Re:Is there anyone out there (Score:4, Insightful)
now that that's out of the way, I like Perl because it gets the fuck out of my way. once you've got a grip on the syntax (which, despite the whines of those whose brains have been dulled by Python syntax, is uncomplicated and consistent), programming in Perl becomes like writing pseudocode. easy. it reminds me of programming in BASIC back in the day -- carefree.
not like Java, where you're plowing through Java In A Nutshell to find the right class method to do what you need every other line. not like C, where you're walking a tightrope between null pointers and memory leaks the whole frickin time. in Perl you write what you want the program to do, and it does it.
in other words, it's a high level language, as opposed to being one or two steps above asm.
Re:Is there anyone out there (Score:1)
In other words it's still way too low level language, just two (only two!!!) steps above asm, while most of programming languages I know and use are thee or more steps above asm.
First of all you admit about Perl's bad syntax by yourself. From this prospective, Python is one step above Perl (means 3 steps above asm), as its syntax lets a Python programmer to complete the target program much faster then Perl to Perl
Re:Is there anyone out there (Score:2)
However, for a software application (and this includes web applications) I've contended that scripts suck. This definitely includes Perl. I don't care what Yahoo or Google is doing with Python or PHP, and I don't want to get into those particular cas
Re:Is there anyone out there (Score:2)
in other words, it's a high level language, as opposed to being one or two steps above asm.
But as a functional language, Perl lacks structure, but makes up for it's very free form nature. Just today I was converting a query from Perl to C. Perl's version of the query was approx 150 lines. C was close to 1000.
I'm learning Python now, so I can get a high level language with a bit more structure(i.e. datatypes are much more explicit). I'm aware that Perl has objects too, but it seems to me it was never a
Re:Is there anyone out there (Score:1, Insightful)
And what are the goals of the Perl coders who wrote that garbage? To combat reverse-engineering and theft of code by unskilled script kiddies, some use obfuscators for deployed code while keeping easier-to-maintain versions private. Almost but not quite like keeping C/C
Parrot started out as a joke (Score:5, Informative)
Parrot started out as a joke, and is still a joke (Score:2, Interesting)
Re:Parrot started out as a joke, and is still a jo (Score:2)
Tell you what - give me the $200,000 that they've been given and I will write the Perl6 interpreter for them.
How will you write the interpreter for a language that is still being designed? This may be part of why Parrot is going nowhere...there is nowhere well-defined to go!
Re:Parrot started out as a joke, and is still a jo (Score:1)
But it's here, now. Arguably one of the most cross-platform, complex Open Source application. Just have a little faith with Perl 6. You might not like it, but many will, just like mozilla.
Re:Parrot started out as a joke, and is still a jo (Score:2, Interesting)
start small and then pickup exponentially? Debian
had less than 70 develpers for several years,
today there might be 1000 developers. Or, how
about testing the the 2.6 kernel? Most people
do not test the kernel until the release date
gets closer, at which point traffic and bugfixes
also increase exponenttially.
Re:Parrot started out as a joke, and is still a jo (Score:1)
(Please correct me if wrong). As for Perl6,
it is impossible to judge ahead of time, unless
of course, you are too eager to spread FUD, much like Caldera,
and you keep your reasons a secret.
I have taken the trouble to study the Perl6
features, and I even know Parrot Assembly, not
to mention that many Perl6 features have
been available as Perl5 for years! I am still
waiting to hear why the project is ill conceived,
which unlike Topaz, it en
Re:Parrot started out as a joke, and is still a jo (Score:1)
there was an attempt to rewrite the kernel
in C++. Although that attempt was a failure, did Linux
turned out to be a failure?
We will judge when it arrives. I am just suspisious
of people who arrive to speak ill about other
people's projects before completion, especially,
when these people have a prior record
of achivement.
Big surprise, another postive book review (Score:4, Insightful)
Not really, but what does NOT come as a surprise to me is that we have yet another glowing book review with a bn.com affiliate link. I've seen far too many glowing reviews on this site, about books that I know to suck donkey balls, to trust the reviews here anymore, especially knowing that readers are more likely to follow affiliate links when the review is positive than when it is not (And this from the same site where people so often rip stock analysts for writing glowing reviews of companies that garner their firms big i-banking fees). I wouldn't trust a movie review if I knew the reviewer was getting paid every time people went to saw the movie, and this is almost the same thing. Maybe Slashdot should put up a disclaimer...
If I see a book whose title sounds remotely interesting reviewed here, the first thing I do is go directly to amazon, and check out their user reviews. At least there you'll potentially see a bunch of negative reviews, instead of a chapter summary and a "this belongs on every Perl/PHP/Mysql/Linux geek's bookshelf".
Re:Big surprise, another postive book review (Score:2)
About positive reviews,
(1) 90% of everything is crap, so why publish that many negative reviews? Publish the "wow, this was surprisingly helpful." Unless it's a hyped bestseller that failed to deliver the promised quality, don't publish the whining diatribes (see below). Infer that if you haven't seen a review, it's probably Sturgeon-bait.
(2) This site allows replies with almost the same prominence as the original. If you think it doesn't live up to the review, then post your specific opinion to it
Nothing is as it appears... (Score:1)
Write a glowing review, and post a link and watch the balance in your affiliate account grow! What's wrong with making some spare change on the side? Except, the original review is tainted - it can't be objective because the author has something to gain.
Did you know that many retail stores make more income off the interest on th
I have reviewed this book for my site in the past. (Score:1, Interesting)
Perl 6 release date? (Score:5, Interesting)
So, how many editions should we expect?
Re:Perl 6 release date? (Score:2, Informative)
My guess is two more, though the more people who contribute, the sooner Programming Perl 6 will be released.
Re:Perl 6 release date? (Score:1, Funny)
I think Fred Brooks might disagree with that statement.
Re:Perl 6 release date? (Score:1)
I'm willing to try parallelizing development a little more. If Mr. Brooks wants to send in good patches, I'll apply them whatever his philosophy.
Re:Perl 6 release date? (Score:4, Informative)
Reasons I think this:
* Parrot Progress. The Parrot team clearly believes Parrot will be in good shape by next summer, to the sum that they've wagered that Python will run faster on Parrot than it does under it's current implementation by next OSCon, or the Python team gets to hit them with cream pies. I'm willing to accept that level of confidence to imply that Parrot will be up to the task of being usable to develop things onto by next year, and quite polished by 2005.
* Ponie (ie, Perl On New Interpreter Engine, ie perl5 on parrot): Someone (and my brain is fuzzy from being sick recently, sorry) is paying two competent developers to work half-time on Ponie for the next two years. Now, timeframes are often very hard to predict going into a project, but the goal is clear: Ponie for OSCon 2005.
So, with those critical building blocks in place, and judging by the fact that most of the hard design work is done (and looks very nice), it's just a simple matter of programming. (That's a joke.) I don't expect Perl6 to beat Ponie out the gate, but there's so much potential synergy between the projects, I boldly predict Larry Wall announcing Perl6 available in a stable version for OSCon 2006.
There's clearly a lot of speculation in this line of thought, and it's not like anyone really knows the answers. I like to think it's at least informed speculation, though. And I'd like nothing better than for it to be done sooner. I'd almost recommend people to _not_ check out this book - the design is so good, I've already come up with at least a dozen places in my code where I've wanted to use a perl6 feature that doesn't exist in perl5.
There's lots of ways to help - coding, design, doc writing, testing - as well as the more indirect method of donations to The Perl Foundation. Which ends up helping some of the key developers (like Larry Wall) work on Perl and still pay his bills and keep his health up.
We're attempting to convince our company to make a donation to the Perl Foundation, given how much we use it for our business. I heartily encourage similar efforts - $500 isn't much for a company, but it can add up quickly.
PONIE supporters (Score:2)
Ripoff (Score:2, Informative)
Re:Ripoff (Score:2)
Back to the Future (Score:4, Interesting)
Development of it is taking a long time but it has been worth it.
Some peoples minds don't seem to fit Perl 5 quite right and complain about it. Should have a lot more options of languages and style in P6.
Its a blazingly fast byte code interpreter. Having this Open Source is a very powerful thing and something many projects will find useful.
Re:Back to the Future (Score:2)
Is that supposed to satisfy any complaints?
Re:Back to the Future (Score:2)
To clarify that: I believe it will be better style, more modern and more of what many other languages use.
Obfuscating it up more wouldn't do anyone any good. Although it certainly looks like there will be a fair amount of obfuscation in P6 (it is Perl after all), Parrot is squeaky clean.
Re:Back to the Future (Score:1)
Perl has lots of weak points, especially when
compared to real languages like Lisp. But modularity
is not a weak point of Perl; if anything, there is
too much modularity. Even OO is modular, exceptions,
IO, overloading, etc,.
Now that I have postted with specifics, do you
mind telling us what is not modular in Perl?
O'Reilly naming conventions (Score:5, Informative)
Understanding O'Reilly titles can help you decide which blue book(s) to purchase. Just as they have conventions for the books' color (e.g. Perl blue, Java purple, security yellow), O'Reilly and Associates has conventions for the titles.
* "... Essentials" means an overview of what's new.
* "Learning
* "Programming
* "... Cookbook" is a series of problems and their solutions
* "... in a Nutshell" is like a language reference
* "... Pocket Reference" is a shorter version of the above
Barely about Perl. Certainly not essential. (Score:5, Interesting)
The rest of the book--most of the book, actually--is about the Parrot virtual machine. Now, really, does this matter to Perl programmers at all? Is there a book about the innards of the interpreter used for Perl 5? Or a book about Python bytecode? It only matters if you're going to write a compiler that targets Parrot. And, again, note that Parrot is also a work in progress and will likely change dramatically before Perl 6 is actually released.
In short:
1. This is a book about vaporware.
2. Most of the book is not about Perl 6.3.
3. Why did O'Reilly even bother with this?
Re:Barely about Perl. Certainly not essential. (Score:3, Insightful)
As far as delving into the guts, yes there is a book about the innards of perl5 Extending and Embedding Perl [barnesandnoble.com]. A good read actually. I myself am looking forward to a refactored implementation. perl5 isn't too pretty inside the bowels.
Re:Barely about Perl. Certainly not essential. (Score:4, Funny)
Neither are you mate, no, not pretty at all, at all.
Re:Barely about Perl. Certainly not essential. (Score:2, Funny)
attractiveness of my internals.
Re:Barely about Perl. Certainly not essential. (Score:1)
a Perl5 book, buy something else.
So what if Perl6 is not ready. If I was interested
in the Unified Theory, I would buy an appropiate book for
the topic; or do I first have to wait until physists
finaly decide whether the theory is valid or
invalid?
It takes all kinds (Score:2)
When I can escape the clutches of IT I enjoy looking through housing estates that are under construction while the water supply, drains, sewers, electric supply, gas, telecommunications, roads, footpaths, etc. are being installed. Likewise for friends' new houses and renovations and public buildings when I can wangle access.
Following the Perl 6 development process is a lot like that. You gain some a
Perl 6 is coming (Score:5, Funny)
Will it be released at the same time as HURD?
Re:Perl 6 is coming (Score:3, Funny)
Ya boink my regex then want me to buy yer book!?! (Score:2)
Anti-Perl Sentiment (Score:2)
And regular expressions, too! Like Perl, you may hate the syntax but but you've got to love the power. Ah yes, it's like one of those fire-breathing car-crushin
Re:I want to know how many websites use PERL . (Score:1)
Re:I want to know how many websites use PERL . (Score:2)
That's really sick.
That's like using IE on *nix/Wine.
Re:I want to know how many websites use PERL . (Score:1, Insightful)
Re:I want to know how many websites use PERL . (Score:2)
The distinction is that it isn't called PERL, it is Perl. There once (a short while) was a Perl ripoff called PERL that was a bit similar, but without all the features that makes a maintainable and secure application possible. If anyone is curious, you could have a look at Acme::Inline::PERL [cpan.org] at CPAN, which brings the power of PERL to Perl. Yes, the ACME:: namespace is for sillyness and joke modules.
Re:I want to know how many websites use PERL . (Score:1, Insightful)
exactly. thirty years and we still can't fucking get past C. isn't it time we start using languages designed for humans and not machines?
Re:The Right Tool For The Job (Score:1, Insightful)
Re:The Right Tool For The Job (Score:2)
WTF are you talking about? Divide the community... it's about the software, not the language. Who gives a damn if the code is written in Perl, Python, Ruby, or, heck, shell script, as long as it does something useful?
Re:Ruby (Score:1)
>
> Ruby.
Personally I love Ruby. It's great fun to program in. There's one thing I don't like about it, though: anytime you want to do ANYTHING, you have to do a method call. That means you have to take some object, and look through one or more hash tables of method names => methods. You can't evel 'call' a piece of code without looking up its 'call' method. I'm sure that hurts efficiency quite a bit. What would be nice would be to use Parrot-style vtables for common operation
Re:Ruby (Score:1)
Ruby says "bwarghhhhh!" [uklinux.net]