5 ms·

> Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. jwz's wit was a lot of fun in the earl

> Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. jwz's wit was a lot of fun in the early 2000s but that quote is too often used wrong. This quote is not about regexps, it's about using wrong tools for the job. Using it without context makes it sound dumb. "Well, what if regexp is exactly the right solution for that problem?".

lmm 11y ago
A regexp is almost always the wrong solution. It's a way of representing a finite state machine that obscures the states, which are the only valuable part of the state machine abstraction (they're inherently incomprehensible otherwise). And most implementations these days have random extensions, meaning you have all the performance and safety issues of a turing-complete programming language - but a much worse UX. They may have made sense in the days of ed and the teletype, when a terse incomprehensible expression was better than a slightly longer readable one, but they don't now.
- incepted 11y ago
  > A regexp is almost always the wrong solution. That's quite a sweeping statement. Sure, complex regexps can be hard to read but state machines are just hard to read for humans in general, whatever the form. What do you recommend for parsing simple text entries, then?
  - lmm 11y ago
    If there are no existing libraries, parser combinators. More verbose but so much more readable, and they make it much easier to parse into an actual structure rather than a list of match groups.
    - incepted 11y ago
      > More verbose but so much more readable First of all, "more readable" is extremely subjective. Second, there are a lot of different parser combinators, all with very different syntaxes. Finally, parser combinators are readable by people familiar with them and regexps are readable by people familiar with them. Regexps are also much more widespread and approachable. And very often, writing a parser combinator to parse a simple text entry is way overkill. There are many good reasons why regexps are so popular.
      - lmm 11y ago
        > Finally, parser combinators are readable by people familiar with them and regexps are readable by people familiar with them. Regexps are also much more widespread and approachable You don't have to be familiar with them to find something like: def emailAddress = userPart ~ "@" ~ hostnamePart ^^ {(username, at, hostname) => EmailAddress(username, hostname)} clearer than any regex. Named capture groups help a little bit but I've never seen people using them (and they don't have a consistent syntax across regex implementations either). > And very often, writing a parser combinator to parse a simple text entry is way overkill. Disagree. They can be very much a one-liner.
        incepted 11y ago
        I think you'd be hard pressed to find someone who doesn't know parser combinators tell you the snippet above is readable. First of all, what language is this? Well, I know, but you seem to forget that the parser combinator syntax varies per language. What's the equivalent syntax for Java? Or for Python? What about a language that doesn't have a parser combinator library? Or one that has several ones, all slightly different? I think you're falling prey to the specialist fallacy: you're obviously very comfortable with parser combinators but you've forgotten how long it took you to get there and you now see them as an ultimate solution to all problems without realizing their downsides.
        lmm 11y ago
        > First of all, what language is this? Well, I know, but you seem to forget that the parser combinator syntax varies per language. What's the equivalent syntax for Java? Or for Python? What about a language that doesn't have a parser combinator library? Or one that has several ones, all slightly different? I very deliberately didn't mention the language or the library, because I think the snippet is readable without knowing that. Minor syntax differences between libraries matter when writing, but not when reading, and reading is more important. (And it's not like there aren't several slightly different implementations of regexes) I'm not that committed to parser combinators - I'd be happy to consider alternatives - but anything where you a) name the things you're capturing b) can easily combine several small parsers to make a bigger parser will have a huge readability, testability and maintainability advantage over regexes.

lmm 11y ago

A regexp is almost always the wrong solution. It's a way of representing a finite state machine that obscures the states, which are the only valuable part of the state machine abstraction (they're inherently incomprehensible otherwise). And most implementations these days have random extensions, meaning you have all the performance and safety issues of a turing-complete programming language - but a much worse UX. They may have made sense in the days of ed and the teletype, when a terse incomprehensible expression was better than a slightly longer readable one, but they don't now.

incepted 11y ago
> A regexp is almost always the wrong solution. That's quite a sweeping statement. Sure, complex regexps can be hard to read but state machines are just hard to read for humans in general, whatever the form. What do you recommend for parsing simple text entries, then?
- lmm 11y ago
  If there are no existing libraries, parser combinators. More verbose but so much more readable, and they make it much easier to parse into an actual structure rather than a list of match groups.
  - incepted 11y ago
    > More verbose but so much more readable First of all, "more readable" is extremely subjective. Second, there are a lot of different parser combinators, all with very different syntaxes. Finally, parser combinators are readable by people familiar with them and regexps are readable by people familiar with them. Regexps are also much more widespread and approachable. And very often, writing a parser combinator to parse a simple text entry is way overkill. There are many good reasons why regexps are so popular.
    - lmm 11y ago
      > Finally, parser combinators are readable by people familiar with them and regexps are readable by people familiar with them. Regexps are also much more widespread and approachable You don't have to be familiar with them to find something like: def emailAddress = userPart ~ "@" ~ hostnamePart ^^ {(username, at, hostname) => EmailAddress(username, hostname)} clearer than any regex. Named capture groups help a little bit but I've never seen people using them (and they don't have a consistent syntax across regex implementations either). > And very often, writing a parser combinator to parse a simple text entry is way overkill. Disagree. They can be very much a one-liner.
      - incepted 11y ago
        I think you'd be hard pressed to find someone who doesn't know parser combinators tell you the snippet above is readable. First of all, what language is this? Well, I know, but you seem to forget that the parser combinator syntax varies per language. What's the equivalent syntax for Java? Or for Python? What about a language that doesn't have a parser combinator library? Or one that has several ones, all slightly different? I think you're falling prey to the specialist fallacy: you're obviously very comfortable with parser combinators but you've forgotten how long it took you to get there and you now see them as an ultimate solution to all problems without realizing their downsides.
        lmm 11y ago
        > First of all, what language is this? Well, I know, but you seem to forget that the parser combinator syntax varies per language. What's the equivalent syntax for Java? Or for Python? What about a language that doesn't have a parser combinator library? Or one that has several ones, all slightly different? I very deliberately didn't mention the language or the library, because I think the snippet is readable without knowing that. Minor syntax differences between libraries matter when writing, but not when reading, and reading is more important. (And it's not like there aren't several slightly different implementations of regexes) I'm not that committed to parser combinators - I'd be happy to consider alternatives - but anything where you a) name the things you're capturing b) can easily combine several small parsers to make a bigger parser will have a huge readability, testability and maintainability advantage over regexes.