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.
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...
You sir, are a f'in nutcase, that or I hope this was meant to be parody.
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.
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
It may come as a surprise that within the pages of 'Perl 6 Essentials'lies what could be two books
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".
okay, first off: Perl owns you.
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.
"$_" is a perl pronoun. Anyone that actually KNOWS any perl, doesn't find the use of implicit pronouns at all confusing, or unreadable, the same way that anyone who knows the english language doesn't find pronouns at all confusing.
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.
So, how many editions should we expect?
Opinions my own, statements of fact may contain errors
When I started using Perl 5 I figured it to be about 10 years ahead of its time. Being about 5 years since then I think I was pretty close to right.
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.
Excellent points, thanks. I'll just add a few notes:
- 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.
-- http://frobnosticate.com
(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
This book isn't about Perl 6 at all, and there's nothing about it that's "essential." Part of the book is about the *plan* for Perl 6, but that's just plain silly. Who wants to read about the plan for some that's in the middle of development? Odds are that much of this part of the book will be completely invalidated long before Perl 6 is actually released.
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?
Will it be released at the same time as HURD?
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
I think the plan is important in the sense that the it gives members of the community an idea of what's going to happen who haven't been following it that close.
As far as delving into the guts, yes there is a book about the innards of perl5 Extending and Embedding Perl. A good read actually. I myself am looking forward to a refactored implementation. perl5 isn't too pretty inside the bowels.
-William Shatner can be neither created nor destroyed.
Neither are you mate, no, not pretty at all, at all.
In the same way, in a statement such as// foreach ( @array ) { print }// It is extremely obvious,
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.
I do not have a signature
No, that is print "@array"