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!)
So that's what... like 100 pages of the string "Smoke crack" repeating?
print "Smoke crack" x 1000000 .. hey, that was pretty easy.
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
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.
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
If you've been keeping track of the Parrot project's progress for the past 2+ years you'd see that they're going nowhere fast. No language implemented other than a toy Basic language, no thread support, no object support, no exception support, no stable standard calling convention, no code module support (like Java .jar files), a proliferation of stupid one-off opcodes that should be method calls - and worse of all - no working Perl support. As for Ponie/Perl5 on Parrot - I'll believe it when I see it - this Parrot project blows more hot air than a thousands hair dryers. Tell you what - give me the $200,000 that they've been given and I will write the Perl6 interpreter for them. A lot of better open source projects have been written with little or no funding at all. There's no excuse for the pace of this project - it's directionless and leaderless.
(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.
...interesting if true.
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.
While I tend to prefer Perl as well, many of your reasons for prefering it are not entirely informed...
"* 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 is a bit ad-hominem, with the "not so in other (which?) languages part, but others would say the OO part is Perl's weakness. Either way, both languages (Perl in 5, PHP in 5) are working to improve their OO models.
"* Perl has better string manipulation"
True. Probably why PHP apes it in some respects.
"* PHP used Perl as part of it's basis"
This isn't really a good reason, since the obvious rejoinder is "ah, so PHP is an improvement on Perl then?". At any rate, its a bit silly to pick on another language for appropriating the good parts of other languages when you like Perl. Pot, this is Kettle, over, you are BLACK!
"PHP embeds..."
You mean, kind of like Mason with Perl? Really "violations of the OSI model" aside, this tends to be WHY PHP is so popular, because its very easy to use to do the odd simple thing because of this. Yes, you run into the problems with it when you start to do a larger project (which is why there are all those PHP template systems, I suppose.) but why deride something that works very well for the 80% of cases that are out there. It's also entirely possible to use PHP as a non-HTML-embedded language, of course.
That being said, I'd choose Perl in a heartbeat over PHP for a large project, particular one not Web related, for a number of reasons.
* Far better support for modules, and a much larger library of solutions already available.
* Some speed related issues out of the box.
* The afore mentioned string manipulation issues.
* Better ability to do things like signal handlers, and other "Unixy" things.
* What IMHO, I consider better language/character set support.
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.
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"
I'll thank you for not pondering about the :P
attractiveness of my internals.
-William Shatner can be neither created nor destroyed.
Is it not true that most Free Software projects
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.