4 ms·

Got to admire someone who is going to invest time to invent a whole new language just to avoid mastering an existing one. Regex is fine. Been using it nearly da

by gajus 4y ago

Got to admire someone who is going to invest time to invent a whole new language just to avoid mastering an existing one. Regex is fine. Been using it nearly daily for the last decade. You get used to it. These days, there are tools that make it incredibly easy to write, test, version and document regex, like https://regex101.com/ https://regex101.com/.

SonOfLilit 4y ago
Working with a company that writes hundreds of regexes per day, I can say with confidence: regex syntax is _not_ fine. People with lots of experience make obvious mistakes and lose them in the line noise all the time.
- xdfgh1112 4y ago
  Do you use the /x modifier?
  - SonOfLilit 4y ago
    The regexes are very simple, there's just thousands of them. /x wouldn't help much.
- donatj 4y ago
  What could the job possibly be? Based on next to nothing, sounds like you might be better off building custom parsers?
  - chrisshroba 4y ago
    I'd guess any large tech company on average is writing at least hundreds per day, given the crazy amounts of code being produced.
coldtea 4y ago
>Got to admire someone who is going to invest time to invent a whole new language just to avoid mastering an existing one. Yes, because any existing language is the global optimum, and we should always strive to reuse it, never invent any new one... I mean, what's the problem with stone cavemen-era cart-wheels? Why reinvent the wheel? Not to mention the implying that the only reason one would try to invent a new language is to "not invest time mastering an existing one". I.e. "It's not that this guy tries to improve regular expression languages - it's that he's dumb/lazy to master the standard regex expressions". Never mind that this new language also transpiles into regular regex, so clearly the person who created it has also "mastered the existing one".
- Underphil 4y ago
  You missed the obvious "why use C when assembly language exists?".
asicsp 4y ago
And https://www.debuggex.com/ https://www.debuggex.com/ for visualizing regex as railroad diagrams. I'd agree that we get used to regex with usage, but need to be extra careful to test all the corner cases (since by design, a pattern matches multiple things).
ur-whale 4y ago
> Regex is fine Hrm, I don't think regex is fine. It's well established yes. It's dense, concise and minimalist, yes. It is somewhat powerful, yes But there's a lot of places where it comes short: 1. Very steep learning curve for beginners, especially if they have to read a regex they didn't write themselves 2. Write-only language, just like APL: dense and concise, but a giant PITA to read once you've walked away from a complex regex for a couple of days. 3. Not standardized (sed regex vs. sed extended regex vs. perl regex vs. vim regex vs. bash regex vs. globbing vs. whatever else, it's never the same, what a giant effing PITA) 4. No proper integrated debugger (there might be some 3rd party out there, but it's never around when you need it, as in: integrated in whichever environment you are currently doing regexes in). When your large and complex regex fails good effing luck trying to figure you why, short of breaking it down in tiny pieces and debugging each in turn recursively. You don't even have access to a bloody printf. 5. Boolean trees of regexes (match blah OR blech AND NOT blargh, where blah, blech and blargh are themselves boolean trees of regexes) are a giant PITA to express within the language. 6. Overlap and confusion between capture '()' and factoring out an expression to plug into a dyadic OR. 7. No way to factor out common and/or repeating parts, like you would in a normal programming language. So any attempt at improving this mess is welcome in my book.
- bmn__ 4y ago
  > So any attempt at improving this mess is welcome in my book. Already done, I think. :) 2. Not a big problem if the responsible programmer employs named captures and named subpatterns, and switches on extended mode and makes use of whitespace and comments. Like with any other programming environments, it's a matter of wanting to write readable code, and perhaps enforcing this through technical and social means. 3. I observe that Perl-style regex have become the de facto standard, in the sense that numerous programming languages in common use have adopted it, and preceding styles are marginalised to the point that any discussion about regex that does not mention the style makes the assumption of Perl-style. The next points are actually implementation dependent. It is not fair to condemn regex as a whole just because some implementations fall short. 4. Perl has good debugging tools for regex. 5. This is easy to express in Perl. 6. Non-capturing grouping exists. 7. Named subpatterns exist, interpolation of variables containing regex values exists.
Benjamin_Dobell 4y ago
> Got to admire someone who is going to invest time to invent a whole new language just to avoid mastering an existing one Wow, that's unnecessarily inflammatory. This is the first I've ever heard of Rulex, yet it takes no more than a glance at the homepage to realise the author would have more mastery of regex than 99.99% of developers. Rulex transpiles to regex, running in a variety of engines. Meaning the author has not just mastered one regex dialect, but the subtleties of all supported regex engines (PCRE, JavaScript, Java, .NET, Python, Ruby and Rust).
- Someone 4y ago
  > Rulex transpiles to regex, running in a variety of engines. Meaning the author has not just mastered one regex dialect, but the subtleties of all supported regex engines Not necessarily. More likely, Rulex supports the common subset of features of those engines, with, where/if necessary, small syntactical differences in the output, ignoring many subtleties of implementations.
  - Aloso 4y ago
    (Author of rulex here) It's a middle ground, actually: When compiling a rulex, you specify the target regex flavor. Some features (e.g. lookaround and backreferences) aren't supported in every flavor. Some features are polyfilled by rulex, so they work even when the targeted regex engine doesn't. However, there are also features supported by PCRE that aren't available in rulex yet. Notably, atomic groups, recursion, character class intersection/subtraction and some mode modifiers aren't supported yet. Eventually I'd like to support all of PCRE's features.
vintermann 4y ago
It's all too clear that they master the regular expression syntax, because they explain their own in terms of it. And I for one have a hard time reading it. Regex is not fine. It's been recognized as a source of bugs for decades. Fredrik Lundh's famous quote: "Some people, when confronted with a problem, think ''I know, I'll use regular expressions!''. Now they have two problems." Claiming that nothing needs fixing here is a lot like claiming we don't need Rust because the C prepocessor does all we need, or that we don't need any fancy build tools because we have GNU autotools. I really see that sort of comment anymore anywhere but Slashdot. The issue is that ideally you use regex as little as possible anyway, so it's not worth the effort of fixing it and pushing for something better. The main problem with this proposal is that they use almost no time explaining why they've made the changes they made, and even to understand WHAT the changes are you have to be good at reading already existing regexes (which is harder than writing them!) That said, one change I spot which I heartily approve of, is reversing the quoting assumption. In regular regex, strings by default match themselves, and need to be escaped to get special meanings. This is a poor design because if you reach for regexes in the first place, it's the special meanings which are important, not the literal matches. Even the first change to regex (egrep) partially recognized this, by reversing the escaping assumption on ?, +, | and parentheses. Going all the way would have been the better decision, and I'm glad to see the authors of this project agree with me on that.
- SonOfLilit 4y ago
  I think you'll love the https://github.com/SonOfLilit/kleenexp https://github.com/SonOfLilit/kleenexp readme, then, I provide so. many. explanations. :)
- rtpg 4y ago
  I think the point of that quote is less about error prone regexes and more about regexes not being the right tool for many parsing problems. A new regex language doesn't really tackle that right? Maybe we need a new syntax generator language...
- gorjusborg 4y ago
  > "Some people, when confronted with a problem, think ''I know, I'll use regular expressions!''. Now they have two problems." This is a sort of funny tongue-in-cheek jab, not a factual statement. I'd chuckle if I heard someone say it in real life, but also eye-roll internally. There are some people who will write lines of substr code to trim whitespace from a string. That is the type of person I would expect to crack this joke. Regular expressions are fine, just like an oil filter wrench is fine. I wouldn't use an oil filter wrench to tighten a nut/bolt. I wouldn't write a single regular expression to validate an email address or implement a lexer. While I respect the effort put into making this project, I see it mostly as a distraction for new developers. If you are confused by regular expressions, you may be trying to do too much with them and/or you need to put some effort into mastering them (I recommend Jeffrey Friedl's Master Regular Expressions). If you try to pretend regular expressions don't exist, you are going to have a bad time. You will encounter them, unless you never touch existing code during your tenure. I also don't think this syntax is better. Regular expressions are terse, and that is a feature. It may feel like an anti-feature in larger expressions, but the secret is that if you are writing huge regular expressions, you are probably doing something wrong.
avgcorrection 4y ago
I genuinely admire someone who wants to improve on the regex DSL design. Clearly they will master regexp in the process since this new language compiles to regexp.
XorNot 4y ago
RegExr (https://regexr.com/ https://regexr.com/) doesn't come up enough in these discussions. One of the nicest regex debugging/development tools on the internet today.
tester756 4y ago
>Regex is fine Regex and Git are the worst really popular APIs up to date, it's sad because both are really good and powerful, but their APIs just suck. Regex maybe is fine in config files, but using it in programming languages that have way better expressivness it is just painful. I'd really want to replace Regex with something like C#'s LINQ
Aloso 4y ago
(Author of rulex here) Creating rulex has been quite a journey, during which I learned a lot about regex syntax, its quirks, and the differences between various regex flavors. I already knew a lot about regexes before I started this project, but creating a language that compiles to regexes requires a much deeper and more thorough understanding of them. I didn't create rulex so I don't have to master regexes. I created it so that people who use it don't have to master regexes -- a language that is riddled with poor design choices. Yes, you can get used to it, just like you can get used to working with a dull plastic knife. The fact that people need a website such as regex101 or regexr just shows, in my humble opinion, that regular expressions aren't as straightforward or easy to understand as they could be.

by gajus 4y ago

SonOfLilit 4y ago

Working with a company that writes hundreds of regexes per day, I can say with confidence: regex syntax is _not_ fine. People with lots of experience make obvious mistakes and lose them in the line noise all the time.

xdfgh1112 4y ago
Do you use the /x modifier?
- SonOfLilit 4y ago
  The regexes are very simple, there's just thousands of them. /x wouldn't help much.
donatj 4y ago
What could the job possibly be? Based on next to nothing, sounds like you might be better off building custom parsers?
- chrisshroba 4y ago
  I'd guess any large tech company on average is writing at least hundreds per day, given the crazy amounts of code being produced.

coldtea 4y ago

>Got to admire someone who is going to invest time to invent a whole new language just to avoid mastering an existing one. Yes, because any existing language is the global optimum, and we should always strive to reuse it, never invent any new one... I mean, what's the problem with stone cavemen-era cart-wheels? Why reinvent the wheel? Not to mention the implying that the only reason one would try to invent a new language is to "not invest time mastering an existing one". I.e. "It's not that this guy tries to improve regular expression languages - it's that he's dumb/lazy to master the standard regex expressions". Never mind that this new language also transpiles into regular regex, so clearly the person who created it has also "mastered the existing one".

Underphil 4y ago
You missed the obvious "why use C when assembly language exists?".

asicsp 4y ago

And https://www.debuggex.com/ https://www.debuggex.com/ for visualizing regex as railroad diagrams. I'd agree that we get used to regex with usage, but need to be extra careful to test all the corner cases (since by design, a pattern matches multiple things).

ur-whale 4y ago

> Regex is fine Hrm, I don't think regex is fine. It's well established yes. It's dense, concise and minimalist, yes. It is somewhat powerful, yes But there's a lot of places where it comes short: 1. Very steep learning curve for beginners, especially if they have to read a regex they didn't write themselves 2. Write-only language, just like APL: dense and concise, but a giant PITA to read once you've walked away from a complex regex for a couple of days. 3. Not standardized (sed regex vs. sed extended regex vs. perl regex vs. vim regex vs. bash regex vs. globbing vs. whatever else, it's never the same, what a giant effing PITA) 4. No proper integrated debugger (there might be some 3rd party out there, but it's never around when you need it, as in: integrated in whichever environment you are currently doing regexes in). When your large and complex regex fails good effing luck trying to figure you why, short of breaking it down in tiny pieces and debugging each in turn recursively. You don't even have access to a bloody printf. 5. Boolean trees of regexes (match blah OR blech AND NOT blargh, where blah, blech and blargh are themselves boolean trees of regexes) are a giant PITA to express within the language. 6. Overlap and confusion between capture '()' and factoring out an expression to plug into a dyadic OR. 7. No way to factor out common and/or repeating parts, like you would in a normal programming language. So any attempt at improving this mess is welcome in my book.

bmn__ 4y ago
> So any attempt at improving this mess is welcome in my book. Already done, I think. :) 2. Not a big problem if the responsible programmer employs named captures and named subpatterns, and switches on extended mode and makes use of whitespace and comments. Like with any other programming environments, it's a matter of wanting to write readable code, and perhaps enforcing this through technical and social means. 3. I observe that Perl-style regex have become the de facto standard, in the sense that numerous programming languages in common use have adopted it, and preceding styles are marginalised to the point that any discussion about regex that does not mention the style makes the assumption of Perl-style. The next points are actually implementation dependent. It is not fair to condemn regex as a whole just because some implementations fall short. 4. Perl has good debugging tools for regex. 5. This is easy to express in Perl. 6. Non-capturing grouping exists. 7. Named subpatterns exist, interpolation of variables containing regex values exists.

Benjamin_Dobell 4y ago

> Got to admire someone who is going to invest time to invent a whole new language just to avoid mastering an existing one Wow, that's unnecessarily inflammatory. This is the first I've ever heard of Rulex, yet it takes no more than a glance at the homepage to realise the author would have more mastery of regex than 99.99% of developers. Rulex transpiles to regex, running in a variety of engines. Meaning the author has not just mastered one regex dialect, but the subtleties of all supported regex engines (PCRE, JavaScript, Java, .NET, Python, Ruby and Rust).

Someone 4y ago
> Rulex transpiles to regex, running in a variety of engines. Meaning the author has not just mastered one regex dialect, but the subtleties of all supported regex engines Not necessarily. More likely, Rulex supports the common subset of features of those engines, with, where/if necessary, small syntactical differences in the output, ignoring many subtleties of implementations.
- Aloso 4y ago
  (Author of rulex here) It's a middle ground, actually: When compiling a rulex, you specify the target regex flavor. Some features (e.g. lookaround and backreferences) aren't supported in every flavor. Some features are polyfilled by rulex, so they work even when the targeted regex engine doesn't. However, there are also features supported by PCRE that aren't available in rulex yet. Notably, atomic groups, recursion, character class intersection/subtraction and some mode modifiers aren't supported yet. Eventually I'd like to support all of PCRE's features.

vintermann 4y ago

It's all too clear that they master the regular expression syntax, because they explain their own in terms of it. And I for one have a hard time reading it. Regex is not fine. It's been recognized as a source of bugs for decades. Fredrik Lundh's famous quote: "Some people, when confronted with a problem, think ''I know, I'll use regular expressions!''. Now they have two problems." Claiming that nothing needs fixing here is a lot like claiming we don't need Rust because the C prepocessor does all we need, or that we don't need any fancy build tools because we have GNU autotools. I really see that sort of comment anymore anywhere but Slashdot. The issue is that ideally you use regex as little as possible anyway, so it's not worth the effort of fixing it and pushing for something better. The main problem with this proposal is that they use almost no time explaining why they've made the changes they made, and even to understand WHAT the changes are you have to be good at reading already existing regexes (which is harder than writing them!) That said, one change I spot which I heartily approve of, is reversing the quoting assumption. In regular regex, strings by default match themselves, and need to be escaped to get special meanings. This is a poor design because if you reach for regexes in the first place, it's the special meanings which are important, not the literal matches. Even the first change to regex (egrep) partially recognized this, by reversing the escaping assumption on ?, +, | and parentheses. Going all the way would have been the better decision, and I'm glad to see the authors of this project agree with me on that.

SonOfLilit 4y ago
I think you'll love the https://github.com/SonOfLilit/kleenexp https://github.com/SonOfLilit/kleenexp readme, then, I provide so. many. explanations. :)
rtpg 4y ago
I think the point of that quote is less about error prone regexes and more about regexes not being the right tool for many parsing problems. A new regex language doesn't really tackle that right? Maybe we need a new syntax generator language...
gorjusborg 4y ago
> "Some people, when confronted with a problem, think ''I know, I'll use regular expressions!''. Now they have two problems." This is a sort of funny tongue-in-cheek jab, not a factual statement. I'd chuckle if I heard someone say it in real life, but also eye-roll internally. There are some people who will write lines of substr code to trim whitespace from a string. That is the type of person I would expect to crack this joke. Regular expressions are fine, just like an oil filter wrench is fine. I wouldn't use an oil filter wrench to tighten a nut/bolt. I wouldn't write a single regular expression to validate an email address or implement a lexer. While I respect the effort put into making this project, I see it mostly as a distraction for new developers. If you are confused by regular expressions, you may be trying to do too much with them and/or you need to put some effort into mastering them (I recommend Jeffrey Friedl's Master Regular Expressions). If you try to pretend regular expressions don't exist, you are going to have a bad time. You will encounter them, unless you never touch existing code during your tenure. I also don't think this syntax is better. Regular expressions are terse, and that is a feature. It may feel like an anti-feature in larger expressions, but the secret is that if you are writing huge regular expressions, you are probably doing something wrong.

avgcorrection 4y ago

I genuinely admire someone who wants to improve on the regex DSL design. Clearly they will master regexp in the process since this new language compiles to regexp.

XorNot 4y ago

RegExr (https://regexr.com/ https://regexr.com/) doesn't come up enough in these discussions. One of the nicest regex debugging/development tools on the internet today.

tester756 4y ago

>Regex is fine Regex and Git are the worst really popular APIs up to date, it's sad because both are really good and powerful, but their APIs just suck. Regex maybe is fine in config files, but using it in programming languages that have way better expressivness it is just painful. I'd really want to replace Regex with something like C#'s LINQ

Aloso 4y ago

(Author of rulex here) Creating rulex has been quite a journey, during which I learned a lot about regex syntax, its quirks, and the differences between various regex flavors. I already knew a lot about regexes before I started this project, but creating a language that compiles to regexes requires a much deeper and more thorough understanding of them. I didn't create rulex so I don't have to master regexes. I created it so that people who use it don't have to master regexes -- a language that is riddled with poor design choices. Yes, you can get used to it, just like you can get used to working with a dull plastic knife. The fact that people need a website such as regex101 or regexr just shows, in my humble opinion, that regular expressions aren't as straightforward or easy to understand as they could be.