The more I think about this, the more I'm convincing myself (for good or ill), that the things programmers need to learn next aren't so much about Perl as things they should know how to implement in Perl, but could also do in some other language. Surely I can teach more and more Perl stuff, but at some point the student who really wants to learn more needs to have a "programming lifestyle" that supports it.

To me, this is the heart of it. I first learned Perl in 1995, and thought it was a heck of lot better than C or Pascal, but it was just a year-off from college, so I didn't do much with it. In 1999, I started working seriously with Perl and, after reading the Camel 3rd a few times, realized that I already knew all the language stuff, but didn't know the programming stuff (despite have a CS degree). I was lucky enough to be directed here, where I have happily undergone a 4+ year apprenticeship to some great people.

Teaching beginners is easy because we know where to start and everyone is pretty much in the same place. A lot of people are content to stay at that level, and that might be okay for them. What catapults people into the higher levels, though?

This is also very important. Most people who write stuff in Perl do so because they're not programmers, don't want to be programmers, and know just enough to get done what they need to get done. They don't need to know how to do more. At best, a quick tour of CPAN is all they need to be more productive.

You can also look at Saints in our Book and catalog what they thought they'd be when they grew up. I'll bet you less than 20% thought they would actually be real-life computer programmers. Yeah, there's the people like me who wanted to be a programmer ever since they first played around with AppleBasic or CP/M or whatever. But, most just fell into it because some random job accidentally asked them to go beyond what they thought they could do. How many times do we get the question that goes something like "I can write cronjobs, but now I'm being asked to write mission-control software. Help!"

As for your safety net ... every dangerous task has its own safety net. I think that instead of trying to build Safe for mid-level developers, you should instead look at trying to develop habits. I programmed for 5 years before I even knew that you could have automated tests for software. It was something missing from my foundation. Now that I know about them, I (try to) follow the XP guideline of "write test, fail test, write code, pass test." It's just a more sanitary way to live, but you don't know that until you've seen it.

For your "Do Foo in Bar" thing ... we're actually have this discussion on the extreme-perl mailing list. (Well, Rob Nagler and Ovid are having the discussion while the rest of us are making sure no blood spills on the carpet.) I tend to agree with Rob, though not as vehemently. He feels that Perl has all the tools he has ever needed for the projects he's run into, and I agree with that. The big eye-openers for me have been when I learned to program thinking of

• lists instead of items (map/grep/sort vs. for/while)
• functions as first-class items (dispatch tables, closures, etc)
• objects as both instances of classes and entities in their own right (classic OO vs. prototyped OO)

I'm certain a few others can be described, as well. If you teach those, in Perl, then you're well on your way to giving your students many of the benefits of other languages. This isn't a substitute for learning Haskell or Smalltalk, but it's a good start.