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

41–50 of 75 posts

Re: Parsoid in PHP, or There and Back Again

#41

Post by hnzix »

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 $…

Strict typing has an overhead, but the payoff is apparent when working with a large dev team of variable skill levels. People can make a mess in any language but it's easier to decode with strict typing.

For lone wolf coding or rapid prototyping the equation is different.

Re: Parsoid in PHP, or There and Back Again

#42

Post by b3kart »

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 $…

Reformat your example slightly, and suddenly it's not so bad:

  public function html2wikitext(
    PageConfig  $pageConfig, 
    string      $html, 
    array       $options = [],
    ?SelserData $selserData = null
  ): string
I am sure an IDE could do that for you.

That being said, I think the Python way of formatting type annotations ("variable : type") is more readable than C-style "type variable = ...", especially when the annotation is optional.

Re: Parsoid in PHP, or There and Back Again

#43

Post by nicoburns »

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'll bet the typed version is a lot more readable with syntax highlighting.

Re: Parsoid in PHP, or There and Back Again

#44

Post by b3kart »

hnzix wrote: post #41
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 $…

Strict typing has an overhead, but the payoff is apparent when working with a large dev team of variable skill levels. People can make a mess in any language but it's easier to decode with strict typing. For lone wolf coding or rapid prototyping the equation is different.

I've never worked in a large team that has used a dynamically typed language. To me it sounds like a nightmare, especially given that I know how little time is typically left for documentation. I see that it could work if you enforce type annotations. But then you might as well use a strongly typed language.

Re: Parsoid in PHP, or There and Back Again

#45

Post by simion314 »

LessDmesg wrote: post #10

Almighty Zeus, please smite PHP and all code written in it from all the records of humanity. This language is too disgusting and wrong to be used by anyone, ever.

I was refactoring yesterday some JS code, bad JS code it is worse then bad PHP code, so by your logic JS has to go too and probably many other languages.

Good code uses small functions that do a simple thing, then you combine those functions , it will look similar for most programming languages

Re: Parsoid in PHP, or There and Back Again

#46

Post by dingdingdang »

trynewideas wrote: post #5

Reintegrating the parser into Mediawiki's PHP core goes beyond performance. Many prominent MW features -- particularly the visual editor, translation functions, and mobile endpoints -- depend heavily on Parsoid/JS, which required running it as a Node.js microservice, something not all smaller (or especially shared-hosting wikis) could manage for quite some time. Bringing Parsoid closer to core makes it easier for non…

Performance gains of "Parsoid/PHP ... roughly twice as fast on most requests as the original version" are bit more than a casual bonus and into territory of pretty dang awesome in my book.

Re: Parsoid in PHP, or There and Back Again

#47

Post by Cthulhu_ »

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 $…

Your first function definition leans HEAVILY on implicit knowledge - what does $config mean? What does $html mean? What are valid properties of $config and $data?

This is fine in smaller codebases, 'your' code, and code that you can read to a point where you can extrapolate these variables from the implementation, but this simply does not scale beyond a certain code size - or more importantly, a certain amount of contributors.

It can be compensated with documentation (phpDoc), but that is just as verbose if not moreso than adding type information - although you should probably do both.

Type systems come into place where you are not expected anymore to fully comprehend the code. They are useful when you are just a consumer / user of this function and all you want to do is convert some html to wiki text without having to understand the internals of that particular function (and whatever else goes on beyond it). Types are documentation, prevent shooting yourself in the foot, reduce trial-and-error, and avoid the user having to read and comprehend hundreds - thousands of lines of code.

Re: Parsoid in PHP, or There and Back Again

#48

Post by lowercased »

shimst3r wrote: post #4
echelon wrote: post #2

I'm actually curious why PHP was chosen instead of Rust or Go given that the parsing team wasn't familiar with the language. I understand that MediaWiki is written in PHP, but it sounds like they were already comfortable with language heterogeny. They claim, > The two wikitext engines were different in terms of implementation language, fundamental architecture, and modeling of wikitext semantics (how they represented…

> Parsoid/PHP also brings us one step closer to integrating Parsoid and other MediaWiki wikitext-handling code into a single system, which will be easier to maintain and extend. I assume that Wikimedia works on a rather tight budget. Choosing (and unifying on) tech stacks with a larger supply in devs seems to be an economically reasonable choice.

and... migrating an entire codebase to something new because there's a subset of devs that jump between tech stacks and want 'newer' stuff isn't an economically reasonable choice.

server-side JS was a thing 10 years ago, but it didn't offer enough benefits to switch. same with python, java, ruby - all existed, but didn't offer enough benefits to switch then, and probably still don't now.

also, what would be a "larger supply"? C? Java? C#? JS? PHP has a huge supply of developers at all skill levels, which may make it just as easy (or easier) in finding the talent they need. And... hey - they wrote that initial parsoid in JS and... they've doubled the speed by converging on PHP.

Re: Parsoid in PHP, or There and Back Again

#49

Post by jedieaston »

TicklishTiger wrote: post #27
perlgeek wrote: post #25

Earlier quoted context omitted.

The GitHub repo is a mirror. It has links to more documentation on how the development process works.

I saw that. But why not have the code on Phabricator?

Here it is on Phabricator: https://phabricator.wikimedia.org/diffusion/GPAR/

Re: Parsoid in PHP, or There and Back Again

#50

Post by aurbano »

Cthulhu_ wrote: post #47
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 $…

Your first function definition leans HEAVILY on implicit knowledge - what does $config mean? What does $html mean? What are valid properties of $config and $data? This is fine in smaller codebases, 'your' code, and code that you can read to a point where you can extrapolate these variables from the implementation, but this simply does not scale beyond a certain code size - or more importantly, a certain amount of con…

This. Passing a variable named $config, or options, settings... etc, to a function with no type definition is the recipe for unmaintainability.
Post reply on HN