11–20 of 75 posts
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.
Earlier quoted context omitted.
Probably parser is bunch of regex-es that noone understands. So they just converted to code to php without touching the expressions.
My suspicion is correct - code is full of things like: /\[\[([^\[\]] )\]\]|\{\{([^\{\}] )\}\}|-\{([^\{\}]*)\}-/
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.
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.
The other side to using PHP was having support in other host providers. Wikipedia is not the only installation of MediaWiki and there has been consideration in the past for those installing MediaWiki on shared hosts where you don't necessarily have root access to install things like node. Moving forward that's less of a concern because you can containerise MediaWiki (and the other services), but not even Wikimedia run that in production yet AFAIK.
However, even if they weren't budget constrained (which they aren't) unifying on a single language used by the majority of their devs isn't a bad idea, especially when the effort to port the entire stack to a new language would be unjustifiable.
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.
Why are web engineers snobs? Get the job done and move on.
Earlier quoted context omitted.
My suspicion is correct - code is full of things like: /\[\[([^\[\]] )\]\]|\{\{([^\{\}] )\}\}|-\{([^\{\}]*)\}-/
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.
Earlier quoted context omitted.
My suspicion is correct - code is full of things like: /\[\[([^\[\]] )\]\]|\{\{([^\{\}] )\}\}|-\{([^\{\}]*)\}-/
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.
For some reason, I did not manage to find it. Neither linked from this article, nor via the MediaWiki page:
https://www.mediawiki.org/wiki/Parsoid
Nor via the Phabricator page:
https://phabricator.wikimedia.org/project/profile/487/
What am I missing?
Earlier quoted context omitted.
> 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.
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_salarie...
A nice (unexpected) side effect is it became much easier for people extend the parser which their own syntax, leading to an explosion of plugins ( https://www.dokuwiki.org/plugins?plugintype=1#extension__tab... )
I'm no expert on parsing theory but I have the impression that applying standard approaches to parsing source code; building syntax trees, attempting to express it with context free grammar etc. is the wrong approach for parsing wiki markup because it's context-sensitive. There's some discussion of the problem here https://www.mediawiki.org/wiki/Markup_spec#Feasibility_study
Another challenge for wiki markup, from a usability perspective, if a user get's part of the syntax of a page "wrong", you need to show them the end result so they can fix the problem, rather than have the entire page "fail" with a syntax error.
From looking at many wiki parsers before re-writing the Dokuwiki parser, what _tends_ to be the case, when people try to apply context-free grammars or build syntax trees is they reach 80% then stumble at the remain 20% of edge cases of how wiki markup is actually used in the wild.
Instead of building an object graph, the Dokuwiki parser produces a simple flat array representing the source page ( https://www.dokuwiki.org/devel:parser#token_conversion ) which I'd argue makes is simpler write code for rendering output (hence lots of plugins) as well as being more robust at handling "bad" wiki markup it might encounter in the wild - less chance of some kind of infinite recursion or similar.
Ultimately it's similar discussion to the SAX vs. DOM discussions people used to have around XML parsing ( https://stackoverflow.com/questions/6828703/what-is-the-diff... ). From a glance at the Parsiod source they seem to be taking a DOM-like approach - I wish them luck with that - my experience was this will probably lead to a great deal more complexity, especially when it comes to edge cases.