they're hard to use too, because there are quirks and gotchas that, if not treated correctly, could lead to disastrous performances;
Maybe.
they're also immensely harder to debug, because you can't run step-by-step their execution: they're basically atomic statements.
Of course you can step-by-step a RE. It's just a finite automata; just step though it.
And that's indeed another aspect to consider: many regex engines are slow to boot but we have to deal with that, because we simply just have no alternatives. And also have awkward APIs, too.
But we do have alternatives. Ragel, as mentioned above, is a really good one. re2 for python is supposedly good. The rust regex is good. Alex is also pretty good.
The language and what you can do with it is standardized - unions, differences, kleene stars and so on. The rest is just syntax.
Not so easy. The point is that you can't transpose a regular expression from a different language without any second thinking. It means that regular expressions are another layer of programming language that you have to take into consideration.
A well designed regex engine is a finite automata. That's it.
A computer doesn't care what a regex is. You shouldn't either, as it doesn't make any difference. The implementation can be very different and something that should be cared about.
That's not a regular expression: it's a list of definitions used by a regex engine.
Of course you can step-by-step a RE. It's just a finite automata; just step though it.
Only if you have a library that replicate a regex engine. In many languages, you just use the regular expression engine that's natively implemented, because any non-native solution is usually several orders of magnitude slower, it's basically a reinvented wheel, and it just adds another dependency to the project.
If it's slower and takes additional configuration, the "fastest and simplest you can do" part simply disappears.
But we do have alternatives.
In some languages maybe they're worth considering. But nobody uses a custom regex engine in JavaScript, or in PHP, or in Python, except for very limited cases.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sure, that quote is fun, but it doesn't carry a very strong point.
The language and what you can do with it is standardized - unions, differences, kleene stars and so on. The rest is just syntax.
A well designed regex engine is a finite automata. That's it.
I don't think this is too hard to read.
Maybe.
Of course you can step-by-step a RE. It's just a finite automata; just step though it.
But we do have alternatives. Ragel, as mentioned above, is a really good one. re2 for python is supposedly good. The rust regex is good. Alex is also pretty good.
Not so easy. The point is that you can't transpose a regular expression from a different language without any second thinking. It means that regular expressions are another layer of programming language that you have to take into consideration.
A computer doesn't care what a regex is. You shouldn't either, as it doesn't make any difference. The implementation can be very different and something that should be cared about.
That's not a regular expression: it's a list of definitions used by a regex engine.
Only if you have a library that replicate a regex engine. In many languages, you just use the regular expression engine that's natively implemented, because any non-native solution is usually several orders of magnitude slower, it's basically a reinvented wheel, and it just adds another dependency to the project.
If it's slower and takes additional configuration, the "fastest and simplest you can do" part simply disappears.
In some languages maybe they're worth considering. But nobody uses a custom regex engine in JavaScript, or in PHP, or in Python, except for very limited cases.