The Signpost

Technology report

Why "Lua" is on everybody's lips, and when to expect MediaWiki 1.19

Contribute  —  
Share this
By Jarry1250

Lua chosen as new template scripting language

Reducing the inefficient complexity of complicated templates has long been on the wishlists of those who design and maintain them. It is a complexity that can put a significant drain on server resources, not to mention one that makes accurate duplication of templates between wikis incredibly time consuming and error prone. This complexity is caused by a number of factors, but it has long been recognised that the introduction of certain constructions found in full programming languages (among them loops, arrays and a full range of string functions) would drastically simplify matters.

Of course, the introduction of a programming language would bring with it a number of other problems, particularly with regards to privacy, security and memory footprint. As a result, the long term consensus was that the introduction of a programming language would be a major undertaking, including time for discussing which languages would work best in a heavily sanitised environment. The project as a whole has been discussed at regular intervals, but it was only this week that a consensus seemed to emerge in favour of Lua, a lightweight but relatively unheard-of language generally regarded as being "easy to learn" (wikitech-l mailing list).

The preferred implementation at this time is via a separate namespace for scripts, perhaps augmented by the overloading of the double-curly-brace notation to incorporate both Script and Template namespaces. Work is expected to start after the release of 1.19 and could well centre around the Berlin Hackathon, held annually in May.

In brief

WMF Director Tomasz Finc took the time this week to look back at the significance of the recent Android app release

Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.

+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.
It strikes me that it's profoundly unlikely to be worse. As a programming language, ParserFunctions is horrible. At work this month I've been doing large and complicated things with ant ... I've nicknamed it mod_brainfuck. Turing complete is actually a sort of curse - if all you have is a hammer and it's Turing-complete, you will use it as a screwdriver, spanner, soda siphon, nail ... - David Gerard (talk) 08:28, 31 January 2012 (UTC)[reply]
  • I remember LUA from the old days scripting my World of Warcraft client (they it for the same reasons: security and light weight). It's not a bad language (even if I found it a bit confusing). -- Luk talk 09:27, 31 January 2012 (UTC)[reply]
  • "The potential for bias within the survey was not examined." what is the point in writing about useless surveys? Bulwersator (talk) 09:51, 31 January 2012 (UTC)[reply]
  • Moving to Lua will reduce the programming complexity of templates, which is good, but it will increase the resource utilization of the scripts, so somehow limitations will need to be introduced to limit script cpu time. Does Lua make this easy to do?Jeff Kubina (talk) 23:08, 31 January 2012 (UTC)[reply]
    • One of the positives of Lua discussed was the ease with which memory limits can be imposed to prevent accidental/deliberate massive memory allocations taking down whole servers. (Note that I would not be so sure average resource utilisation will go up rather than down: some templates are very resource-intensive at present.) - Jarry1250 [Deliberation needed] 23:19, 31 January 2012 (UTC)[reply]
      • Excellent! Thanks Jarry. So then in terms of current templates I agree, I suspect many of them would run much more efficiently in Lua. What I suspect will happen though is that templates will evolve to provide much more (better, useful) information using about the same amount of cpu time that they use now to be generated (and be easier to write); so it is a long term win situation. Jeff Kubina (talk) 04:12, 1 February 2012 (UTC)[reply]
  • Since when is Lua "relatively unheard-of"? --cmelbye (t/c) 00:21, 1 February 2012 (UTC)[reply]
    • Of course "relatively unheard-of" a subjective term. Since it's an issue that interests me, I thought I might as well do some digging:
      • On Github it ranks at #18 for number of repos and #17 for number of users, way behind JavaScript, which was also considered for this role, and PHP, the main language of MediaWiki itself (source).
      • Probably due to the fact that it is mainly known in game programming circles, it did not rank in a 2007 survey of job adverts
      • It was not included in this top-ten of programming languages by book sales
      • In this comprehensive analysis it ranks at #15 by Yahoo! searches, #21 for job adverts, #26 for book sales, and #15 for projects.
    • Of course, I have used ordinals, but I could have used cardinals. I agree that maybe people have heard of it (literally speaking) but the point I was trying to make was more figurative, and relates to the fact that Lua is an unfamiliar language to virtually all wiki admins and even a considerable percentage of the "hard core" of WMF techies. - Jarry1250 [Deliberation needed] 00:48, 1 February 2012 (UTC)[reply]
  • As a programmer, I look forward to this. I don't know any Lua, but I've heard good things about it, and I'm sure I can pick it up. I'm also confident it will be more satisfying to work on than ParserFunctions-based templates. Superm401 - Talk 22:56, 1 February 2012 (UTC)[reply]
  • I am very excited about Mediawiki supporting a real programming language for extensibility. This will dramatically reduce complexity and improve readability and maintainability, and remove a lot of very annoying limitations due to template nesting limits. It'll also enable new things that heretofore were considered too complex or inefficient to undertake. Dcoetzee 03:33, 2 February 2012 (UTC)[reply]
  • This sounds great! I can't wait to get my hands on Lua capabilities in my Semantic templates. Jamie (blog | hello) 03:44, 2 February 2012 (UTC)[reply]
  • Lua is a very nice programming language, that isn't that hard to learn. I'm looking forward to being able to use it in templates, ect. If you want documentation, you can look here. I presume for output, we'll use print("Hello World"), and stuff like that. It will be interesting to see what gets removed, and what stays when they update. (FYI, people get picky when you call it 'LUA' as it's not an Acronym, or when you call it 'lua', as 'lua' is portugues for moon. Make sure you call it Lua. :D) Idofen (talk | contribs | February 2) —Preceding undated comment added 07:39, 2 February 2012 (UTC).[reply]
  • Lua has no native Unicode string support. How will this be addressed? 67.6.156.62 (talk) 22:28, 2 February 2012 (UTC)[reply]
  • Is there any example comparing the MediaWiki parser function and Lua? Thx. -- Sameboat - 同舟 (talk) 13:14, 5 February 2012 (UTC)[reply]
  • The ability to construct complex if statements will certainly be of great value. With ParserFunctions, the only real option at present is to resort to writing code such as this which looks more like obfuscated code than anything else. Having to write code this way also means it is extremely difficult for many people to understand and modify.

    Probably the thing I find the most unusual about Lua is the use of and and or instead of && and || for logical operators. I'm sure there was a reason these keywords were chosen for logical operators, but these and the end keyword still seem odd.

    If we are finally going to implement a real programming language, I also hope we end up with some support for true regular expressions (and not just pattern matching). Regular expressions would simplify far too many things to count. --Tothwolf (talk) 14:02, 5 February 2012 (UTC)[reply]

    • You can also have complicated datastructures. For example, instead of having a 100 input thing for a input you can use tables. (I presume this stuff will be formatted as a function). It would look like this:
 function List(...)
 for _, Text in pairs({...}) do
 print([==[
 <div>
 ]==]..Text..[==[
 </div>
 ]==]
 end
 end

Which takes in every single input , and puts it in a <div </div> . Idofen (talk | contribs | April 26) —Preceding undated comment added 02:10, 26 April 2012 (UTC).[reply]




       

The Signpost · written by many · served by Sinepost V0.9 · 🄯 CC-BY-SA 4.0