On Tue, Sep 2, 2014 at 12:41 PM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
<This reply still isn't anything official, but does represent my own views as a developer (both volunteer and staff)>
Is there an actual problem with Scribunto that drove you to writing this lisp interpreter, or is it just that you don't like the fact that Scribunto forces you to separate Lua code from templates?
I consider this separation a good thing, as even if it is more work for the developer it makes things much easier for everyone else to understand later.
I have a specific reason for disapproving of the separation. Wiki markup was incredibly successful; that's why there /is/ a wikimedian movement. It's not all been made to happen by flower-power. The two key characteristics of wiki markup that, I believe, made it work so spectacularly well are (1) It's very easy to use. It can get to be something of an awful mess at the high end, when the subtly design-flawed template mechanism gets forcibly overused, but when you get down to it, wiki markup is easy --- especially when one takes into account the second key characteristic, (2) it naturally promotes incremental learning. A while back I had a really simple edit to make to a Wikipedia page, and thought I'd try out VisualEditor on it. Eventually I gave up and did it by editing the markup. What I'd wanted to do was to add another simple item to an itemized list. The point here isn't how to do that, directly; the point is, even if I'd been a newbie with no clue how to do that, I'd have had no problem whatsoever with doing it in the absence of VE, because when I edited the markup, I'd have had examples right there in front of me of exactly how to do it. And as I think back, I learned just about everything I know about wiki markup that way. My first few edits were correcting typos, and I saw how wikilinks were done, and so on. At each stage, I'd seen examples of things just a little more advanced than what I'd done myself, because it was all right there in the markup I'd been editing, and when I wanted to do a little more than I had I'd go see how others had done similar things. But Lua is a completely different sort of language, requiring a major step --- and major steps don't belong to the wiki development pattern. Wikis work using volunteer labor because of their incremental approach, both to editing and to /learning/ to edit (and to learning how to participate in the community, but that's another subject).
And, Lua is a high-overhead language. You can't just write super-simple expressions and have them work, and build other stuff up. Lisp, on the other hand, has extremely simple, unambiguous, low-overhead syntax. (Even simple template calls have more syntactic overhead than lisp function calls.)
Of course, my primary goal was interactive pages, for building wizards, and it was clear to me that Lua wasn't going to help me with those anyway.
I do agree that templates are rather broken, although frankly the
Foundation could --- with some deep insight --- have done things that would have improved them. The current plethora of magic words is a mess, partly because the template call-syntax is heavy and pure template/magic-word usage keeps sending things back to typeless text;
The Foundation *did* do something. It's called Scribunto.
Scribunto which I maintain is, for the reasons I've attempted to articulate, philosophically incompatible with the factors that make wikis successful. I might add, that I believe these things are /still/ an essential ingredient for making wikis successful, and each time the wiki experience is changed in a way that moves away from those factors, the long-term success of the movement is degraded.
Scribunto isn't an improvement to templates; it's trying to half-replace them with something else. My understanding of "improve templates" would exclude a half-replacement (or full replacement), even if the half/full-replacement were to "improve *on* templates". (Actually, I do think Scribunto is an improvement on the status quo ante, but there are other routes that would have also been improvements on that, that I believe would have been better for the long-term health of the wikimedian movement.)