So, I've decided to work on a book for those looking to learn programming. It will focus on learning how to program, using Perl as the example language. This, in my opinion, is an area that is sorely lacking in recent years. I am in discussions with a publisher and it is looking quite likely that it will become a nice hard-copy book. Regardless, though, I will be placing it on the Catalyzed wiki.
What I've realized in starting this process is that it is actually very difficult to figure out what to cover. Once you have been programming for awhile, it tends to infect your brain. It actually modifies your thought processes and you forget what you didn't know when you started.
I'm hoping to accomplish a lot of things with this book, but there are two main items which I think are most important. First, I want to introduce the subject of programming and Perl clearly to those coming to either subject for the first time. Second, I want to teach all the little things that make Perl programming an enjoyable experience, the little things that let you really be productive in Perl.
I've got quite a bit of the book's contents worked out... but I have a question for all you Perl programmers out there... What, beyond the basics of all programming, should I be sure to cover?
What do you think every Perl programmer should know? What things help you on a daily basis and keep you working in Perl over other languages? What aspects of working in Perl do you think are most important and/or most different from other languages? What bit of Perl did you learn late and wish you knew much earlier in your Perl programming career?
Here's your chance to share your knowledge with the next generation of Perl programmers (I am ambitious, what can I say?) .. Share your thoughts in the comments!




I'll share first... I'm almost embarrassed to say that for the first couple years of my Perl programming career I never used map... I know, I know.
It was in the books I read, but not front-and-center enough I guess and and not knowing what it was I didn't bother to look into it until much later. Oh how many of my projects could have been more succinct and clearer if I'd just learned map to begin with.
> What things help you on a daily basis and keep
> you working in Perl over other languages?
I've been $working with Java for the past week and I can never cease to be amazed at how painfully verbose that language is, along with is libraries which follow its culture, and how disorganized the set of libraries is.
I think the book should mention, perhaps at the very beginning, in order to win over the programmer who might've heard bad things about Perl and glorious stories about other languages:
how Perl's data structures are stupid easy to create and manipulate. To build a set of key/value pairs as for passing in a URI query:
Java:
List qparams = new ArrayList();
qparams.add(new BasicNameValuePair("key1", "value1");
qparams.add(new BasicNameValuePair("key2", "value2");
Perl:
my $params = {
key1 => value1,
key2 => value2,
}
How Perl is so much more concise and consistent in its built-in functions when compared to PHP (see http://tnx.nl/php). The fact that humans can hold in their head around 7 concepts at a time really makes a difference when you need to remember which of ereg, ereg_replace, eregi, eregi_replace, mb_ereg, mb_ereg_replace, mb_eregi, mb_eregi_replace, preg_replace, str_replace, str_ireplace to use.
How all of Perl's libraries are centralized on CPAN, with easy installation, built-in documentation, bug tracking and all that.
That Perl is not line noise, unless the programmer is binarily vociferous. Perl is in reality very expressive and elegant, and often reads close to English.
Moose
That Perl has quality IDEs as well, and it works on Windows too, and it can even do desktop applications on it.
etc.... and here I sympathize with you in that I've been using Perl for so long and take it so much for granted that I'm having a hard time enumerating what makes it so great.
Every time I have to switch from Perl to another language (save perhaps jQuery), I feel crippled.
Any list type stuff and functional. You mentioned map. I didn't learn map till I used Ruby do to the more approachable syntax.
I also think that a good intro to CPAN and Moose is good for perl programmers.
Hi Jay!
You may wish to go over my "Perl for Perl Newbies" series of lectures and see what I thought required emphasis. Some of the material there is a bit out-dated, especially the third installment, but, hopefully you'll be able to re-use some stuff. The licence is Public Domain, so feel free to incorporate parts of it into a larger work. (I would appreciate an attribution / link, a monetary donation, etc. but do not require them).
I have written the summary of the 5th and 6th installments, but have been neglecting working on it because of other projects.
In any case, what should be covered is: (some of it was inspired by an excellent talk by Reuven Lerner - I have the slides if you're interested)
Scalar vs. list context.
Using the perl debugger, as well as Devel::Trace, Devel::LineTrace, print statements, etc.
Getting help (IRC, Perl monks, mailing lists, etc.)
undef, true, false.
compilation vs. runtime.
Lexicals vs. Globals.
References.
use strict; / use warnings; / autodie / etc.
Using CPAN, CPANPLUS, cpan2dist, local::lib, etc.
I also think you should cover some practical topics such as writing web applications, GUI programs, web automation programs, etc. so people would not only learn about the core language and be able to put their knowledge into practice.
I agree with frew, certainly hit map hard. Best practices obviously, but I would like to see problem solving more integrated with teaching people programming languages. Figure out an algorithm first, then build a bridge from your problem to your solution with Perl.
My $0.02 :-)
Devin Austin's comments above about the bridge between what you want to do and where you are now capture something important about learning to program. Perl is great because it teaches you how to build the bridge if you can use its error messages, the debugger, the documentation and the community.
It teaches you how to program. You teach yourself to program trying to build that bridge.
This assumes an intelligent, determined person, who is good at following instructions.
For someone less gifted, the role of a teacher would be a handholder, a shoulder to cry on, and a magic carpet to other less confusing, disheartening parts of the maze, or bridge
Dr Bean ++
The method I describe is one I've seen my father, who is an incredible mentor, Jay himself, and every single successful mentor in my life that has made an sort of difference to my learning abilities or the abilities of others.
It allows everyone to feel confident enough to open their mind and learn this stuff.
Hi Jay,
I've moved back into programming Perl after a ten year break. The most useful things I've learned this time around are using local instances of libraries; CPAN::Mini and Lib::Local. Inclunding a number of things around testing and version control. Getting your work flow right takes time, so far has been the trickiest part of getting on with the job. How do other people do that would certainly be interesting to see.
Surprisingly the hardest things were getting my head around scalar and list context and that hashes are just associative arrays as are found in other languages.
$_ @_ and friends always used to bother me, but this time around now understanding scalar and list context, it all seems to fit properly. I moved from C to Perl last time, so I expect that there was a bit much of a jump.
Over the last couple if years I've been working in Python and with that worked my way through a number of books. The most used is the 'Python Phrasebook'. I've not found one of these for Perl yet, I imagine there is something similar out there. Once you have a grasp of the structures of the language, understanding short recipies makes it a whole lot easier to plug together scripts/programs a lot quicker. The more code you write the more you get it, the less code you need to write =) The nice thing about that book is its concise and the examples are well grouped.
While programmers don't tend to be social animals, I've gotten into the habit of showing other folks my code, often. Maybe this is odd, but its certainly helped me work on a style that is more readable to others and obviously improve my code through feedback. That probably the single hardest challenge of all. The best piece of advice I recieved about programming came at Linux Conf AU this year, "Don't worry about how good or bad you code is, showing it to others will always help you improve it. Even if its not obvious at fisrt how negative feedback about your code can help." And I've had some very negative feedback. Sure some of my Perl must have been horrible, but how else do you figure out what is "best practice"? How do you avoid the gotchas?
Like other interests I have, I've found the best way to learn in a new field is to find folks that are happy to mentor you through the early wilderness and direct you a bit into the greener pastures =) Books help you form new questions, coding helps you answer some of them, but walking in your community really sets the biggest challenges you can face and conqure =)
Web development using Perl would be really helpful.