Putting the ideas together, a hands on tutorial of modern Perl
Jacinta Richardson will be giving a free workshop at YAPC::NA 2012 described as:
So you’ve heard of Moose, autodie, DBIx::Class, Try::Tiny, Method::Signatures, autobox, NYTProf, Perl::Critic, test driven development and the funky regular expressions changes Perl 5.10 brought in. Or at least you’ve heard of some of them. Have you had the opportunity to smash these all together and see what amazing results can fall out?
This tutorial will treat most of these modules as black boxes which do amazing magic; and instead of showing you the intimate details of how to create your classes with Moose, create hints for autodie, interface with a database with DBIx::Class, or catch exceptions with Try::Tiny etc; this tutorial will show you how to use code where all of that work is already done, allowing you the freedom to play with the fun bit of what comes next.
If you’ve ever wished you could just write code that looks more like:
$string->split(” “)->reverse->join(” “)->say;
rather than
say join(” “, reverse(split(” “, $string)));
Or hated writing or die $! after every open, or lost count of opening parentheses in a regular expression and not been sure if you wanted $5 or $6, or got annoyed at unpacking @_. If you’ve ever been afraid of writing tests or littered your code with print statements to try to guess where it was taking so long or grumbled about a lack of try-catch semantics that don’t involve eval and $@. If you’ve been frustrated by these things, but just accepted that this is the way Perl is, then no more, because this is the tutorial for you.
[From the YAPC::NA Blog.]
My little part in the greater Perl world.
As much as i like to see modern tutorials, that example doesn't need to be that ugly. This does the same thing and looks pretty nice:
say join ' ', reverse split ' ', $string;
You're right. It's definitely shorter. However, I believe it would be less clear to someone just starting out with Perl. The parenthesis that Jacinta uses adds clarity in the order of operations.
I agree with Mithaldu. I don't think adding a ton of parentheses adds clarity at all; it just adds a ton of parentheses. His version isn't just shorter, it's easier to both read and write. It seems a bit disingenuous to claim the autoboxed thing looks better than the alternative when you're not being honest about the alternative.
As much as I like to read Mithaldu's version, when I code I'd go for Jacinta's parenthesized version.
Unless you're a noob Perl developer you cannot possibly refute my claim. I didn't say it was less clear, I said it would be less clear to a noob. I've taught lots of new developers Perl, and can say that they certainly get confused when they see a whole bunch of things shoved together like this.
Even though I don't use autobox, I like it's syntax better. As for the parentheses, or any style question, you can never say it's clear or not clear. You can only say it's clear to you or not clear to you. Different people, especially people of different skill levels, have different ideas about clarity.
In my Learning Perl classes, I teach people to reach list things from the end toward the beginning (which is what the autobox does by ordering operations). If you don't figure that out, reading the unparenthesized form is difficult for newbies merely because they don't know where to start to break things into the different operations. It doesn't matter how I feel about that, either. My opinion is completely irrelevant. I know that some newbies have trouble with the lack of parentheses.
People make a big deal out of the ease of writing. That's hardly ever my problem. I certainly don't write code by starting with the first character and typing the next character until I get to the end. I make a big mess, usually coding inside out, and make it look pretty as I debug and refine it. I usually don't end up with whatever I started with. Ease of writing has never been high on my list. Working code that other people can read is much more important to me. The problem, though, is who those other people are. Things that I can easily read aren't necessarily things that other people can easily read, no matter how easily I wrote it.
Jacinta, by the way, isn't a "him". She's a "her".
I really like autobox syntax in Perl 5 and core methods in Perl 6, but I personally prefer to call
sayandprintas functions instead of methods to put emphasis on the IO operation as opposed to simply munging a string.say $string->split(' ')->reverse->join(' ');or even better in Perl 6:
say $string.words.reverse.join(' ');Note that
wordsin Perl 6 splits on any amount of whitespace characters, which would probably be more desirable in this case anyway.I'd agree with this - say and print are really functions of the I/O layer rather than anything to do with the string itself. Although it might be convenient to have $string->say, this seems to contravene the usual notions of encapsulation - you might get some disapproving comments in code review if you were to implement a $string->use_as_email_subject_and_send_to_everyone_in_my_contact_list method, for example =)
I'm really not familiar with perl6 but split ' ' in perl5 also splits on any amount of whitespace characters (and strips preceeding/trailing whitespace as well), so I think those two are probably equivalent?
Yes,
wordsin Perl 6 is equivalent tosplit ' 'in Perl 5. In Perl 6,' 'is not a special pattern forsplit. In general, the language is much more predictable than it's predecessor, except for certain elements of the language like the~~(smartmatch) operator and the*(whatever) term. When you see those, expect some magic!Completely different
sayandprintmethods are provided forIOobjects, which I think is a much better use of them than the ones onStrobjects. For example:$filehandle->say($string);