3 ms·

I'll disagree here. While I have quibbles about the specific API used in this project, I like the idea of an imperative regex builder, especially if it can be t

I'll disagree here. While I have quibbles about the specific API used in this project, I like the idea of an imperative regex builder, especially if it can be type checked. Every time I turn to regex, I waste time debugging which characters I forgot to escape or accidentally escaped when all the brackets and slashes blur together. I debug why some group isn't matching right because regex's semantic density makes it hard to tell where the group starts and ends. I turn to regex debuggers because they're necessary, but they're not great experiences, and at first glance I'd think a type checked regex builder could make debuggers unnecessary a lot of the time. There's also a discoverability problem. I know non-capturing groups and negative lookbehind are a thing, but I always have to look them up because it's hard to remember the arcane syntax if I don't use them often. And my peers don't even know some of those things exist, so they struggle to solve easy problems. A library that my editor would offer autocomplete suggestions for would really help this. I also think a regex builder would promote better organization - break the regex into parts, assign the parts to variables, and reuse portions of a regex. That's all possible with traditional regex, but I don't see folks doing it because it seems few folks know about verbose regex, building logic with string concatenation is discouraged in many situations, and if your language has a native regex data type, declining that in favor of string building feels weird. If all a regex builder did was reframe what developers feel is natural to do, that's beneficial.

lhorie 6y ago
For me, a regex usually has to be wrapped into a function, which I can then throw copious amounts of unit tests at. Regex is, IMHO, a easy-to-write hard-to-read language, so I find it more fruitful to use tests to specify what is the task being accomplished, so that - if it's easier - I can just rewrite the appropriate regex from scratch rather than trying to decipher how the old one is broken. If the task is complex enough, regex might not even be the right tool for the job, and the function boundary provides a sensible encapsulation boundary.
btilly 6y ago
Here is what I see. You want an automated tool to build a regular expression for people who don't understand regular expressions. There is no shortage of ways that this is going to lead to disasters. Starting with the fact that far too many developers do not understand the difference between pattern matching and parsing, and will reach for the wrong tool with no idea what it is doing and why they can't get it to do what they want. See https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags https://stackoverflow.com/questions/1732348/regex-match-open... for more.
- spiffytech 6y ago
  I'd like to clarify that my position isn't about "not understanding regular expressions". Sure, it could help people who don't. But even for people like me: I read the O'Reilly regex pocket book and other materials, I studied formal regular languages during college, built a basic lexer/parser for a senior project, I've written no shortage of simple and complicated regexes in application code in the workplace, and once in a conference lecture I was the first audience member to recognize and shout out when the speaker quizzed which commonplace file format the given gnarly full-page regex matched. I'll never be up there with Brian Kernighan[0], but I know my way around regex at least as well as what I feel is reasonable to expect and accommodate from the average developer. My position is that even with a background in regexes that's a lot deeper than just Googling and putzing on Regex101.com, traditional regex syntax is still a frustrating time sink that's hard to get correct without more trial-and-error than feels intrinsically necessary. The syntax provides zero opportunity to discover there's a more effective way to perform a task. I have trouble identifying a compelling value proposition for traditional syntax besides familiarity and natural serializability, and the fact that it gets the job done at all. I don't believe traditional regex syntax is the optimal way to accomplish text pattern matching tasks in the workplace, and I'm open to other tooling that makes it success simpler and more reliable. People misuse regexes all the time (examples like the one you linked are almost tropes at this point), but I don't think that's compelling justification on its own for preserving the status quo. [0] https://www.cs.princeton.edu/courses/archive/spr09/cos333/beautiful.html https://www.cs.princeton.edu/courses/archive/spr09/cos333/be...
  - btilly 6y ago
    My only complaint about the regex syntax is that it does not allow you to separate things out with whitespace, or add comments about what the chunked units. The x modifier fixes both. What you traditionally see with a complex RE for a complex pattern is the same as what you traditionally see with someone writing complex SQL statements on a single line. Stop trying to treat it like a black box, and treat it as a programming language in its own right. Use whitespace, indentation, and comments (when necessary) to communicate intent as well as just to make it do its job. Other than that, regular expressions say what they mean and mean what they say very concisely directly. Particularly the PCRE variants of the language. I consider that conciseness and directness a virtue.

lhorie 6y ago

For me, a regex usually has to be wrapped into a function, which I can then throw copious amounts of unit tests at. Regex is, IMHO, a easy-to-write hard-to-read language, so I find it more fruitful to use tests to specify what is the task being accomplished, so that - if it's easier - I can just rewrite the appropriate regex from scratch rather than trying to decipher how the old one is broken. If the task is complex enough, regex might not even be the right tool for the job, and the function boundary provides a sensible encapsulation boundary.

btilly 6y ago

Here is what I see. You want an automated tool to build a regular expression for people who don't understand regular expressions. There is no shortage of ways that this is going to lead to disasters. Starting with the fact that far too many developers do not understand the difference between pattern matching and parsing, and will reach for the wrong tool with no idea what it is doing and why they can't get it to do what they want. See https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags https://stackoverflow.com/questions/1732348/regex-match-open... for more.

spiffytech 6y ago
I'd like to clarify that my position isn't about "not understanding regular expressions". Sure, it could help people who don't. But even for people like me: I read the O'Reilly regex pocket book and other materials, I studied formal regular languages during college, built a basic lexer/parser for a senior project, I've written no shortage of simple and complicated regexes in application code in the workplace, and once in a conference lecture I was the first audience member to recognize and shout out when the speaker quizzed which commonplace file format the given gnarly full-page regex matched. I'll never be up there with Brian Kernighan[0], but I know my way around regex at least as well as what I feel is reasonable to expect and accommodate from the average developer. My position is that even with a background in regexes that's a lot deeper than just Googling and putzing on Regex101.com, traditional regex syntax is still a frustrating time sink that's hard to get correct without more trial-and-error than feels intrinsically necessary. The syntax provides zero opportunity to discover there's a more effective way to perform a task. I have trouble identifying a compelling value proposition for traditional syntax besides familiarity and natural serializability, and the fact that it gets the job done at all. I don't believe traditional regex syntax is the optimal way to accomplish text pattern matching tasks in the workplace, and I'm open to other tooling that makes it success simpler and more reliable. People misuse regexes all the time (examples like the one you linked are almost tropes at this point), but I don't think that's compelling justification on its own for preserving the status quo. [0] https://www.cs.princeton.edu/courses/archive/spr09/cos333/beautiful.html https://www.cs.princeton.edu/courses/archive/spr09/cos333/be...
- btilly 6y ago
  My only complaint about the regex syntax is that it does not allow you to separate things out with whitespace, or add comments about what the chunked units. The x modifier fixes both. What you traditionally see with a complex RE for a complex pattern is the same as what you traditionally see with someone writing complex SQL statements on a single line. Stop trying to treat it like a black box, and treat it as a programming language in its own right. Use whitespace, indentation, and comments (when necessary) to communicate intent as well as just to make it do its job. Other than that, regular expressions say what they mean and mean what they say very concisely directly. Particularly the PCRE variants of the language. I consider that conciseness and directness a virtue.