[cbuq]

There is a saying (which I can't remember the source) that I always thought described regex perfectly in my experience.

"Beginner programmers don't understand regex, good programmers understand regex, the best programmers don't use regex."

I've found regex is a poor choice in production systems because it is very hard to maintain (which this library tries to address) and very hard to test (which this library does not address).

However, regex is perfect for that complicated one-time find and replace.

[nneonneo]

Like anything in programming, regular expressions are a tool. Yes, it might be unusually easy to shoot yourself in the foot with this particular tool, but that doesn't make them not valuable at all. I'd argue that the best programmers use them judiciously and cautiously, as they would any fancy language feature.

Case in point: logfile analysis. Often times you might have a log file with many different kinds of messages formatted in many different ways, only some of which you care about. A quick regular expression can pull out the messages of interest, and extract out the bits you care about. Sure, in an ideal world you'd ingest the logging data in some structured format, but the real world simply does not hand you the luxury of controlling all your upstream data sources all the time.

[cbuq]

I think logfile analysis is a perfect example. Regex could be the perfect tool for one-shot analysis of logs. But if you are writing an actual commercial application to do logfile analysis, regex is probably not the right tool.

[theamk]

What would you use in the actual commercial applications?

I have seen people try to replace regexes with sequences of splits and accesing hardcoded field numbers. This can inmprove readability in the simple cases, but makes code much more fragile in the complex cases.

Another approach I have seen is a full featured lexer. Looks clean and very fadt, but in my experience is an overkill for most tasks