I can't begin to imagine how much MORE complicated reproducing a regex long-hand might be. They were invented to solve real problems.

The corresponding FSM usually isn't too bad. I've personally never really used regexes that much in production code, but I guess I don't work with strings very often.

It's actually pretty easy to hardcode a regex. Most CS degrees expose students to how finite state machines work and that's all that's needed.

Well, I read Jeffrey Friedl's "Mastering Regular Expressions" two or three times since the 2nd edition was released and I can tell you there's no way anything more than a simple regex is going to be easier to grok when converted to some FSM, especially with look-behind or lazy operators and significant backtracking. I'm referring to the Perl/PCRE regular expression flavour which is the only variant that matters to me. Perl regexen are NFA so I'm not sure your assumptions about FSMs apply.

It's not always simple. Regexes have inherent complexity because the equivalent FSM is, in general case, nondeterministic. This implies it cannot always be easily simulated.

So you either drag this complexity into your code or dump it on the regex library. It's a trade-off.

> debugging why a particular regex works slowly

I encountered one of these once. A user decided to enter this in the middle of their post:

  ------------------------------

It triggered catastrophic backtracking, and IIRC, 16 characters was right around where you could see noticeable delay, then at about 19 was when it ran so long it never returned.