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.
Agreed. This is especially important in the free software world, where every advantage we can get we need. With all these languages abounding, there is a divide in our community.
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.
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".
You know, some programmers write things other than web pages.
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.
For the love of god, don't use PERL. We are thirty years out of the seventies....
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?
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.
What is the background of the programmers who wrote the Perl code you're criticizing? Sysadmins with 5 minutes to get something done or professional programmers who negotiated time for proper design to be included in the development time?
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++ source private while distributing binaries.
In general, I can point to C, C++, and even Visual BASIC code and make strong statements about them being obscure unmaintainable garbage. Lets face it, most programmers (even the ones with computer science degrees from respected universities) truly suck and have no business coding for a living.
When I saw Perl code, it made me stay away for years because it wasn't "obvious" compared to other high level languages. Out of curiosity, I read the first few chapters of Programming Perl and came to realize that I've been missing out--the same Perl code that initially looked like garbage actually made sense and looked very elegant because it didn't force the programmer to jump through hoops to "get stuff done".
If you've read & understood that book and still see unmaintainable Perl code at your company, maybe it is time to push for some coding standards.
Given Perl's extensibility, you can even have exception handling similar to Java's throw/catch/finally.
Again, nothing stops Perl programmers from using coding standards that enforce naming conventions, use of the same exception handling library, etc. The fact that they don't choose to doesn't reflect on the language but on the coders and the circumstances (having only 15 minutes to write a quick utility to fix a problem) which led them to write unmaintainable code.
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"