6 ms·

> They didn't even like you to use regular expressions when case statements could be used. I'm confused. How are those two related? Case statements can replace

> They didn't even like you to use regular expressions when case statements could be used. I'm confused. How are those two related? Case statements can replace if statements and can be used for exhaustiveness checking. Regexes are for parsing strings.

sbarre 6y ago
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.
- kradroy 6y ago
  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.
praptak 6y ago
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.

sbarre 6y ago

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.

kradroy 6y ago
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.

praptak 6y ago

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.