Live data from Hacker News

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

cargocultcode.com

91–100 of 136 posts

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

#91

Earlier quoted context omitted.

Consider alternatively that this is a tiny piece in the much broader puzzle of what they are trying to accomplish, that they are aware both of their own beginner status but also that, in this case, good enough will be good enough, or that they don't have the time or inclination to switch to a real parser and that's why they didn't ask about it. Or maybe even that the goal here is to specifically learn to use regex to…

These objections may seem relevant to your personal experience, but they don't pertain to the case at hand, for which ample context is available. Dealing with responses from people who've rushed to write something without bothering to properly consider the problem is, of course, internet 101, but such answers generally take the short road to content oblivion. For those answers of any quality, however, note this: if p…

I also both ask and respond to questions. Mostly respond. For free. On my own time. People who answer on SO are not a unique special breed in the sense that they are willing to help others with their problems. I have read your reading of the thread, gone through it myself with that in mind, and disagree wholeheartedly that you have meaningfully extrapolated the context you claim.

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

#92

> The question is about finding opening tags in XHTML using a regular expression Bzzzt, wrong, sorry! The question is about finding open tags in the presence of XHTML self-closing tags. That difference alone places these interpretations gulfs apart. But there’s more: it does not specify that the input document is even XHTML, only that XHTML-style self-closing elements may be present. In fact the original question was…

What if we looked at the XHTML parsers trusted by the people who mindlessly dismiss the utility of regular expressions and found they were constructed using a lexer that relied on regular expressions.

[deleted]

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

#93

Earlier quoted context omitted.

> disengages any sense of purpose and practical utility and instead treats it like a badly worded test question. Who are you to know the purpose and utility better than the person who asked the question ?

Oh, are they here? It’d be fascinating to hear from them. Alternatively, perhap, that hostile tone is suggesting I’m personally unqualified to interpret loosely framed questions? I suppose, since I’ve only been doing it for a few decades, I’m definitely a novice by any standard, and my tendency to observe and follow up on anomalous, incomplete, subtly conflicting, or otherwise inexplicable requirements by investigati…

> 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.

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

#94

Earlier quoted context omitted.

These objections may seem relevant to your personal experience, but they don't pertain to the case at hand, for which ample context is available. Dealing with responses from people who've rushed to write something without bothering to properly consider the problem is, of course, internet 101, but such answers generally take the short road to content oblivion. For those answers of any quality, however, note this: if p…

I also both ask and respond to questions. Mostly respond. For free. On my own time. People who answer on SO are not a unique special breed in the sense that they are willing to help others with their problems. I have read your reading of the thread, gone through it myself with that in mind, and disagree wholeheartedly that you have meaningfully extrapolated the context you claim.

That much is quite evident.

Perhaps we'll never know if Jeff's XML RSS feed was conforming or not, but I like to think they got there.

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

#95

I love seeing the weirdo CDATA thingy in there! CDATA ftw! E.g., you've got this enormous spec for SVG which includes CSS, but that CSS has syntax inside a style tag which could break XHTML parsers. Amateurs out there are probably thinking, "Well, why not just compromise in the spec and tell implementers to do the same thing that HTML does to parse style tags?" Well, professionals know that cannot work for myriad rea…

>My holy grail-- how do I use DOM methods to create a CDATA element to shove my style into? If I could know this then I can jump my Dodge Charger back and forth into XHTML without ever getting caught. Does this help? https://developer.mozilla.org/en-US/docs/Web/API/Document/cr...

Ah, thanks!

In hindsight I probably could have guessed at "document.create" and then just read the autocomplete suggestions in devTools. :)

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

#96

> The question is about finding opening tags in XHTML using a regular expression Bzzzt, wrong, sorry! The question is about finding open tags in the presence of XHTML self-closing tags. That difference alone places these interpretations gulfs apart. But there’s more: it does not specify that the input document is even XHTML, only that XHTML-style self-closing elements may be present. In fact the original question was…

The problem is the answers saying "this is not possible".

The OP asks a perfectly reasonable question. The answers assume the OP actually meant to ask a different question, and they they ridicule the OP for this imagined question.

The question they imagine the OP asks was: "How do I parse an arbitrary HTML document into an element-tree using only a single regular expression and not using any auxiliary data structures, not even the call stack?"

Yes, this is indeed not possible, given the limitations of vanilla regular expressions.

But that was not the question asked.

Of course "use a parser" is perfectly sound advice (if a parser exists which can solve the OP's problem). But saying what the OP is attempting to do (tokenize xhtml) is impossible is absurd, since then it would also be impossible to write a parser!

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

#97

> The question is about finding opening tags in XHTML using a regular expression Bzzzt, wrong, sorry! The question is about finding open tags in the presence of XHTML self-closing tags. That difference alone places these interpretations gulfs apart. But there’s more: it does not specify that the input document is even XHTML, only that XHTML-style self-closing elements may be present. In fact the original question was…

> For this task, the suggestion of "use a parser" is indeed sound advice. Perhaps technically, but it's also useless advice because a parser does not exist for their particular flavor of malformed XHTML. XHTML parsers parse XHTML, which you yourself have said it wasn't: > they were trying to fix a malformed document So in the absence of a reference to a particular malformed-XHTML-recovering parser (which may or may n…

> "use a parser" amounts to "write a entire parser yourself, then use it"

"Use a parser" is a common answer, besides being the accepted one, and with good reason: it'll work. The world is not short of HTML parsers (although, who knows, perhaps PHP may have been short of very good parsers back in 2009). Whether they use regular expressions for tokenizing is an internal detail.

Serializing XML from the resulting memory structure, DOM or otherwise, closes the loop, and this remains a conventional and commonplace means to normalize some incoming HTML-like mush into something that can be spliced/interpolated into XML and a strict receiver will probably accept it.

> Pot, kettle.

Oh look, personal abuse! Good-day to you, too.

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

#98

> The question is about finding opening tags in XHTML using a regular expression Bzzzt, wrong, sorry! The question is about finding open tags in the presence of XHTML self-closing tags. That difference alone places these interpretations gulfs apart. But there’s more: it does not specify that the input document is even XHTML, only that XHTML-style self-closing elements may be present. In fact the original question was…

What if we looked at the XHTML parsers trusted by the people who mindlessly dismiss the utility of regular expressions and found they were constructed using a lexer that relied on regular expressions.

Well, since I've learned at least four assembly languages, and wrote my first toy lexer at least 25 years ago, probably in Standard ML, by this standard I seem qualified to comment.

It doesn't matter what the parser looks like under the bonnet. What matters is the utility it provides.

One might otherwise similarly offer the advice to mine your own copper and grow your own silicon, these being equally essential activities for anyone seeking the ultimate in mechanical sympathy.

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

#99
post #96

> The question is about finding opening tags in XHTML using a regular expression Bzzzt, wrong, sorry! The question is about finding open tags in the presence of XHTML self-closing tags. That difference alone places these interpretations gulfs apart. But there’s more: it does not specify that the input document is even XHTML, only that XHTML-style self-closing elements may be present. In fact the original question was…

The problem is the answers saying "this is not possible". The OP asks a perfectly reasonable question. The answers assume the OP actually meant to ask a different question, and they they ridicule the OP for this imagined question. The question they imagine the OP asks was: "How do I parse an arbitrary HTML document into an element-tree using only a single regular expression and not using any auxiliary data structures…

They're trying to tokenize HTML into two arrays, one being an array of opening tags and one of closing tags, with the hope being to pairwise compare and reconcile the elements of these arrays.

The necessary clarification appears further down the page.

As for whether it's a reasonable question; as written I beg to differ, it's the opposite, since it does not convey their problem except by a very careful and nuanced reading. The proper response of the S.O. community should've been to aid the OP in clarifying their intentions and amending the question accordingly to bring focus onto their actual problem.

That is not what happened. Instead they are indeed on the receiving end of some ridicule, which is shameful, but the advice of "use a parser" would still likely have been a top answer in some fashion had the OP's scattered ancillary questions and clarifications been incorporated.

Sadly, only one correspondent of many seems to have seen fit to ask.

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

#100
post #89

Earlier quoted context omitted.

> This conversation would be a lot clearer with a distinction between "regexes" and "regular languages". Very much so. > In this post, the example given IS a regex, but it IS NOT a regular language: ` # comment` The nongreedy match of .*? isn't a mathematical construct; it implies a backtracking engine. Actually, that's [edit: "it IS NOT a regular language"] wrong, at least in principle. If you're limiting it to only…

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?

Post reply on HN