My coworker used to teach non-technical people how to code. Students always found regex hard to understand.<p>Let's be honest, regex can be hard to understand even for technical people. (At least it's hard for me.)<p>So coworker built this to help anyone understand arbitrary regex commands.<p>AI disclosure: this was built using Agent Duel, a local coding agent arena system (<a href="https://github.com/bottomless/agent-duel" rel="nofollow">https://github.com/bottomless/agent-duel</a>). 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 <i>conceptually</i> incredibly easy to understand.<p>But regex is also <i>syntactically</i> designed by Satan himself.<p>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.<p>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, <i>on top of</i> escaping regex symbols within the regex itself.<p>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:<p><pre><code> ^(\+\d{1,3}-?)?\d{3}-\d{3}-\d{4}$
</code></pre>
We would write something like:<p><pre><code> <start>
<optional> # Optional country code
"+"
<digit>[1-3]
"-"
</optional>
<digit>[3] # Area code
"-"
<digit>[3]
"-"
<digit>[4]
<end>
</code></pre>
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...
If you want readability you can write<p><pre><code> ^(?P<country_code>\+[0-9]{1,3}-?)?[0-9]{3}-[0-9]{3}-[0-9]{4}$
</code></pre>
Most regex engines even have a verbose mode (typically the x flag) where this is a valid regex:<p><pre><code> ^
(
\+
[0-9]{1,3}
-?
)? # optional country code
[0-9]{3}
-
[0-9]{3}
-
[0-9]{4}
$
</code></pre>
I am not sure if everyone writes unreadable regex because the reputation of regex makes it seem pointless to try, or if being witty one-liners is a critical part of the value proposition of regex
Regex in xml? Now you have 2 problems. And the comments are not xml comments even.<p>Ultimately it is a dsl. Should equations in math also use full words and comments?<p>No, they should not. Maybe a nice syntax for grammars like raku is a better approach.
Most regex dialects allow whitespace and comments, so that already gets you halfway there.
You can enable extended mode for most engines, which allows you to add white space and comments.<p>Personally, I like regexes, in the same way that I like shell string manipulation: it looks utterly inscrutable, and performs magic. If I write one in code meant for others, I usually use extended mode with each line commented.
I think some languages do have a library-style version of regex. But the function names aren't consistent between the different libraries. Maybe then we need to put on special goggles to make them look the same.
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.<p>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.<p>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<p><pre><code> .
|
?
*
+
</code></pre>
regex only has capture groups<p><pre><code> ()
</code></pre>
and lazy variants of the core quantifiers "?", "*" and "+", which are helpfully called:<p><pre><code> ??
*?
+?
</code></pre>
The rest is just shorthands.<p>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.
Really cool. Do you teach people the mechanics, like what the app shows? Because I wonder if that actually makes it <i>harder</i>. I'm wondering about where the hard bits are, given that it all boils down to just:<p><pre><code> "|", which means "or"
".", which means "any symbol"
"?", which means "at most once",
"*", which means "however many times"
"+", which means "at least once"
</code></pre>
Maybe encountering it next to PEG scrambles your brain.