Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Regex Isn't Hard (2023)

timkellogg.me

Post reply on HN
Print view View original

21–30 of 109 posts

Re: Regex Isn't Hard (2023)

#21

Post by gwd »

So my brother doesn't code for a living, but has done a fair amount of personal coding, and also gotten into the habit of watching live-coding sessions on YouTube. Recently he's gotten involved in my project a bit, and so we've done some pair programming sessions, in part to get him up to speed on the codebase, in part to get him up to speed on more industrial-grade coding practices and workflows.

At some point we needed to do some parsing of some strings, and I suggested a simple regex. But apparently a bunch of the streamers he's been watching basically have this attitude that regexes stink, and you should use basically anything else. So we had a conversation, and compared the clarity of coding up the relatively simple regex I'd made, with how you'd have to do it procedurally; I think the regex was a clear winner.

Obviously regexes aren't the right tool for every job, and they can certainly be done poorly; but in the right place at the right time they're the simplest, most robust, easiest to understand solution to the problem.

Re: Regex Isn't Hard (2023)

#22

Post by goku12 »

If you take the regex subset that works uniformly across all regex engines (even for just perl-compatible engines), you would probably get nothing done. They all have some minor variations that make it impossible to write a regex for a particular engine without a reference sheet open nearby, even if you have years of experience writing them. And those 'shortcuts' like look-ahead and look-behind are often too useful to be neglected completely.

Crafting regexes is story of its own. The other commentor has described it. Just to summarize, regexes are fine for simple patterns. But their complexity explode as soon as you need to handle a lot of corner cases.

Re: Regex Isn't Hard (2023)

#23

Post by thomasmg »

For me, the main problem of the Regex syntax is the escaping rules: Many characters require escaping: \ { } ( ) [ ] | * + ? ^ $ . And the rules are different inside square brackets. I think it would be better if literal text is enclosed in quotes; that way, much less escaping is needed, but it would still be concise (and sometimes, more concise). I tried to formulate a proposal here: https://github.com/thomasmueller/bau-lang/blob/main/RegexV2....

Re: Regex Isn't Hard (2023)

#24

Post by criddell »

comrade1234 wrote: post #13
nickez wrote: post #3

Found an error immediately "Any lowercase character" doesn't match all Swedish lowercase characters.

lol really? Why not? Is that true for all encodings? Is it a bug or a feature? What about a simple character set like gsm-7 Swedish?

The Swedish alphabet includes characters outside of the a-z range.

Re: Regex Isn't Hard (2023)

#25

Post by lalaithion »

comrade1234 wrote: post #13
nickez wrote: post #3

Found an error immediately "Any lowercase character" doesn't match all Swedish lowercase characters.

lol really? Why not? Is that true for all encodings? Is it a bug or a feature? What about a simple character set like gsm-7 Swedish?

The author says “any lowercase character” but they mean “any character between the character ‘a’ and the character ‘z’”, which happens to correspond to the lower case letters in English but doesn’t include ü, õ, ø, etc.

Re: Regex Isn't Hard (2023)

#26

Post by lalaithion »

iugtmkbdfil834 wrote: post #11
nickez wrote: post #3

Found an error immediately "Any lowercase character" doesn't match all Swedish lowercase characters.

Ok. This sounds like an interesting detour. Can you elaborate on that one? I doubt I will ever use that knowledge, but it sounds like it is worth knowing anyway.

The author says “any lowercase character” but they mean “any character between the character ‘a’ and the character ‘z’”, which happens to correspond to the lower case letters in English but doesn’t include ü, õ, ø, etc.

Re: Regex Isn't Hard (2023)

#27

Post by ykonstant »

poisonborz wrote: post #5

This is truly one thing AI solved. Hard to write, easy to test. No one needs to learn this convoluted syntax in the future and we're all better for it.

I wonder if the problems people are pointing out with the examples (lowercase not being correct under various locales, IP address regex not being conformant etc) would be absent in code furnished by LLMs.

Re: Regex Isn't Hard (2023)

#28

Post by SnowingXIV »

TrackerFF wrote: post #10

Confession: Regex knowledge is one of those things I've let completely atrophy after integrating LLMs into my workflow. I guess if the day comes that AI/ML models suddenly disappear, or become completely unavailable to me, I'll have to get into the nitty gritty of Regex again...but until that time, it is a "solved problem" for my part.

Yeah, this is my heaviest use case too. Mostly because it generally does save me a bit of time and is easily verifiable with tools like rubular and then can tweak what is needed once 90% there.

Re: Regex Isn't Hard (2023)

#29

Post by hyperman1 »

This is both a demo for the beauty and power of regexes, and of their dangers:

* The use of backslash separatores quickly makes a mess, as they tend to need escaping wherever regexes are usefull.

* The uppercase/lowercase is only right if there are no accented characters, so USA. This is bad in western europe in files where they are rare: Your program works for a while, then an accent sneaks in and breaks things.

* The exact meaning of all the specials like \( vs ( .

* Ranges work in most regex dialects but not everywhere.

* A simple regex for an int with a specific range is nasty. If you want a full float, good luck.

Regexes are great as initial filter or quick hack, but you need more in full size programs.

I'd love to see a better regex syntax, too.

Re: Regex Isn't Hard (2023)

#30

Post by kelafoja »

gwd wrote: post #21

So my brother doesn't code for a living, but has done a fair amount of personal coding, and also gotten into the habit of watching live-coding sessions on YouTube. Recently he's gotten involved in my project a bit, and so we've done some pair programming sessions, in part to get him up to speed on the codebase, in part to get him up to speed on more industrial-grade coding practices and workflows. At some point we ne…

My problem is that regexes are write-only, unreadable once written (to me anyway). And sometimes they do more than you intended. You maybe tested on a few inputs and declared it fit for purpose, but there might be more inputs upon which it has unintended effects. I don't mind simple, straight-forward regexes. But when they become more complex, I tend to prefer to write out the procedural code, even if it is (much) longer in terms of lines. I find that generally I can read code better than regexes, and that code I write is more predictable than regexes I write.
Post reply on HN