Re: Wikipedia Chooses Lua As Its New Template Language

[Tim Starling <tstarling@...>]

On 03/02/12 02:45, Mateusz Czaplinski wrote:
> On Wed, Feb 1, 2012 at 10:08 PM, Alessandro Delgado
> <adelgado1313@gmail.com <mailto:adelgado1313@gmail.com>> wrote:
> 
>     http://developers.slashdot.org/story/12/02/01/1429229/wikipedia-chooses-lua-as-its-new-template-language?utm_source=slashdot&utm_medium=facebook
>     <http://developers.slashdot.org/story/12/02/01/1429229/wikipedia-chooses-lua-as-its-new-template-language?utm_source=slashdot&utm_medium=facebook>
> 
> 
> After initial reading, I'm not quite sure if they're aware of the Lua
> 5.2 vs. LuaJIT "split". Mike's thoughts on the topic may not be widely
> known beyond this mailing list; or are they visible at least somewhere
> on the LuaJIT page?
> Shall someone educate them?

No, I was not aware of it. Thanks to Pierre for the forward. I read
the relevant mailing list thread in the archive.

We'd like to keep our implementation options open. I imagine that we
will start with Lua and consider a switch to LuaJIT once we have
real-world test cases and benchmarking data. But for that short
period, we can just stick with 5.1.

We want to support MediaWiki installations where Lua is executed by
shelling out to the standard interpreter. This will allow people to
copy scripts from Wikipedia to a broader range of hosting
environments. However, this does mean that we need to promote a lowest
common denominator feature set. If worst comes to worst, we can always
patch "goto" out of the lexer on Wikipedia until 5.2 is mature and
readily available for external users.

I'll make a few general comments about 5.2:

The lack of attention to backwards compatibility is concerning. I can
understand the environment changes, but the deprecation of math.log10
and table.maxn just seems arbitrary.

Their removal from the reference manual is worse still -- people still
have to read and understand old code, so they need to be able to find
the documentation for all of the functions which are present. If you
want to discourage the use of a function, write in the manual "use of
this function is discouraged", don't just remove it.

A manual comment about the version in which new functions were
introduced would also be helpful.

The break in backwards compatibility for C source, due to the extra
parameter to lua_load(), is annoying and could have easily been
avoided by introducing a pair of new functions (lua_load_string and
lua_load_binary). It's too late to change this now, I mention it as an
example of a pattern you might want to consider for 5.3.

I'm not concerned about changes to libraries like coroutine, package
or os, since we're not planning on exposing any of those to our users.

In general, we value stability. We're imagining an application for Lua
where scripts are distributed across many wikis, hosted on servers
both inside and outside our control, with script maintainers with
widely varying levels of expertise and commitment. So the impact of
backwards compatibility breaks could potentially be severe and
long-lasting.

-- Tim Starling