...colleagues who tend to do a lot of elaborate string manipulation using only built-in string functions—a common anti-pattern I've observed

if ($nodename =~ /$mynode/)
[download]

if ($nodename eq $mynode)
[download]

I faced a similar Perl training problem a few years back and sent out an email with seven specific word puzzle problems against the Unix "words" file (e.g. /usr/dict/words). I offered some sort of prize for the winner IIRC. All could be solved as one liners using: perl -ne 'your-program-here' words or via a longer program, if you prefer. For example: find all palindromes; find the longest word in the dictionary; find all words that contain a particular letter four or more times; find all words that start with "e", have "n" as their second last letter, and are greater than seven characters in length; find all words that are of even length and contain an even number of each and every distinct vowel in the word. There are an endless number of interesting word puzzles available. You can further ask them to produce both regex and non-regex solutions, to compare and contrast which approach is more appropriate for each problem. It is not hard to invent problems where the regex solution is vastly superior to the non-regex one, which may help convince them of the power of regex.

Update: See also:

• How to Teach Perl to Scholars in the Humanities and Update: Teaching Perl in the Humanities
• Training non-programmers in Perl regexps
• Teaching perl over lunch
• Bling Bling (or: Teaching Perl to Teenagers)

Since "Mastering Regular Expressions" by Jeffrey Friedl is wildly recognized as a very good resource on regular expressions (and I found it a very good read too), I'd closely follow the example-driven approach used in that book, and use some examples that are relevant for your colleagues.

regex cheat sheet

Re^3: My Favourite Regex Tools (Was: Parsing a Variable Format String)

and although it's bash, I like txt2regex, which has Perl regex output, and has helped me many times

Regular expressions often look more complicated than they are. It's easy to get lazy, look at a ridiculous string, and just not start. I would spend time emphasizing the need to break them down into their components in order to understand them. Yeah, its work, but that's the job. Sometimes a long regexp is the perfect tool for the job.

I would emphasize simplicity. Find real-world examples in the code you maintain that might have been more easily accomplished with regular expressions. Careful not to be picking on the authors while doing so. It's a tough balance, but these examples will directly speak to practicality and value.

Another tactic I've used in refactoring work is clearly describing how truly complex what they've created is. Any code replacing a complicated regular expression is bound to be complex itself. I get lots of emotional feedback in my refactoring work about "overly complicated code" (read: objects). What they're missing is the complexity in what its replacing. It's just a different complexity, the one they understand (and aren't maintaining so good). Get to the truth of the matter, break down the emotional knee-jerk responses.

One objective would be to convince those colleagues who tend to do a lot of elaborate string manipulation using only built-in string functions—a common anti-pattern I've observed—to use regular expression pattern matching instead.

How would you teach a class on regular expressions? What would your approach be?

How much do your co-workers know? Do they know the concept? Are they familiar with at least v8 style regexes? (as used by grep, sed, vi, awk, etc). They you can skip the basics and focus on more advanced things. Otherwise, 4-8 hours is just enough to do the basics.

You could also look at YAPE::Regex::Explain.

Consider also including tools such as Parse::RecDescent.

Many tasks involve regular expressions (as this module of course does), but are best-described using a more complex logical structure of which “regular expressions” are simply a primitive-part.   Sometimes the task involves considering among multiple alternatives, such that you need to “back up and try another alternative.”   That is what Parsers do, and this one happens to be a very good one.