3 ms·

Regexes get a bad rap mostly for two reasons: 1) they are abused by people who have never written a parser but need to write a parser, often to parse languages

Regexes get a bad rap mostly for two reasons: 1) they are abused by people who have never written a parser but need to write a parser, often to parse languages that are highly nonregular, and 2) they get thrown at problems where the underlying grammar is actually unknown and iterated on until they're uneditable black boxes. The first problem already has a really good solution: hire people who know the standard undergraduate CS material and you'll never end up with a regex-from-hell when a simple and easy recursive descent parser would've done the trick with ease. The second problem is, of course, more difficult. I've only seen regexes used successfully for a problem like that once. And that's only because the structure was very easy to think about as an NFA. By itself, the regex was a freaking nightmare to look at. But the documentation included a picture of the automata and a great description of what was going on. From there, the monstrous regex was easy to reason about and modify.

wahern 8y ago
hire people who know the standard undergraduate CS material and you'll never end up with a regex-from-hell when a simple and easy recursive descent parser would've done the trick with ease The number of programmers whom I've personally worked with that actually applied proper parsing principles in their work are exceedingly few--count on one hand, few; too few to make generalizations. But suffice it to say not all had CS degrees, nor even a degree of any kind. By contrast, most of the people I've worked with professionally have had a CS degree, and regex abuse is rife. I'm sure the reasons are varied and complex (never really grasped it, unable to recognize appropriate situations, can't apply it in larger code bases, or are simply unable to resist easy fixes when under pressure), but the end result is the same.
- thrmsforbfast 8y ago
  > But suffice it to say not all had CS degrees, nor even a degree of any kind. You will notice that I very carefully worded that post. The word degree wasn't used. Among all the coding quiz questions that get asked in interviews, the parsing-related questions make a ton of sense to me. Being able to bang out a reasonable parser -- and more importantly, knowing which type is needed for which problems -- is an actually useful skill and an even better indicator. > most of the people I've worked with professionally have had a CS degree, and regex abuse is rife. IME this can be shortened to simply: > regex abuse is rife.
  - perl4ever 8y ago
    "> But suffice it to say not all had CS degrees, nor even a degree of any kind. You will notice that I very carefully worded that post. The word degree wasn't used." I sympathize with those shaking their heads at people using regexes to parse XML, for instance. I have fought the battle of trying to get people to do it right. However, in (my version of) the real world, people will give you data that is invalid according to a canonical parser or the language standard, so sometimes you might as well use regexes anyway. A lot of professional programming is more like being an auto mechanic than being an automotive engineer. HN gravitates towards the latter mindset.
    - thrmsforbfast 8y ago
      > However, in (my version of) the real world, people will give you data that is invalid according to a canonical parser or the language standard, so sometimes you might as well use regexes anyway. This is very true, and I mention this in my top-level reply: > Regexes get a bad rap mostly for two reasons: ... 2) they get thrown at problems where the underlying grammar is actually unknown and iterated on until they're uneditable black boxes. When the (non-fuzzy) version of the input language is regular, then robustifying a regex can be the right way to go. And blaming the person who chose regexes on the basis that they used regexes doesn't make sense if the robustification isn't good enough. The failure to sufficiently robustify is a failure of domain knowledge about that particular fuzzy parsing task, not a failure of training. However, if a developer is using regexes to parse XML then they're Doing It Wrong (TM), even if the XML files they're parsing are not always valid XML. It's much easier to robustify the right solution to the idealized problem than it is to robustify the wrong solution to the idealized problem. > A lot of professional programming is more like being an auto mechanic than being an automotive engineer. HN gravitates towards the latter mindset. That's true. But also, a lot of professional programming is more like being an auto mechanic even though it should be like being an automotive engineer. Including, unfortunately for a hundred deceased Toyota vehicle owners, automotive software engineering.

wahern 8y ago

hire people who know the standard undergraduate CS material and you'll never end up with a regex-from-hell when a simple and easy recursive descent parser would've done the trick with ease The number of programmers whom I've personally worked with that actually applied proper parsing principles in their work are exceedingly few--count on one hand, few; too few to make generalizations. But suffice it to say not all had CS degrees, nor even a degree of any kind. By contrast, most of the people I've worked with professionally have had a CS degree, and regex abuse is rife. I'm sure the reasons are varied and complex (never really grasped it, unable to recognize appropriate situations, can't apply it in larger code bases, or are simply unable to resist easy fixes when under pressure), but the end result is the same.

thrmsforbfast 8y ago
> But suffice it to say not all had CS degrees, nor even a degree of any kind. You will notice that I very carefully worded that post. The word degree wasn't used. Among all the coding quiz questions that get asked in interviews, the parsing-related questions make a ton of sense to me. Being able to bang out a reasonable parser -- and more importantly, knowing which type is needed for which problems -- is an actually useful skill and an even better indicator. > most of the people I've worked with professionally have had a CS degree, and regex abuse is rife. IME this can be shortened to simply: > regex abuse is rife.
- perl4ever 8y ago
  "> But suffice it to say not all had CS degrees, nor even a degree of any kind. You will notice that I very carefully worded that post. The word degree wasn't used." I sympathize with those shaking their heads at people using regexes to parse XML, for instance. I have fought the battle of trying to get people to do it right. However, in (my version of) the real world, people will give you data that is invalid according to a canonical parser or the language standard, so sometimes you might as well use regexes anyway. A lot of professional programming is more like being an auto mechanic than being an automotive engineer. HN gravitates towards the latter mindset.
  - thrmsforbfast 8y ago
    > However, in (my version of) the real world, people will give you data that is invalid according to a canonical parser or the language standard, so sometimes you might as well use regexes anyway. This is very true, and I mention this in my top-level reply: > Regexes get a bad rap mostly for two reasons: ... 2) they get thrown at problems where the underlying grammar is actually unknown and iterated on until they're uneditable black boxes. When the (non-fuzzy) version of the input language is regular, then robustifying a regex can be the right way to go. And blaming the person who chose regexes on the basis that they used regexes doesn't make sense if the robustification isn't good enough. The failure to sufficiently robustify is a failure of domain knowledge about that particular fuzzy parsing task, not a failure of training. However, if a developer is using regexes to parse XML then they're Doing It Wrong (TM), even if the XML files they're parsing are not always valid XML. It's much easier to robustify the right solution to the idealized problem than it is to robustify the wrong solution to the idealized problem. > A lot of professional programming is more like being an auto mechanic than being an automotive engineer. HN gravitates towards the latter mindset. That's true. But also, a lot of professional programming is more like being an auto mechanic even though it should be like being an automotive engineer. Including, unfortunately for a hundred deceased Toyota vehicle owners, automotive software engineering.