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:
$var[0] to get information out of an array called @var, which is different from a scalar called $var.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 print et al. These features are tempting and useful and they crop up all the time in real code, even in the official documentation. They also should never be used. Newcomers have to be shown these features - so that they understand what they're seeing "in the wild" - and then warned immediately that, in most situations, they shouldn't be used. Again, this gives a bad impression of Perl (why does it have the feature at all if there's no point in using it?). And, again, I have a limited amount of time available. I'd prefer to demonstrate good practice alone.
But Perl has much on the positive side. Particularly for people coming from a Java background, the map and grep and sort functions are incredibly powerful. Perl also has many simple little things like the unless and 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.