Slashdot Mirror
Perl 6 Essentials
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.
This one is a great addition to the book shelf, you all know how to do certain things in Perl 6 but this book clarifies nicely why you are actually doing it. Also, it introduces nice new perl concepts which hardcore perl 5 scripters might not have come across before.
There is no god
Amazon has for $2.50 less than bn (almost 15% less!)
It's $4.50 cheaper at bookpool.
They're also doing a free shipping deal.
-Dave
>limited in what you can do. This is because Perl isn't OO (so you
>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...
Those of you unfamiliar with Perl history may find it interesting that the "Parrot" started out as an elaborate April Fool's day joke two years ago. Here is the book that was announced. Strangely enough, people found the idea useful and are now actively developing it!
Slashdot's first reaction to VMware
Of course, if you just go read the Apocalypses and Exegeses on perl.com and the FAQ on parrotcode.org, you get all of this for free.
(FYI, I posted this on the thread for this book's announcement.)
..." is a discussion and tutorial on a topic, intended for beginners ..." is the same, but for intermediate and advanced users
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
Joe
http://www.joegrossberg.com
My guess is two more, though the more people who contribute, the sooner Programming Perl 6 will be released.
how to invest, a novice's guide
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.)
If you are looking to convert perl source into java source, then you are probably totally out of luck though.
Admittedly, my response is coming from the perspective of someone who is very happy with Perl, despite it's shortcomings. I've been programming in Perl for almost 4 years, and have only dabbled in PHP (though my brother has used both extensively and prefers Perl greatly). However, some points of your argument are flawed, so I hope to clarify a few things. I'll just address each point:
/home/` or something, which is stupid to do because system calls are extremely slow and can usually be handled with perl commands that aren't platform specific), you shouldn't have to change anything else.
* 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 C and C++ before either one.
* The OO of PHP is excellent. If this is true, then PHP must've vastly improved since I used it. When I did, it had very weak OO support. Despite the odd syntax of OO in Perl, it is a very excellent OO language. I wish it did have a few more features, but they are to come in Perl 6.
* Outstanding database support. This is just patently wrong. Perl has vastly better DB support through DBI. PHP has modules specific to different DBs, but DBI is an excellent abstraction layer that has an implementation in every DB I've ever heard of (Postgresql, mysql, msql, oracle, etc).
* Speed. PHP is faster than CGI perl in a web environment, but in my experience perl is faster in server scripting. Mod-perl is equally fast to PHP in a web environment, so the whole point is moot.
* Portability. You must not know how to program if you can't port your perl code across operating systems. The only thing you might have to change is the location of the perl interpreter (the #!/usr/bin/perl line). Unless you're using system calls (like `ls
* Graphics. There are many graphics modules available on CPAN for perl. I honestly don't know how the implementations compare, but they both have them.
* Data Structures. Perl supports complex data structures also. I'm not familiar with all of those structures you mention, but I'm fairly sure (if memory serves me on all of the definitions) that Perl does linked lists, hash tables, and queues at the minimum. Also, Perl has pointers, though I believe they refer to them as "references" (not to be confused with references in C++). The syntax is a bit different, like if you create a hash (aka associate array) %hash and then pass \%hash into a function, on the other side you'd have $hash (a reference to %hash, references are written as scalars). Then if you want the "stuff" key, you can do $hash->{stuff} or $$hash{stuff} (antiquated syntax) to retrieve it. Same goes for arrays. It also has a fairly robust OO implementation, once you get past the obvious hack syntax utilized for it (since it was added after the language was written, Perl 6 will correct this).
It seems obvious to me that you didn't spend much time trying Perl before you gave up and moved on. Maybe that's an unfair assessment, but most of the limitations you perceive in Perl just aren't there.
I think I'd agree, given that the endpoint is probably not another edition of Perl 6 Essentials, but Programming Perl 4th Edition.
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.
-- Kate