in reply to Teaching Regular Expression Pattern Matching
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.