RE: Wikipedia Chooses Lua As Its New Template Language

["Andre Naef" <andre@...>]

FWIW:

---
Lua 5.2.0  Copyright (C) 1994-2011 Lua.org, PUC-Rio
> return math.log10, table.maxn
function: 0x41dda0      function: 0x41f290
---

Compiled with compatibility on.

I am fine with deprecated functions no longer being documented. One should
not be using them, unless it's legacy code-for which there is the legacy
documentation. I prefer this to, say, the Java model, which deprecates a
lot, and removes nothing ;)

-----Original Message-----
From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
Behalf Of Tim Starling
Sent: Montag, 6. Februar 2012 00:33
To: lua-l@lists.lua.org
Subject: Re: Wikipedia Chooses Lua As Its New Template Language

On 04/02/12 11:17, Axel Kittenberger wrote:
> Three things: Lua never looked back too much. This was also a good 
> recipie to create a clean language, which releases did not break 
> something? I think thats the options you get in language development, 
> either you are always fully backward compatible like many others are, 
> and after a while you just pile the dirt and binary gets larger and 
> slower due to all compatibility checking or you get complaints about 
> breaking. Compared to 4.0 to 5.0 breaking, current changes are 
> negligible.

I'm not asking for much, just that math.log10 and table.maxn be deprecated
but not removed, and that they continue to be documented in the manual. It
doesn't seem unreasonable, given that Roberto Ierusalimschy said in 2010
that 5.2.0 would be probably be released with compatibility modes on:

http://article.gmane.org/gmane.comp.lang.lua.general/66133

> About the LuaJIT vs Lua5.2. It depends on how much CPU vs. IO impact 
> you have. I suppose you might tend to the later where it JIT doesn't 
> matter much, since the time gets burned in IO. Tim Caswell reported 
> with his development of Luvit (https://github.com/luvit/luvit Like 
> Node.JS just in Lua) that in most examples he did, he meassured twice 
> as fast than Javascript due to smaller C barrier, but hardly any 
> difference between vanilla Lua and LuaJIT.

I often hear that said, but I wouldn't analyse performance that way.
10ms waiting for a disk to seek doesn't cost you the same amount as 10ms of
processing time. Maybe if your server costs are negligible and all you care
about is user experience, then it makes sense to optimise for latency, but
that's not the world I live in.

CPU user time is a proxy for compute cluster cost. IO latency isn't really a
proxy for cost, so it makes sense to analyse IO separately, using different
methods.

-- Tim Starling