Re: Why Lua is not more popular

[steve donovan <steve.j.donovan@...>]

On Thu, Sep 19, 2013 at 2:28 AM, Henning Diedrich <hd2010@eonblast.com> wrote:
> It's a leap, but because the big challenges for the big VMs seem to be
> similar, especially if we ended up only having one, "the" VM one day, then
> todays embeddables would probably also not have to be embedded any more but
> simply come as one of the syntaxes offered, probably even preserving
> characteristics of the original runtime.

Well, the divorce between Java and C# was pretty nasty (some have said
that the $100m that Sun got in damages is the most they've ever made
out of Java) so those runtimes aren't going to converge soon.  This is
good, because C# went ahead and did some things better and provided
useful competition so Java was forced to improve.  And yes, we do see
Lua implementations on these runtimes, although being Lua there are
always a number of choices in various stages of big-time readiness ;)
(This is apart from the reflection-based interfaces like LuaInterface
and LuaJava)

As 'Lua as alternative syntax': it would no longer really be Lua and
would use the semantics of the VM.  No longer convinced this is a cool
thing, since it is confusing to have something that _looks_ familiar
and _acts_ so differently. (E.g. a naive translation of Lua to
JavaScript)

> Along the lines Graham described [2] about how hardware power will make the
> benefits of nimbleness less interesting over time.

OK, with faster hardware, people worry less about compilation time.
However,  this cannot be swept under the carpet, since C++ is still a
dog to build and Google's motivation with Go was to make something
simpler that would compile really fast (one of the several 'back to
Pascal' simplifications that have happened in CS history).  So even in
the 21st century people appreciate nimbleness.  To someone used to
Lua, Python seems irritatingly slow, especially to start up!  And (NB)
not everything happens in computer time.  A game runs in player time,
a bank app runs in transaction time, a way to change a running
application without restoring state will always be popular.  The
analogy I like is that we're moving towards 'operating on live
patients'.

steve d.