All of the stuff you can do with regexes can be done with some hand written code. Since thst code often implements the FSM for the regex, it contains a fair share of case statements.

The benefit is that the regex library costs a lot in hidden complexity - debugging why a particular regex works slowly or eats lots of memory is hard. If a similar problem pops up in hand written code, you can use your standard profilers and other tools to see what's happening.

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.

I think the point was that even within the codebase, simplicity and reduced complexity was preferred over perhaps a "cleaner" or more advanced approach.

So managing a bunch of hard-coded code paths via a switch instead of using a regex to pattern-match.

It's less future-proof, but even an entry-level dev can reason about a switch statement and update it as needed.

This is exactly it. The nuances of regex patterns can be misconstrued. Obviously if the regex used for flow control cannot be sensibly translated to more traditional conditional statements, then they are permitted. Even in that case, the "simplest" regex was preferred.