And when you have an SQL query that runs too slow, that's an indication that you should switch to NoSQL. And when you are bathing an infant and the water gets too dirty, that's an indication that you should throw out the baby with the bath water.

As I've switched jobs, and am now living in a C# and Javascript world, I've found developers to be extremely paranoid about regular expressions. They aren't the best tool for all jobs, but they are the best tool for some jobs. And it is beneficial to not only know what those jobs are, but to know the language well enough to get those jobs done.

So, I'll grant that they may be best off by removing the regexes and replacing them with something else. That may or may not be because regexes aren't the right tool for this job. But, more importantly, their developers don't really understand the language, or at least not well enough for this complex of a requirement. (I'll freely admit: I don't know regexes well enough to write an xml parser in it, so I wouldn't, even if that was the best language for that job - I doubt it is, but whether it is or isn't is moot if I'm the one coding it.)

And I'll say that I'm finding a lot of devs' understanding of SQL is in much the same boat. I usually liken the two languages, regex and SQL, as they are both weird non-C-style languages (moreso than python) where everything is just insane if you don't really know what you're doing. And if you do know what you're doing, they're not really that bad.