I've taught Perl to a grand total of about fifty people at work now, in various sizes of group. These are, generally, newcomers to an office where a lot of Perl is used. Most of these newcomers are fresh out of university and if they have any programming experience it's usually Java from their CS courses. These people need to learn Perl to do their jobs, and my task is to show them how to do this work and how to find their way after the lessons are over. Here are some things I've discovered.
Right out of the gate, there's an unavoidable culture shock which comes from learning Java and then learning Perl. Perl, by its very nature, encourages behaviours which Java, by its nature, strongly discourages or even makes impossible. For example: stern, protective type safety is not only missing from Perl but actually not even considered particularly desirable. Perl is relaxed. The reaction from students is, naturally: "Isn't this a huge obstacle to getting anything done?" Obviously the answer is "No", but even after all the Perl I've written I sometimes wonder why not. Is it really just the fact that it takes less time to type method signatures and variable declarations?
There are other big points of unfamiliarity. There's the fact that Perl is interpreted, not compiled. There's the fact that in Java everything is an object but in Perl most things are not objects at all, and the fact that in Perl execution just starts at the top of the page, not in
public static void main(String args).
None of this is Perl's fault or Java's fault. It's like being a child: When you're at the very beginning of your life, and you've seen very little of the world of software engineering, the few things that you have seen fill your whole mind up and heavily colour all of your future experiences.
There's even the fact that - shockingly - Java isn't the number one all-purpose solution to all conceivable problems. There's very little Java can't do, but there are many things which Java is bad for, which Perl is very good for. Likewise Perl is bad for many things where Java will happily pick up the slack. Programming languages form an ecosystem, with multiple languages surviving alongside each other because each provides a combination of somethings which none of the others quite do (even if some of those somethings are intangible and unrelated to the language itself, like easy availability of coders for that language, or irreplaceability). And the languages that one person knows form a toolkit and a person should use the right tool for the right job, not the same tool for every job.
So there's that. But then there are things about Perl (and nothing else in the environment, just Perl) which make Perl hard to teach.
Perl has pitfalls. Every language has pitfalls, and the number of pitfalls in Perl isn't even particularly large. But Perl's pitfalls are right there in the entry-level tutorials, right there in lesson one. Newcomers run headlong into them and have to be helped past every single one:
- You use
$varto get information out of an array called
@var, which is different from a scalar called
- Perl has no boolean data type even though all of the documentation speaks at length about functions returning true and false.
- Creating elementary nested data structures is difficult, as is getting information out of them.
- Modules and packages are actually completely different things which have been dressed up to look the same.
Attempting to sugar-coat the truth doesn't get anybody anywhere. The easiest way to get past these confusions is for me to explain them up front. This means that the newcomers are left with a bad first impression of Perl. "What? Huh? Why would you design a programming language like this?" Obviously the principle of least astonishment is being violated here. Admittedly, there is a point at which the principle of least astonishment must always be violated, otherwise every programming language would be exactly like all of its predecessors, but it should, at least, be immediately obvious why astonishing programmers in this way is a desirable tradeoff.
TMTOWTDI slows things down. From a student's perspective, extra syntax which does the same thing feels redundant, especially when the only benefit appears to be saving a few keystrokes. What I'd like to be able do in practice is teach one canonical Way To Do It, and leave the more advanced syntax for an advanced session, or for newcomers to discover in their own time. The problem is that TMTOWTDI implicitly encourages Perl programmers to use all of those different Ways whenever they feel like it, which means that newcomers need to be made aware of most of them immediately.
And bad practice slows things down as well. Perl has many shortcuts and clever features, such as omitting semicolons, omitting
return calls and omitting arguments to
But Perl has much on the positive side. Particularly for people coming from a Java background, the
sort functions are incredibly powerful. Perl also has many simple little things like the
until keywords, which are self-explanatory and make life much easier, and the short
statement if condition and
statement foreach list formations. Even the
open function is about a million times simpler than Java's. So a good deal of the difference is made up by these "good bits". I show how Perl is perfectly adapted for processing text files into other text files. I present it as essentially hypercharged, portable shell scripting, which is indeed Perl's main use where I work.
At the end of the day the emphasis has to be on getting things done. Perl is a programming language in which people get things done. It's lucky that Perl reaches spots that Java doesn't, though, because I think I'd have a much harder time if most of the audience had a background in, for example, Python.
I guess there's no reason not to share this. This Perl script, when provided with the name of another (demo) Perl script, runs it over and over again every time the demo script is saved.
I put the demo script in a text editor at the top half of the screen, and the output from
perpetual.pl in the bottom half. I found this approach more useful than a REPL because it made it easier to demonstrate things like variable scope and the consequences of minor edits to existing scripts longer than a few lines.
As for content: this and the actual education were developed together and cover almost exactly the same ground.