Wikipedia talk:Wikipedia Signpost/2012-01-30/Technology report

From WikiProjectMed
Jump to navigation Jump to search
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]