Slashdot Mirror


Perl 6 Now by Scott Walters

Joseph Brenner writes "Every now and then, a beginning programmer asks if there's any point in learning to program in Perl 5, when Perl 6 is going to change everything soon. There are a number of answers to that: one is to point out that Perl 6 is still years away, another is to point out that it is promised that Perl 5 code will run under Perl 6 without modification (a module that begins with the traditional "package" statement is Perl 5 code; if it begins with the new "class," then it's Perl 6)." Read on for the rest of Brenner's review of Scott Walters' Programming in Perl 6 style using Perl 5, a book which answers that question a whole different way. Perl 6 Now author Scott Walters pages 379 publisher Apress rating 7 reviewer Joseph Brenner ISBN 1590593952 summary Programming in Perl 6 style using Perl 5

Scott Walters here pursues what might be thought of as the third answer: you can learn Perl 6 now and immediately begin writing programs in a "Perl6ish" sort of way, using appropriate CPAN modules that have been used to implement approximations of Perl 6 behavior: Perl6::Variables, Perl6::Export, Perl6::Contexts, autobox, Perl6::Classes, Switch, and so on.

There are many caveats about using these tricks in production code, however, and Scott Walters doesn't shy away from warning you about them (e.g. p.43 "Source filters are dangerous" where he discusses their increased start-up overhead and potential bugginess -- though he doesn't mention my own peeve which is that they're very confusing when you try and use the Perl debugger).

So possibly the book is not really quite so well suited to an actual beginner-- who probably should not be told about "use Switch 'Perl6'", but the device of spending the early stages of the book directed toward a beginning audience makes it a very useful review for people like myself who have been reading the Apocalypses, but don't remember every detail.

And on the other hand, the book includes some prominent early warnings about common gotchas that beginning programmers seem to be prone to -- e.g. using dynamically defined variables instead of just using hashes.

The standards for writing English in the Perl world are pretty high -- the core members of the Perl community have always cared a lot about clear writing, and it's arguably the world's best documented language (critics will no doubt add that it needs to be). Unfortunately, I can't say that Perl 6 Now quite lives up to this standard. This is a book that was written in a hurry, and it shows: hasty sentences and minor organizational problems abound (e.g. one or two items seem to be discussed in the wrong place; there are an awful lot of explicit forward references, and yet there's at least one place where something was used in an example before being discussed a few dozen pages later). But then in Scott Walters defense, this is certainly a book that needed to be written in a hurry, because its subject matter is such a moving target.

And where the book really shines is in its code examples: short, clear and to the point; the author repeatedly shows how something can be done in Perl 5 code and how it's expected to work in Perl 6. These examples are always clearly labeled "Perl 5" or "Perl 6" in the comments, so that the two can't be confused.

The subjects of some of the examples are pretty cool: e.g. he talks about using PDL ("Perl Data Language") to crunch audio data in MOD format, which I was completely unfamiliar with. A *.mod file essentially contains the "sheet music" for multiple parts (really, MIDI) plus sound samples that specify how notes will sound for each voice. This is discussed in Chapter 7, which is also the free sample chapter. I also liked random walking Arizona's highways as an example of Graph navigation (Chapter 8, p 159), and I appreciate the fact that he downplays inheritance in favor of delegation in his discussion of objects (Chapter 14, p. 262).

All in all, this book is a fun read for the Perl fanatic.

(Note: the title Perl 6 Now bears a strong resemblance to an emacs package I've been working on called perlnow.el, but there is no relation.)

You can purchase Programming in Perl 6 style using Perl 5 from bn.com; it's also available in eBook format (password protected PDF, using your email as password) for $15. Source code and and a sample chapter are available online: Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

8 of 366 comments (clear)

  1. Re:Perl 9 is already out... by Gunny101 · · Score: 2, Interesting

    It's interesting that books on Perl 6 are released when the Perl 6 is still in development. I understand modules for Perl 5 exist that can utlize some Perl 6 features, but still... Someone should release a book on Windows Vista now that a beta is out.

  2. Re:PHP5! by utopianfiat · · Score: 2, Interesting

    s/(1|2|3|4|5|6|7|8|9|0|one|two|three|four|five|six |seven|eight|nine|ten|eleven|twelve|thirteen|fourt een|fifteen|sixteen|seventeen|eighteen|nineteen|tw enty|thirty|forty|fifty|sixty|seventy|eighty|ninet y|hundred|thousand|million|billion|trillion)/<b>\1 </b>/g

    Look, I'm violating patents!

    --
    +5, Truth
  3. Moving from Perl (slightly OT) by Seumas · · Score: 3, Interesting

    I was going to bring this up in the thread about beginning programming the other day, but I came too late to the party. Hopefully someone can offer me some advice.

    First, I'm not really a programmer. Not professionally, at least. I've been writing Perl for about four or five years, though. I'm not well-versed in OO and I'd like to be. I've just found it such a stumbling block in Perl and that's probably because I'm doing in Perl in the first place. It's the first language I picked up since I played around with BASIC and Pascal as a little kid.

    I run a large auction site. Maybe 40,000 members. I wrote the entire engine (auction, forums - everything) in Perl. But it's getting complex and difficult to maintain as it is. And the performance is not holding up. I could move to mod_perl, but rather than re-writing everything (and possibly doing so in OO), I thought I'd just write it in another language.

    I don't want PHP. So that leaves me mostly with Python and Ruby. I've done a lot of reading, but am not sure which would be more appropriate. I think Python might stick me back in the old "easy to do things wrong and blow your foot off" world of Perl. Ruby on the other hand would probably help me gain a better understanding and real-world use of OO.

    Performance is an issue. So are available packages. My backend is postgresql and I need whatever language I use to have an extremely capable and flexible and mature postgresql DBI.

    At the moment, I have to say I'm leaning toward Ruby. But it does seem that Python might have more mature packages available to it and be a bit more widely used. I'm just skittish because everything I've heard has given me the impression that it's very Perl-ish and if I'm going to be in that world, I might as well just stick with Perl in the first place.

    Thoughts?

  4. Re:Pointless Perl6 by Anonymous Coward · · Score: 1, Interesting
    Yeah, wouldn't it be cool if Larry focused on other cool applications like patch management, or news readers or usenet posting software.

    PS: for the uninformed; Larry did indeed write the leading products in those categories at the time(late 80s?)

  5. Re:Is there a point to Perl any more? by CDarklock · · Score: 4, Interesting

    I stopped using Perl over ten years ago, when I had a disagreement with Tom Christiansen and he seriously threatened to blacklist me from the Perl community if I didn't agree with him. I told him to go ahead, because I would simply never write Perl again. He laughed and told me to let him know how that went.

    Well, it went just fine. I haven't written a single line of Perl since that day, and I haven't missed it one bit.

    These days, with so many options available, I think Perl appeals to a certain kind of developer in much the same way Java does. You don't really NEED it, in the sense that many other things can do the same job... but it's a point of style. Java and Perl now serve primarily as focal points for very small and specific communities that otherwise wouldn't really exist in a coherent fashion, much like APL or Objective-C. Ruby is similar, and I don't really see it going mainstream. These sorts of niche technologies still do the job, and selecting one of them instead of a more "mainstream" language like PHP or C++ identifies you as a particular kind of person.

    --
    Microsoft cheerleader, blue flag waving, you got a problem with that?
  6. about package statement by guacamole · · Score: 2, Interesting

    So, what happens if I use perl6 to run a script that has neither "package" nor "class" statements in it. How is it going to decide which language is that?

  7. Re:Why is Perl so hated? by chromatic · · Score: 2, Interesting
    Fewer keystrokes should not be a design goal of a language.

    Your objection is silly and I think it's because you focused on variable names at the expense of what Perl really tries to optimize, Huffman-wisee. The driving question of Perl (and especially Perl 6) design here is "Why should common operations require a lot of syntax?" In English, why should words such as "he", "she", "I", "you", and "it" be short instead of long? Why is say a better keyword to print a string with a newline attached than print_with_newline?

    One answer is to let meaningful identifiers stand out more.

    Granted, there are tradeoffs. I've seen the Sieve of Eratosthenes in APL and it's fairly dense -- but somehow good people get by with learning a little bit of notation. (The waterbed theory of complexity applies here too).

  8. Re:Flame On! by Chandon+Seldon · · Score: 3, Interesting

    I prefer programming in Perl to Python. This is primarily because Perl has better variable scoping, which combines nicely with "use strict" and "use warnings FATAL => 'all'".

    In Python, there are two scopes for variables: Global and Function. In perl, any { block } gets it's own scope for "my" variables. This means that temporary variables disappear when you're done with them rather than sticking around clogging up memory and name spaces. Because perl has variable declaration statements (my, our), it can check at compile time to make sure you have no typos in variable names. In python, any time you do an assignment you might be declaring a new variable - and you'll never know until you get incorrect output.

    Also, Python has no do...while(). This gives you the amazing choice of duplicating program logic (awesome when you change only one instance later) or putting in a "while 1:" - rather than knowing where the loop condition is, the maintnence programmer gets to randomly guess *and* this opens the way for "sometimes the loop never ends" bugs. Not good times.

    I'm looking forward to Perl 6 where it will be possible to have semi-static typing. That will mean even less code that compiles but doesn't work. I really wouldn't want to be using a language without similar features for any sort of non-trivial software project.

    --
    -- The act of censorship is always worse than whatever is being censored. Always.