4 ms·

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 sha

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.

cutler 6y ago
I can't begin to imagine how much MORE complicated reproducing a regex long-hand might be. They were invented to solve real problems.
- smabie 6y ago
  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.
- ThrowawayR2 6y ago
  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.
  - praptak 6y ago
    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.
  - cutler 6y ago
    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.
Izkata 6y ago
> 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.

cutler 6y ago

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

smabie 6y ago
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.
ThrowawayR2 6y ago
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.
- praptak 6y ago
  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.
- cutler 6y ago
  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.

Izkata 6y ago

> 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.