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

Parsoid in PHP, or There and Back Again

phabricator.wikimedia.org

Post reply on HN
Print view View original

31–40 of 75 posts

Re: Parsoid in PHP, or There and Back Again

#31

Post by TicklishTiger »

luckylion wrote: post #28
TicklishTiger wrote: post #26

Anybody else feeling that strict typing and long var names are not worth all the visual overload? Example: https://github.com/wikimedia/parsoid/blob/master/src/Parsoid... This is how I would write the function definition: function html2wikitext($config, $html, $options = [], $data = null) This how Wikimedia did it: public function html2wikitext( PageConfig $pageConfig, string $html, array $options = [], ?SelserData $…

I like long names because autocomplete usually means typing speed doesn't matter and they are more verbose, so less thinking when I come back to the code next week. Same goes for strong typing, it makes you think when you write it so you (or somebody else) have to think less when you read it, and obviously it keeps you from making mistakes, helps the IDE make useful suggestions etc.

Me: Many people like X. Anybody here who likes Y?

You: I like X!

Re: Parsoid in PHP, or There and Back Again

#32

Post by SXX »

spiderfarmer wrote: post #16
SXX wrote: post #12

Earlier quoted context omitted.

I never understood why people find regex so intimidating. Obviously you probably didn't look to find the worst of all, but one you posted is very straightforward.

I never understood why people who understand regex don’t understand people who don’t understand regex. Obviously you are not the worst of all, but it’s not that hard to imagine how a regex looks to someone who doesn’t know regex, is it?

Yeah, I get that regular expressions might look complex and tangled like brainfuck looks for me since I never tried to learn it. Yet I just see comments on how regular expressions are hard to understand from all kind of IT people who solving hundred times more complex puzzles every day. I guess it's just reputation that stick to certain technology and really have nothing to do with actual complexity.

Re: Parsoid in PHP, or There and Back Again

#33

Post by luckylion »

spiderfarmer wrote: post #16
SXX wrote: post #12

Earlier quoted context omitted.

I never understood why people find regex so intimidating. Obviously you probably didn't look to find the worst of all, but one you posted is very straightforward.

I never understood why people who understand regex don’t understand people who don’t understand regex. Obviously you are not the worst of all, but it’s not that hard to imagine how a regex looks to someone who doesn’t know regex, is it?

I couldn't agree more. I know regex fairly well and parsing regex is still annoying and takes a lot more concentration than just reading normal code.

Plus there are so many cases where people build insane regex where they are just the wrong tool for the job, e.g. parsing/extracting or manipulating HTML. It always starts out with "I just need the src from that , what could go wrong" and ends in despair, because you never just need that src and you never only deal with perfect html and you'd be done already if you had just used some dom parser.

Re: Parsoid in PHP, or There and Back Again

#34

Post by mhd »

> We will (re)examine some of the reasons behind this architectural choice in a future blog post, but the loose coupling of Parsoid and the MediaWiki core allowed rapid iteration in what was originally a highly experimental effort to support visual editing.

I'd really like to read that. The decision to have this parser as a completely separate component is the main reason why a lot of local MediaWiki installations completely avoided having a visual editor -- which in turn probably created lots of missing hours and/or missing documentation because WikiCreole ain't exactly a thing of beauty or something that's used in other places (as opposed to Markdown, which is an ugly beast, too, but at least the ugly beast you know).

You need a heavy JS frontend for a visual editor anyway, so why not do it client-side?

Having to deploy a separate component, probably in an environment that's not used at all is pretty much the worst choice possible. Yes, I'm aware, you readers here probably do all kinds of hip docker/keights setups where yet another node microservice ain't nothing special (and should've been rewritten in Rust, of course), but a wiki is something on a different level of ubiquity.

Re: Parsoid in PHP, or There and Back Again

#35

Post by luckylion »

TicklishTiger wrote: post #31
luckylion wrote: post #28

Earlier quoted context omitted.

I like long names because autocomplete usually means typing speed doesn't matter and they are more verbose, so less thinking when I come back to the code next week. Same goes for strong typing, it makes you think when you write it so you (or somebody else) have to think less when you read it, and obviously it keeps you from making mistakes, helps the IDE make useful suggestions etc.

Me: Many people like X. Anybody here who likes Y? You: I like X!

Sorry, I'm bad at reading, I understood your question as mostly "why do people like X?"

Re: Parsoid in PHP, or There and Back Again

#36

Post by ablomen »

TicklishTiger wrote: post #26

Anybody else feeling that strict typing and long var names are not worth all the visual overload? Example: https://github.com/wikimedia/parsoid/blob/master/src/Parsoid... This is how I would write the function definition: function html2wikitext($config, $html, $options = [], $data = null) This how Wikimedia did it: public function html2wikitext( PageConfig $pageConfig, string $html, array $options = [], ?SelserData $…

I did not like/see the real benefit of strict typing until actually using Typescript. Now for me the more verbose code and extra typing is vastly outweighed by knowing what arguments the function actually wants, especially when using 3rd party libraries. The time saved by real-time type checking in my editor compared to edit->run->crash->edit is almost unbelievable and the amount of errors in code I ported over that we did not come across in production is also huge. So no, I think the visual overload is definitely worth it.

Re: Parsoid in PHP, or There and Back Again

#37

Post by tjpnz »

>Parsoid/JS had very few unit tests focused on specific subsections of code. With only integration tests we would find it difficult to test anything but a complete and finished port.

I found this a little frightening given Parsoid/JS is handling user input.

Re: Parsoid in PHP, or There and Back Again

#38

Post by hatch_q »

SXX wrote: post #32
spiderfarmer wrote: post #16

Earlier quoted context omitted.

I never understood why people who understand regex don’t understand people who don’t understand regex. Obviously you are not the worst of all, but it’s not that hard to imagine how a regex looks to someone who doesn’t know regex, is it?

Yeah, I get that regular expressions might look complex and tangled like brainfuck looks for me since I never tried to learn it. Yet I just see comments on how regular expressions are hard to understand from all kind of IT people who solving hundred times more complex puzzles every day. I guess it's just reputation that stick to certain technology and really have nothing to do with actual complexity.

Experience i guess. I've spent hundreds of hours on debugging and fixing regexes that other people wrote - usually just to find there's a quirk in certain regex parser implementation.

Regexes are easy to understand if you write them, but reading them can take lots of time.

Re: Parsoid in PHP, or There and Back Again

#39

Post by darkwater »

TicklishTiger wrote: post #31
luckylion wrote: post #28

Earlier quoted context omitted.

I like long names because autocomplete usually means typing speed doesn't matter and they are more verbose, so less thinking when I come back to the code next week. Same goes for strong typing, it makes you think when you write it so you (or somebody else) have to think less when you read it, and obviously it keeps you from making mistakes, helps the IDE make useful suggestions etc.

Me: Many people like X. Anybody here who likes Y? You: I like X!

But you also say

> I see this "strictness over readability" on the rise in many places and I think it is a net negative.

which makes your tastes a bit more... absolute to say something. So it makes sense to me that people reply to your negative view with counter arguments.

Re: Parsoid in PHP, or There and Back Again

#40

Post by TeMPOraL »

SXX wrote: post #30
TeMPOraL wrote: post #21

Earlier quoted context omitted.

You jest, but that regex looks machine-generated. My Emacs is full of these in places used for syntax coloring, but I know these are optimized . There's an elisp function, regex-opt, into which you can throw a bunch of strings, and you get out a regex like above.

To be honest I was serious. Personally I believe that regular expressions is one of few tools that super useful even for people outside of IT because everyone have to extract of format some text or table data from time to time. You can even learn them just by playing game: https://regexcrossword.com/

The example quoted required some mental work to unparse, so I assumed you're joking.

But in general, I agree with you. Regular expressions aren't hard, and there's no excuse for not learning to read and use them.

Post reply on HN