I never understood why so many developers have problems with Regex.
In my experience, it's difficult because most people avoid it, once you use it enough times the logic makes perfect sense.
1. Regular expressions are often used instead of existing parsers. XML, CSV, file paths, URIs etc. all already have fast, well tested and correct parsers.
2. Often the thing worked on should not be a string in the first place. For example comma separated string is used instead of a list and regular expression emulate list operations.
3. Some things could be processed much easier with different tool - for example recursive descent parser. Yet the developer still tries to parse arithmetic expressions with a hammer.
4. They are often developed via trial and error. They are either first thing which worked for a simple case or are 10 line monsters riddled with exceptions from exceptions.
5. They are often part of hacks and workarounds. For example User-Agent is matched to work around bugs in browsers.
3. They give very limited feedback to user. There is either a match or no match. There is no way to tell what and where is broken.
There are valid use cases for regular expressions. It's even possible to write correct code with them. It's just a rare sight.
As DOM query:
document.getElementsByClassName("title")[0].parentElement.getElementsByTagName("a")[1].href
* When title element no longer has "title" class.
* When title is no longer a sibling of link.
* When link is no longer 2nd link of its parent.
As regular expression:
document.documentElement.innerHTML.match('td class="title">.*a href="([^"]*)"')[1]
* On any white space change.
* On any new attributes on td or a.
* When ' is used instead of "
* When href includes escaped "
* In most cases when DOM query will break.
Many of those can happen without any server-side changes. It will sometimes works sometimes won't - making it hard to test.
There are cases when regular expression will break less often than DOM but DOM is easier to reason about, more predictable and has less corner cases.
1. Those hosts are still broken. The next person will have to jump the same hoops to support them.
2. You parser is very permissive. It will encourage people to create even more broken implementations.
3. The specification of this protocol is now worthless. There is no way to safely add new functionality. Any new element or attribute can break those regexes. Everyone has to take every implementation into account.
4. You are probably missing some corner cases like CDATA elements or quoted characters.
From your point of view, it probably makes sense to support even broken sites. But, you are helping to create next HTML - where every implementation works differently and you have to test everything on every browser.
(also, too many kids on my lawn etc)
People don't want to learn because it's hard?
"Most users of regexps or any other device do not need to read a thick theory book on it."
Which is why they should at the very least read Friedl.
"Cobbling together expressions from online tutorials is a perfectly good way to learn effectively."
No it's not, otherwise we wouldn't have so many bad regexes and people asking silly questions about them, would we?
"Admittedly, it is not the best way to write production code, but there are often economic considerations that override the expert's desire for perfect design and implementation."
Nobody's talking about 'perfect design and implementation', just 'not be a moron' level. Because car analogies are everbody's favorite, let me use one here: no-one is saying that one should have a Formula 1 licence before driving (using regular expressions); just to have more than 20% vision in both eyes and not to drive after drinking 5 beers while texting your wife that you're on your way. Which is the car-driving equivalent of the majority of regex uses in the wild.
There is truth in that, but I meant to address your comment about other people's lack of education. Education (certificate granted by teaching authority), how good soever it may be, is not necessary to have knowledge or skill. Similarly, reading Friedl how good soever his work is, is not necessary to learn or use regular expressions.