Pardon my long reply; I actually meant to just comment on a couple of things, and got carried away. But I really do find this topic very interesting.
On Tue, Sep 2, 2014 at 2:03 PM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
When it comes to your extremely complicated templates with embedded lisp, you're losing *both* of these.
The templates are extremely complicated in implementation, which is irrelevant. If templates were rejected based on extremely complicated implementation, that would rule out essentially everything that uses Scribuntu under the hood.
We already have user studies (which I don't have the links for offhand) that
show that people see the relatively simple infobox templates in articles and give up.
Heh. Studies. Complete this phrase: "Lies, damn lies, and..." :-P Seriously, though, I know from direct observation there are people who have trouble with templates comparable to Wikipedian infoboxes; of course, named parameters are a rather baroque aspect of template call syntax, which I've already remarked is not as light-weight as one could wish. (Although in my experience most people don't get it overly wrong, and after being shown once what they'd not quite gotten right, usually don't get it wrong again.) It does seem a bit surprising to suggest that somebody who can't figure out how to fill in the blanks in an infobox would be more able to write in Lua.
The advantage to having the complexity of Lua in modules is that the
complexity specifically is hidden from new users. Once someone gets to the point where they're ready to make that step, they're probably motivated enough that looking through the manual (or even better would be if someone would write some good tutorials) isn't likely to be the barrier it would be to a complete newbie.
Tutorials are a /horrible/ way to convey information. As are manuals. This is one of the key weaknesses of wikis, I think, that they're atrocious at passing on wiki-expertise. Users can learn some things by the incremental path I've described, but beyond that, wikis naturally fall back on documents, because that's all the wiki software is good for specifying. Documents. Afaik, /all/ the sister projects complain that they provide these carefully written welcome templates that explain all about how to do things on that project, and nobody reads them. New variant on RTFM. I once put a welcome template on a newcomer's user talk on en.wb and they actually complained to me about it, saying they'd been to lots of different sister projects and they all annoyingly insisted on /welcoming/ them, they'd been welcomed to death, cut it out already.
What I think /can/ work is an interactive wizard, where at every step the advice/help for that particular step is right there, in-your-face. Hence my intent to provide tools that enable wiki communities to build their own wizards, completely cutting out the middleman (because the wiki community is where the expertise already resides, and wikis thrive on just-do-it, cutting out the middleman).
I don't think most users are going to progress from wiki markup to Lua. Certainly it requires a deeper commitment than the sort of incremental progression I'm advocating. And lowering the bar for participation is also part of what wikis are about.
Sure you can; a little boilerplate is needed, but both that and the
language itself are simple enough that someone could start from some basic examples and experiment easily enough.
Oh, lol. What was that you were saying about cargo-cult programming? (This is meant as /good-natured/ ribbing. I invite you to laugh with me.)
Seriously, cargo-cult programming, or the equivalent, is how much of wiki contribution works (I suppose we shouldn't open the cargo-cult-professional-programming can of worms). Somebody with deeper understanding might come along later and improve things, and that's good too, but that's later.
On the other hand, Lua's syntax and operation is similar to that of C, PHP, JavaScript, and so on, which are likely to be familiar to users with some sort of programming experience. While parser function syntax somewhat resembles Lisp, I'm not sure that similarity will help with understanding more than the surface.
I mean to avoid cutting off the long tail of users who /don't/ have some sort of programming experience. I'm not worried about those whose experience somehow leaves them able to figure out Lua but not minimalist lisp; I'm not sure that's even a nonempty set, and if it is I doubt it's all that significant. Give me your huddled masses yearning to breathe free any day. Also, most of them don't have to understand more than the surface.
I'm not also sure that Lisp's extremely simple syntax is necessarily an
advantage. While extra syntactic structure requires extra learning, it also means that the written code is more structured which may be easier for humans to make sense of. Again, look at the trouble people report in understanding complicated templates.
It's possible for very compact stuff to be hard to understand because it's so compact (APL comes to mind :-). But if it's all in one place (because it's so compact) that also is an advantage. I don't find the comparison with complicated templates compelling, though; seems to me that's heavy syntax.
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 don't see how Lisp is helping that either. If you want interactive pages, JavaScript is the way to go. Or did you write your Lisp parser in JavaScript too?
No, I don't write the Lisp parser in JavaScript. My tools mediate transferring data between different parts of the system, remember. One of the things they can do is snarf the entire raw markup of another wiki page and feed it into the template-expansion process as a template parameter. (No, that's not easy to do, at least I don't know an easy way to do it, and it's the point at which I'm concerned the current implementation may not scale well to large wiki pages.) So the problem of transforming a page --- such as the way HotCat does, or the way the "submit for review" button on a Wikinews article does, or whatever --- is reduced to a string operation. But it's really quite a sophisticated string operation. My embedded specialized lisp dialect has primitives specifically chosen to be good at that sort of thing.
Isn't your Lisp stuff also half-replacing templates with something else? Or are you overlooking that because Lisp syntax resembles that of templates?
I quite agree that my lisp interpreter is not improving templates, but providing in effect an alternative to them in certain cases. It's also an alternative in those cases to Scribuntu --- an alternative that remains embedded in wiki markup.