My coworker used to teach non-technical people how to code. Students always found regex hard to understand.
Let's be honest, regex can be hard to understand even for technical people. (At least it's hard for me.)
So coworker built this to help anyone understand arbitrary regex commands.
AI disclosure: this was built using Agent Duel, a local coding agent arena system (https://github.com/bottomless/agent-duel). Promotion disclosure: our company is building agent duel. To test it and find bugs we are building passion projects through the system. I nonetheless thought HN would find this interesting.
Regex is conceptually incredibly easy to understand.
But regex is also syntactically designed by Satan himself.
Most programming languages use commands that are semantically understandable, like "for" and "let" and "return" and mostly symbols we already know like "+" and "=". They use newlines and indentation for organization. And they put multiple commands on multiple lines and you can add comments and everything.
Regex is exclusively punctuation, with its own idiosyncratic meanings, all compressed into a single line, zero organization, zero comments, and impossible to remember what each symbol does if you don't use it daily. Not to mention the nightmare of escaping regexes when expressed as strings, on top of escaping regex symbols within the regex itself.
I swear it's high time we come up with a regex replacement that looks like normal Python code or HTML or something. So instead of:
^(\+\d{1,3}-?)?\d{3}-\d{3}-\d{4}$
We would write something like:
<start>
<optional> # Optional country code
"+"
<digit>[1-3]
"-"
</optional>
<digit>[3] # Area code
"-"
<digit>[3]
"-"
<digit>[4]
<end>
Same thing. But one is completely inscrutable to someone who hasn't learned regex, while with the other you can guess pretty easily how it works...
I am mostly an autodidact and learned bits regex on the fly when I needed it and I was always baffled why people have auch a hard time with it.
The problem IMO is that a lot of the traditional teaching material starts with the complexity (and impressive possibilities) of regex, when the best way to start learning it is probably just thinking about it as an extension to simple text matching.
Getting to know regex fully is in fact complicated, getting know enough regex to filter/search/replace 90% of everything you will always need is not too complicated.
Autodidact here. Beyond just the five core quantifiers
.
|
?
*
+
regex only has capture groups
()
and lazy variants of the core quantifiers "?", "*" and "+", which are helpfully called:
??
*?
+?
The rest is just shorthands.
So while I think it's a worthwhile suggestion not to show people the whole thing the first time round, I doubt that the whole thing is really that complicated.
Regex has many more features than this, e.g. backreferences. I agree that it's easy to learn enough regex to be dangerous with that subset, but that's not everything regex offers.
Backreferencing inside of a regex (which is a way to find repeat occurrences of a substring) is a very controversial feature that some regex engines intentionally omit, while most others support it only grudgingly. Supporting backreferences opens up a big can of worms: Most regex engines will fall back to a slow, poorly optimised algorithm if they ever encounter backreferences.
Also, it's important for people not to confuse backreferences with capture groups. They look a bit similar, but capture groups are actually fine.
In fact, backreferencing is such a footgun that I don't see it as a possible regex feature. It's a PCRE feature - perhaps even the core distinguishing feature. While all regexes are PCREs, not all PCREs are regexes. It's simply not possible to create a consistently performant implementation of PCRE.
Really cool. Do you teach people the mechanics, like what the app shows? Because I wonder if that actually makes it harder. I'm wondering about where the hard bits are, given that it all boils down to just:
"|", which means "or"
".", which means "any symbol"
"?", which means "at most once",
"*", which means "however many times"
"+", which means "at least once"
Maybe encountering it next to PEG scrambles your brain.
Let's be honest, regex can be hard to understand even for technical people. (At least it's hard for me.)
So coworker built this to help anyone understand arbitrary regex commands.
AI disclosure: this was built using Agent Duel, a local coding agent arena system (https://github.com/bottomless/agent-duel). Promotion disclosure: our company is building agent duel. To test it and find bugs we are building passion projects through the system. I nonetheless thought HN would find this interesting.
But regex is also syntactically designed by Satan himself.
Most programming languages use commands that are semantically understandable, like "for" and "let" and "return" and mostly symbols we already know like "+" and "=". They use newlines and indentation for organization. And they put multiple commands on multiple lines and you can add comments and everything.
Regex is exclusively punctuation, with its own idiosyncratic meanings, all compressed into a single line, zero organization, zero comments, and impossible to remember what each symbol does if you don't use it daily. Not to mention the nightmare of escaping regexes when expressed as strings, on top of escaping regex symbols within the regex itself.
I swear it's high time we come up with a regex replacement that looks like normal Python code or HTML or something. So instead of:
We would write something like: Same thing. But one is completely inscrutable to someone who hasn't learned regex, while with the other you can guess pretty easily how it works...The problem IMO is that a lot of the traditional teaching material starts with the complexity (and impressive possibilities) of regex, when the best way to start learning it is probably just thinking about it as an extension to simple text matching.
Getting to know regex fully is in fact complicated, getting know enough regex to filter/search/replace 90% of everything you will always need is not too complicated.
So while I think it's a worthwhile suggestion not to show people the whole thing the first time round, I doubt that the whole thing is really that complicated.
Also, it's important for people not to confuse backreferences with capture groups. They look a bit similar, but capture groups are actually fine.
In fact, backreferencing is such a footgun that I don't see it as a possible regex feature. It's a PCRE feature - perhaps even the core distinguishing feature. While all regexes are PCREs, not all PCREs are regexes. It's simply not possible to create a consistently performant implementation of PCRE.