An Intro to Perl - Presented to Makers Academy students
As part of our eager hunt for new developers I met up a few weeks ago with Ruben from Makers Academy, who told me all about their 12 week intensive web development course. They have a pretty impressive set up: they start courses every 6 weeks and each class is about 20 people, meaning they churn out about 160 new Ruby developers every year!
Given our successful internship program here at Nestoria (which I spoke about at YAPC::EU this year) I've got some experience taking people who know Python, Ruby or PHP and training them up in Perl very quickly. So, when Ruben asked if I would like to come and give a talk to some of their students I knew exactly what I wanted to talk about.
I gave this talk on Monday November 4th, to an audience of about 20 Ruby newbies. At the time one cohort was on their 6th week and the other on their 12th and final week, but sadly the guys and girls in their final week were mostly too busy on their final projects to attend. The six week group had just done a week with the Sinatra web framework, so they definitely had enough knowledge to follow along with my examples.
The talk was well received and I got a few questions at the end. Mostly people were asking me to draw comparisons between Ruby and Perl, which I answered as best I could with my limited Ruby familiarity.
I hung out a bit with some of the final week students after my talk and for their final project they were building a Gem - Ruby's equivalent to a CPAN distribution - which made me suspect that if we could convert them over to Perl we could have them contributing to CPAN nice and quickly :-)
Maybe these slides aren't too interesting to people who are already reading blogs.perl.org, but hopefully you'll get something out of it :-) At the very least, feel free to share it around and show some of your junior developers or your Python or Ruby programming friends.
CTO at Lokku Ltd.
The slides are very interesting for me, because i'm very interested in how newbies are introduced to Perl (see: http://perl-tutorial.org ). Sadly i have to say that i'm quite unhappy about them, because they methodically and uniformly are written without strict in effect, which has distinct negative effects on newbies. (It would also be neat if the Objects page showed Moo code instead. ;) )
On the other hand, i am extremely happy to see a company willing and interested in training new Perl developers, knowing that it will benefit themselves as well as the community. Major props for that.
Also props for actually mentioning a pay range on your jobs page, not many companies do that.
A more reasonable approach, for a more civilized time.
That was written in 2003 and with the, then reasonable, assumption that newbies can be expected to actually put in work and understand the language and its quirks.
I suspect you have not interacted with all too many newbies in the field in the past five years, but they've become much more lazy and ignorant.
mjd attacks tituraly strict in that prose, but what he really complains about is people who attack lack of strict in a program that is otherwise perfectly fine when the author asks for help with a single issue. Nowadays however one typically sees code with which more things are wrong than can be reasonably counted by a human.
Not in the past five years, but I have tutored undergrad CS in the past ten, and it was pretty grim. If there were pseudocode on the lecture slides, you would inevitably run into a student in the lab who had typed it directly into the computer, and was confused when it didn't run. There was a constant tension between trying to teach them something, and simply telling them what to do so that both you and them could move on.
My post was more a reaction to your drive-by scolding of Mr. Balhatchet, who put up some slides containing perfectly fine code not prefaced by some variant of the "use strict" chant. When you can only fit 5-10 lines of code on a slide, wasting 10-20% of those lines seems counterproductive.
Good to hear that you understand my worries. :)
There's been a misunderstanding though. I intentionally said "without strict in effect", which is not the same as "with strict in the code". It's very easy to achieve the desired teaching effect by mentioning strict once at the start, like Modern Perl and Beginning Perl do, and then simply leave it off the rest of your examples, but write them as if it were there.
Adding "my" all over the place would just be noise. Somewhere else in that page, MJD noted that there's not much difference between lexical and global scope in a one-screen program. We could pedant this out (recursive functions, dynamic scope, etc.), but that's exhausting and sad.
You apparently want all Perl on the internet to comply with "use strict 'vars';", because you really don't like global variables. I think it doesn't make much difference in small examples, and would rather not encourage cargo-cult programming.
No, the only thing i care about is starting newbies off in such a way that they write code by default that's easily debuggable. Please try to keep aware of the very large difference between code in teaching materials (monkey see, monkey do) and the code you write at home.
But all a beginner can do is cargo-cult!
It’s a necessary stage to go through in the process of leaning. Even the proverbial
print "Hello, world\n";has an onion of layers to unravel before you fully understand what is going on. The simplest example here is\n, of course. But there is plenty that isn’t even visible in the code – e.g. the concept of STDOUT, the idea of the selected handle, the fact that there are I/O layers applied to STDOUT by default, and the whole character ball of wax in the first place. A beginner who writesprint "Hello, world\n";is far from fully understanding everything that happens.But what you gonna do? You gotta start somewhere.
Learning is a spiral process. You start out somewhere and cargo-cult most of what you are doing, learning a little, then moving on to the next thing and learning a little, then learning a little more about a third part, and so on; until you have the foundations to come back to the first thing you started with, and learning more deeply about it, going into details that you previously didn’t have the basis to understand. This keeps going around and around, and the strength of a good teacher is to know how much to explain to you at each step of your progress, and how much to keep from you (or tell you to take on faith).
Without cargo-culting, you cannot learn.
So here’s my opposing position:
Those who understand what
use strictandmyare for, have the understanding to easily subtract those from sample code in their minds where they may be omitted; but those who have not yet built this understanding should be cargo-culting a form of code that does include them, because if you don’t yet know any better, then you should err on the side of using them over omitting them. This does not imply that cargo-culting is the ultimate goal; the goal is always to build full understanding.