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

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