Skip to content

Comment on The Parser that Cracked the MediaWiki Code

Comments

This is a breakthrough and a welcome one. From a end user point of view, it has a couple major implications.

First, I believe this reveals the complexity of the parser, which implies a complex syntax, which implies a complex user interface as felt by end users. A more complex the user interface may make it harder it is to attract new editors, although it's unclear (to me) if that is a fact.

Second, having an AST representation is awesome. It makes it possible to even think about building a path towards WYSIWYG or some other form of rich text editing. It was not really possible to build a WYSIWYG editor around the wiki syntax.

If you have an AST, you can also store the page as the AST since you can regenerate the wiki syntax from the AST for people who need text-based editors.

A more complex the user interface may make it harder it is to attract new editors

There may be friction against gaining new editors from the user interface of the MediaWiki software, but I think the greatest barrier to participation by new editors is the hostile, drama-filled environment on many controversial topics on Wikipedia. My evidence for that is the decline in "unsustainable fashion"

http://strategy.wikimedia.org/wiki/Story_of_Wikimedia_Editor...

in the number of Wikipedian administrators, who presumably for the most part are people who know how to use Wikimedia software. Too many of best contributors (people who look up facts in reliable sources and edit articles for better readability) on Wikipedia feel attacked and that their time is wasted. I know a lot of dedicated hobbyists who quietly work on their hobby-related subjects putting together great articles, but on any subject that is controversial, and for which looking up reliable sources takes some effort, Wikipedia is becoming a war zone and is not improving in quality.

http://strategy.wikimedia.org/wiki/Strategic_Plan/Movement_P...

http://strategy.wikimedia.org/wiki/Strategic_Plan/Movement_P...

First, I believe this reveals the complexity of the parser, which implies a complex syntax, which implies a complex user interface as felt by end users.

That's the case to some extent, but the opposite is also the case to some extent. Some of the difficulty of parsing is because "ease of human use" has been a much higher priority than "ease of parsing" when discussing syntax, which leads to some constructs that aren't easy to parse with typical CFG-type parsing approaches. It's also designed to be very lenient to ordering and common errors, much like a modern non-strict HTML parser, which makes hand-writing the syntax more friendly and forgiving, but with a tradeoff that the parser has to be more complex, because it doesn't have the luxury of just returning a parse error.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.