Live data from Hacker News

Solving the regex of madness, and snarky answers on StackOverflow (2019)

cargocultcode.com

111–120 of 136 posts

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#111

Earlier quoted context omitted.

You're not the first to take that line, so I'll refer you to my previous observations: https://news.ycombinator.com/item?id=27097403 There's no wild assumption going on here. I just bothered to keep reading, very carefully, everything the original author actually wrote. Then, please, further reflect that Stack Overflow is not Codewars; it is a forum for practical, focused, and relevant problem-solving advice, and at…

> There's no wild assumption going on here. I just bothered to keep reading, very carefully, everything the original author actually wrote. That doesn't excuse it. You're still inferring stuff that wasn't asked in the actual question. What happens when someone else comes along who really does want to use a regex? They now have a question without the correct answer and they can't even ask the question themselves becau…

[deleted]

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#112
post #89

Earlier quoted context omitted.

Does your regex assumes that "-->" must be prefixed by a space? This is not the case in XML. (Also the string "--" must not occur inside a comment, so the last clause is not necessary.)

> Does your regex assumes that "-->" must be prefixed by a space? Yep, because the quoted regex assumed the same thing, and I didn't see a point in editorializing more than necessary. > Also the string "--" must not occur inside a comment, so the last clause is not necessary. "Must not" seems unreliable in webpage parsing. What page does your XHTML parser produce when fed text of the form ` `, for example?

Handling invalid syntax is another can of worms! It would make all parts of the tokenizer much more complex, not just comments.

In the case of XHTML, a parser is supposed to reject any document which is not well formed. HTML parsers typically try to "gracefully recover" from all syntax errors, but this is a crazy complex algorithm.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#113
post #54

Earlier quoted context omitted.

So what do you use instead of regular expressions for such tasks?

That kind of depends on the language I am using, as well as dealing with performance requirements vs readability tradeoffs.

What I like about regexes is they are typically both the most readable and the best performing solution to the kind of problems they are suited for.

Just don't use them for validating email addresses or determining if a number is a prime.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#114

The author seems to be missing the point, in my opinion. While it is certainly true that often one can solve simple, seemingly innocent sub-problems within more general languages, the transitions from "I see I can solve this simple program with regex'es!" to "Then I can probably solve this other, almost identical problem as well!" and have the problem explode right into your face are subtle (almost imperceivable to a…

The article goes as far as to say that a parser is not the right tool. > Not only can the task be solved with a regular expression - regular expressions are basically the only practical way to solve the problem. Which is why none of the clever answers actually suggest another way to solve the problem. So no, the author is not missing the point at all.

The point is that a parser could very well use regexes under the hood to perform the tokenization. Because it is the right tool for the job. A language without regex-support might use something like lex to compile a lexer. Of course you can write a character-by-character lexer by hand, but this is just equivalent to what a regex would generate.

So saying "this is not possible, use a parser instead" is completely misunderstanding the relationship between lexing and parsing. I wonder how these people think a parser works?

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#115

Earlier quoted context omitted.

The article goes as far as to say that a parser is not the right tool. > Not only can the task be solved with a regular expression - regular expressions are basically the only practical way to solve the problem. Which is why none of the clever answers actually suggest another way to solve the problem. So no, the author is not missing the point at all.

I mean that bit is clearly wrong. An XML/HTML parser is a perfectly practical way to solve the problem. However I completely agree that they didn't miss the point. A regex to do this might be fine for hacky things that you don't need to be robust (e.g. for searching for stuff, measuring stats, one-off scripts etc.).

Regular expressions can be as robust as you need them to be, just like any other kind of code. They are a DSL to create lexers, and they are exactly as robust (or hacky) as if you wrote the same lexer by hand.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#116

Earlier quoted context omitted.

You're not the first to take that line, so I'll refer you to my previous observations: https://news.ycombinator.com/item?id=27097403 There's no wild assumption going on here. I just bothered to keep reading, very carefully, everything the original author actually wrote. Then, please, further reflect that Stack Overflow is not Codewars; it is a forum for practical, focused, and relevant problem-solving advice, and at…

> There's no wild assumption going on here. I just bothered to keep reading, very carefully, everything the original author actually wrote. That doesn't excuse it. You're still inferring stuff that wasn't asked in the actual question. What happens when someone else comes along who really does want to use a regex? They now have a question without the correct answer and they can't even ask the question themselves becau…

Well, that is snide, petty, personal, and wrong.

The strangest part of this whole discussion has been the remarkable number of accounts making head-first personal character attacks. And as with that comment further back, the personal invective comes coupled to some strange language, like “StackOverflow people” - what are they, even? It sure ain’t a tribe I’d identify with. Does anyone with a login qualify? Where’s all that anger even coming from?

Setting that aside, I don’t believe that reading the OP’s clarifying remarks and follow up questions is “inference”. Not that there’s anything wrong with inferring things, but it’s the opposite, it is going to the primary source, and I don’t need to excuse it. Frankly, I think people who skimp on their research, and fail to engage with the source to refine the matter, are selling the question short.

This question was undoubtedly mishandled in part because it became memorialised for a famous answer. The failure to provide the OP with adequate feedback, or to edit it unilaterally to incorporate the OPs essential clarifications (without which its a “wtf” class question) was, and remains, a dereliction of moderator duty. Because it makes much more sense and is much more likely to be useful to your hypothetical later visitor once focused.

What the world did not need was yet another page of half-baked tokenisation routines.

Finally, I have never closed a dupe in all my puff, and I’m thoroughly unimpressed by those that do.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#117
post #42

Earlier quoted context omitted.

So if using regular expressions is "bad practice", how should one write the tokenizer or lexer stage of a parser?

Who said regular expressions are bad practice? Regexes are great but they can get abused easily. Looking more carefully at the SO question, I am inclined to ask "why?" at least a couple of times because I suspect the answer to the deeper problem the SO OP needs to solve can be worked out with a DOM parser. If not, then definitely a SAX parser could solve that specific problem and it would be more robust than handcraf…

As far as I can tell, a SAX parser does not expose the distinction between an opening tag and a self-closing tag. The tag `` would just emit a startElement event followed by an endElement, exactly the same as ``.

Which means it can't solve the specific problem the OP describes.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#118

Earlier quoted context omitted.

> There's no wild assumption going on here. I just bothered to keep reading, very carefully, everything the original author actually wrote. That doesn't excuse it. You're still inferring stuff that wasn't asked in the actual question. What happens when someone else comes along who really does want to use a regex? They now have a question without the correct answer and they can't even ask the question themselves becau…

Well, that is snide, petty, personal, and wrong. The strangest part of this whole discussion has been the remarkable number of accounts making head-first personal character attacks. And as with that comment further back, the personal invective comes coupled to some strange language, like “StackOverflow people” - what are they, even? It sure ain’t a tribe I’d identify with. Does anyone with a login qualify? Where’s al…

> “StackOverflow people” - what are they, even?

StackOverflow has a real problem with attracting strict rule followers who love over-moderating. I expect Wikipedia suffers from a similar issue but it's not such an interactive site so most people aren't exposed to it.

> Where’s all that anger even coming from?

StackOverflow can be an extremely frustrating experience due to people who probably think they are helping casually closing questions.

> Finally, I have never closed a dupe in all my puff, and I’m thoroughly unimpressed by those that do.

Good! I wish there were more people like you! I'm still waiting for the day when somebody starts a friendly competitor to StackOverflow that doesn't support closing questions, gives authors actual control over what they write (can you imagine if other people could edit your comments here?) and does away with mods. One day...

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#119
post #115

Earlier quoted context omitted.

I mean that bit is clearly wrong. An XML/HTML parser is a perfectly practical way to solve the problem. However I completely agree that they didn't miss the point. A regex to do this might be fine for hacky things that you don't need to be robust (e.g. for searching for stuff, measuring stats, one-off scripts etc.).

Regular expressions can be as robust as you need them to be, just like any other kind of code. They are a DSL to create lexers, and they are exactly as robust (or hacky) as if you wrote the same lexer by hand.

C code can be as robust as you need it to be. So why bother with formal verification, safe C coding standards, Rust, etc?

The answer is that it can be robust, but the effort required to do that is so large that in practice it usually isn't.

Re: Solving the regex of madness, and snarky answers on StackOverflow (2019)

#120

Earlier quoted context omitted.

> Sometimes, we just have to bother reading what's in front of us. You are making an absolutely great example of that. I was absolutely not talking about the original SO post, but about the generally extremely entitled answers which assume the existence of a very specific X to the Y of a post.

If I understand correctly, you're suggesting "Who are you" wasn't directed at me personally, "the person" wasn't referring to the OP but all possible authors, and "the question" wasn't referring to, well, the original SO question at hand, but the class of all possible questions. If so, then I see, I think: perhaps it was more intended as "Who is anyone to know the purpose and utility (of a question) better than the p…

> If I understand correctly, you're suggesting "Who are you" wasn't directed at me personally, "the person" wasn't referring to the OP but all possible authors, and "the question" wasn't referring to, well, the original SO question at hand, but the class of all possible questions.

yes, exactly ? but maybe it is less common to speak in such a general way in english than in my mother tongue

Post reply on HN