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

The true power of regular expressions (2012)

npopov.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: The true power of regular expressions (2012)

#51

Post by GuB-42 »

bazoom42 wrote: post #48
AussieWog93 wrote: post #12

It might just be a me problem, but I've always been wary of regexes. They're not too bad to write, but reading them back and understanding what's actually going on can get a bit hairy. Plus, all of the subtle differences between regex libraries seems like a bit of a footgun. Obviously they have their place, but I know a lot of the older guys seemed to love them way more than the young.

The readability should be compared to alternative ways to solve the same problem. Sure, regexes are not the most intuitive syntax, but it is compact and declarative. What is the alternative? Substring searches? Looping over characters? Hand-rolled recursive descent? Neither are obviously more readable, and intermingles the pattern with the mechanism.

Raku worked on this. As the Perl successor, they gave regex a lot of attention. The result still look like regex, but more powerful and with a more consistent syntax. They also made "/x" the default, which ignores unescaped whitespace and lets you put comments, so you can use spacing and indentation for readability. The general idea is that they are treated like actual programs rather than extended search strings.

But Raku, despite some good ideas and what looks like a nice community is not mainstream to say the least. So I don't expect "RCRE" to become a thing anytime soon.

Re: The true power of regular expressions (2012)

#52

Post by bryanrasmussen »

graemep wrote: post #47
bryanrasmussen wrote: post #43

Earlier quoted context omitted.

the might at beginning of the clause was also meant to take into account that people might have familiarity with English, as I could not be certain, but probably should have been expressed better.

I should really have worded my comment differently too. You need to filter out those Asian countries. Thinking about it, I think one thing that might stop that is that most people will start with English like languages first even if they are not English speaking and by the time they learn things like APL they will already be familiar with the more common style of languages.

probably, so harder to check, but if the "english-like" languages are still just gibberish to them that does things they might still be able to learn what to English speaking peoples looks like gibberish that does things easier.

Re: The true power of regular expressions (2012)

#53

Post by isqueiros »

jjice wrote: post #15
isqueiros wrote: post #13

Before the AI craze, I'd gotten quite good at writing regexes. Regexr was quite useful for decoding and composing them. I feel like they're going to become a lost art.

Totally agree. Selfishly, I was always the "regular expression" guy because they were a bit hobby space of mine (engine implementation and such), so seeing LLMs rip them is a bid of a bummer. Half the reason it's a bummer is because I've seen coworkers who don't know when a regular expression is very suboptimal performance wise, but the LLM has no problem spitting it out. Part of really understanding regular expressi…

Being the "regex guy" at work was also my thing. I was even in the process of making a regexr-like extension for vscode, but right about then everyone jumped ship to AI and making vscode extensions kinda felt like a last years thing.

They really are a "tool for the job" type thing, and I've seen the abuses people put them through. The fact that we struggled to know when to reach for it before worries me that this will be exacerbated now that we don't even read our own code.

Re: The true power of regular expressions (2012)

#54

Post by ghusbands »

jakobnissen wrote: post #22

This article misleads you by conflating regular expressions with specific implementations like PCRE, which also does non-regex string matches. Annoyingly, the article does a good job of explaining what a regex is and what the limitations of regex are relative to PCRE, so the author should understand that what they are talking about when they talk about NP-complete string matching is not regex, but PCRE-specific featu…

In common usage, "regex" means patterns accepted by regex engines like PCRE. Police the formal term "regular expression" if you like, but ordinary usage does not honour that distinction.

Also, it's not guaranteed that an engine implementing regular expressions will have O(n) time complexity - a backtracking engine can still have much worse performance on formal regular expressions.

Re: The true power of regular expressions (2012)

#55

Post by jibal »

jakobnissen wrote: post #50
skrebbel wrote: post #42

Earlier quoted context omitted.

You’re splitting hairs. The author is writing from the perspective of a PHP programmer (author is in fact a major PHP contributor), where the term “regex” has a single very clear definition, namely PHP’s PCRE-based implementation.

No, this is not splitting hairs. This is the author using the straight up wrong terminology. Regex can’t match HTML, and aren’t NP-complete. The fact that the author believes that “regex obviously means PCRE” is objectively wrong and misleading in the sense that all the things his article are about would have another conclusion if he actually talked about Regex. It’s like if there was a library called QuickSort which…

I already quoted from TFA in response to you, completely refuting your misrepresentation of it. To post this more than an hour after my comment while ignoring my comment is bad faith, especially this extraordinary falsehood and fake quote:

> the author believes that “regex obviously means PCRE”

The actual statement in TFA is

> (Reminder: When I say “regular expression” here I obviously mean it in the programmer sense, not the formal language theory sense.)

There are regex libraries that are more powerful than the regular expressions corresponding to Chomsky's regular languages. One can pedantically argue that these libraries are "using the straight up wrong terminology" by using such terms as "regex" or "regexp", but that ship has sailed, and the charge against TFA is bogus since it is very explicit about talking about those libraries and not the something from formal language theory, and it is very explicit about these regexes being able to parse CFGs and not just Chomsky's regular languages.

Finally, you're just plain wrong about "the straight up wrong terminology". The technical language theory terminology is "regular language", which has a formal definition and TFA is completely accurate in its discussion of that. But "regular expression" and "regex" has a broader and more casual meaning: https://en.wikipedia.org/wiki/Regular_expression#Patterns_fo...

I won't respond further.

Re: The true power of regular expressions (2012)

#56

Post by reichstein »

lbriner wrote: post #4

Something that seems obvious but not always implied by people's comments is that people are rarely trying to match an entire document with a regular expression so it doesn't really matter that "HTML is not a regular language". If I am trying to e.g. count div tags with a regex like " As soon as you also add character classes to ignore various parts of the document that you are not interested in like " ]*>" or whateve…

RegExps is the way to tokenize, so it's not surpassing you can look for individual tokens using them.

It's parsing that's hard , for example when it needs to match up braces, or start and end tags, even if either is easily matched by a RegExp.

And you still need to be careful if the source you're looking in has any way to escape text or have different meanings for the same text. In source code, you should recognize comments and strings (and RegExp literals) so you don't match inside those. In HTML, you should recognize CDATA sections, including script elements. If they contain `That's is, your 99.9% is probably too damn high.

Re: The true power of regular expressions (2012)

#57

Post by m463 »

AussieWog93 wrote: post #12

It might just be a me problem, but I've always been wary of regexes. They're not too bad to write, but reading them back and understanding what's actually going on can get a bit hairy. Plus, all of the subtle differences between regex libraries seems like a bit of a footgun. Obviously they have their place, but I know a lot of the older guys seemed to love them way more than the young.

> older guys seemed to love

I actually don't love regular expressions. But honestly I think it is implementations that make me dislike using them.

They are unclear in most programming languages.

Using regular expressions in just about every language I've used has had this programming language vs regular expression language ambiguity that makes them hard to recommend in production past minimal complexity.

I don't like to hand off code to my coworkers where it's unclear if a character is part of the quoting system, part of the programming language, part of the regular expression syntax, or a character to match literally.

for example, what if the program variable foo contained "abc" and you wanted that to be matched by a regular expression. each language has a different way of doing this and reviewing the code has a high chance of an error unless the person is really pedantically accurate regarding regular expressions. for example a regular expression in bash vs python is different because of quoting and escapes. And what if you wanted to use it in a search and replace?

What would help would be:

- a very very syntax aware editor that could color the regular expression, showing language characters vs regular expression control characters vs literals

- a tool for bidirectional conversion. Type in a pure regular expression and it will put out the expression in your programming language. or check an expression in the language and it will expand/annotate the regular expression.

(maybe there are things like this?)

Re: The true power of regular expressions (2012)

#58

Post by krackers »

jakobnissen wrote: post #22

This article misleads you by conflating regular expressions with specific implementations like PCRE, which also does non-regex string matches. Annoyingly, the article does a good job of explaining what a regex is and what the limitations of regex are relative to PCRE, so the author should understand that what they are talking about when they talk about NP-complete string matching is not regex, but PCRE-specific featu…

That's the whole point of the article, that regular expressions you use day-to-day are not strictly regular.

Re: The true power of regular expressions (2012)

#59

Post by ocodo »

jakobnissen wrote: post #22

This article misleads you by conflating regular expressions with specific implementations like PCRE, which also does non-regex string matches. Annoyingly, the article does a good job of explaining what a regex is and what the limitations of regex are relative to PCRE, so the author should understand that what they are talking about when they talk about NP-complete string matching is not regex, but PCRE-specific featu…

> "Regex absolutely can't match HTML"

Never abuse "absolutely", and match != parse.

Post reply on HN