
Lua Doesn't Suck – Strange Loop 2010 20-minute talk video - kylecordes
http://kylecordes.com/2010/lua-strange-loop
======
indigoviolet
I haven't seen the video [do they discuss this?], but the biggest problem I
have with Lua is its lack of good unicode support. The Lua wiki suggests
slnunicode and ICU4Lua, but neither library has been updated for a year.

I'd love to use Lua instead of Python for some tasks, given that LuaJIT kicks
ass. But poor support for something as important as unicode is a deal breaker.

Am I just missing some information in this regard?

~~~
jacques_chester
> Am I just missing some information in this regard?

A major, and non-negotiable, design goal of Lua is that it targets the ANSI C
environment to maximise portability. ANSI C does not define Unicode support.

Incidentally, those two libraries might be unchanged because they're stable.
The rate of change in the main lua implementation is quite measured.

~~~
benatkin
The Lua philosophy is far different from the philosophy of other languages.
That's why videos like these, that cover the advantages before the tradeoffs,
are a good thing. Knowing the positive things about something really effects
my perceptions of the tradeoffs.

Also, Unicode is an odd thing to consider to be an essential part of a
programming language. Usually when I hear it I think the person must think
it's a part of accepting those that speak other languages. I would point out
the fact that Ruby took much longer to get Unicode support than Python as a
counterpoint to that, as Ruby's creator, Matz, is Japanese.

~~~
arkx
As a Finnish software dev I can say that in these days native support for
Unicode is a must. We have a couple of special characters in the alphabet
(åäö) and if you have to do a lot of manual work to use these, the programming
language is pretty much unusable for real world stuff that involves any use of
Finnish.

The fact that Ruby took so long to get real Unicode support is due to Japanese
resisting Unicode in favor of their own encodings, EUC-JP and Shift JIS, just
like Finnish used to cling to ISO-8859-1(5) for so long.

~~~
silentbicycle
Is Unicode something that needs to be in the _core_ of a language, or is it
sufficient to leave it to libraries, if the language's design doesn't prevent
it?

On this computer (OpenBSD/i386), icu has over 1 MB of libraries and a 15 MB
data file. The whole Lua distribution fits in one 200k library. Bloating the
core language with that seems impractical.

~~~
arkx
In my opinion, it needs to be in the core.

Imagine you need to go through a library every time your string includes or
might include the letter "s" or "v". Basically you'd need to use this library
for all your strings. But then you lose compatibility with 'normal' string
type and need to be constantly aware of the difference. You might want to use
some other library that doesn't support this Unicode library at all, etc. It
quickly becomes a very painful world to live in.

As you might imagine, just having support for Unicode baked in the language is
very nice. Defaulting to Unicode for all text is even better.

I can understand why Lua in particular doesn't come with Unicode support out
of the box, being so small. My comment was written in response to the more
general claim that Unicode support is a strange thing to consider essential in
a programming language.

(According to <http://www.bckelk.ukfsn.org/words/etaoin.html>, s/ä and v/ö are
comparable in frequency.)

~~~
silentbicycle
I think we have slightly different ideas about the language core vs. library
distinction. In C, for example, printf and strlen are library functions
(stdio.h and string.h), while structs are part of the core language.

All the language core needs for Unicode is reasonable support for tagging
string literals (i.e., U"blah") and a binary-safe string type. It's best if
there's either a standard or de facto community standard library for doing
Unicode string ops, but it doesn't need core support anymore than the Linux
kernel needs to know about parsing HTTP.

------
olliesaunders
For a time I was seriously considering using Lua for building web applications
but after playing with it for a four days I decided the community just wasn't
ready and I wasn't prepared to put in the work myself. A lot of the libraries
were incomplete/being changed (lots of bitrot) and very few unit tests. As a
language though Lua is pretty cool, a cleaner, smaller, faster, JavaScript.

------
wyclif
Full version of "Programming in Lua", available for free on Google Books:
<http://books.google.com/books?id=ZV5hXZ8QPKIC>

~~~
probablycorey
That book is a little dated because it deals with Lua 5.0 but is still good.
The differences between 5.0 and 5.1 can be found here
<http://www.lua.org/manual/5.1/manual.html#7> and new version of the book can
be found on amazon.

~~~
silentbicycle
It will still give you a good taste of the language, but PiL 2nd ed. and the
reference manual will be much more useful in the long run.

------
netghost
I'd say lua is great, well good, it's just that it's entirely reasonable,
which makes it kind of boring ;) It as been the least surprising language I've
used.

~~~
silentbicycle
There's deep stuff there (look into coroutines and metatables), but Lua has
been carefully designed so that it doesn't get in the way. If all you want
from Lua is a (JSON-like) format for data dumps or config files, you can
safely ignore the rest of the language. It's like the opposite of C++ that
way. :)

~~~
kylecordes
That is exactly how I introduced Lua in to one of our projects: as a very -
little code way to handling a complex configuration situation. It grew in to
full scriptability.

------
olliesaunders
Very unscientific but hopefully interesting:

    
    
        $ time php -r 'echo "Hello, world!";' # smaller php binaries can be compiled
        real 0m0.555s
        $ time perl -e 'print "Hello, world!";'
        real 0m0.385s
        $ time ruby -e 'puts "Hello, world!"' # mri
        real 0m0.073s
        $ time python -c 'print("Hello, world!")'
        real 0m0.067s
        $ time lua -e 'print "Hello, world!"'
        real 0m0.013s
        $ time js -e 'print("Hello, world!")' # spidermonkey
        real 0m0.010s
        $ time awk 'BEGIN { print("Hello, world!") }'
        real 0m0.004s

~~~
avar
You're right about one thing. That is very unscientific. You're mainly testing
your file system cache, not these programming language implementations.

E.g. perl(1) is faster than ruby(1) at printing "Hello, world!". But since you
presumably had ruby hot in cache and not perl the latter seems to be almost 4
times as slow.

Here's a better benchmark, which runs each of these 500 times and takes the
average: <http://gist.github.com/630868>

Which yields these results:

    
    
                   Rate clojure   php emacs python  ruby   js perl  awk  lua shell     C
        clojure 0.844/s      --  -97%  -97%   -98%  -99% -99% -99% -99% -99%  -99% -100%
        php      24.6/s   2812%    --   -2%   -43%  -75% -76% -78% -82% -82%  -84%  -89%
        emacs    25.2/s   2882%    2%    --   -41%  -74% -75% -78% -81% -82%  -84%  -88%
        python   43.0/s   4995%   75%   71%     --  -56% -58% -62% -68% -69%  -72%  -80%
        ruby     96.7/s  11361%  294%  284%   125%    --  -5% -15% -28% -29%  -38%  -55%
        js        101/s  11919%  313%  303%   136%    5%   -- -11% -24% -26%  -35%  -53%
        perl      114/s  13397%  364%  353%   165%   18%  12%   -- -15% -17%  -27%  -47%
        awk       134/s  15743%  444%  431%   211%   38%  32%  17%   --  -2%  -14%  -38%
        lua       137/s  16134%  458%  444%   219%   42%  35%  20%   2%   --  -12%  -36%
        shell     156/s  18359%  534%  519%   262%   61%  54%  37%  17%  14%    --  -28%
        C         216/s  25440%  777%  756%   401%  123% 113%  89%  61%  57%   38%    --
    

Update: Added a C program and ran the shell program in a sub-shell (since
perl's system function preloads a shell). Didn't add silentbicycle's SWI
Prolog and OCaml since he didn't provide the source.

~~~
silentbicycle
What we're essentially measuring here is runtime startup and (in some cases)
byte-compiling.

    
    
               Rate python swipl ruby perl  lua luac bash ocaml  awk subshell ocamlopt    c py_pyc shell
        python   46.3/s     --  -17% -56% -70% -76% -78% -78%  -79% -83%     -87%     -88% -88%   -90%  -92%
        swipl    55.9/s    21%    -- -46% -63% -70% -73% -73%  -74% -80%     -84%     -85% -86%   -88%  -90%
        ruby      104/s   125%   86%   -- -31% -45% -49% -51%  -52% -62%     -71%     -72% -74%   -79%  -82%
        perl      152/s   229%  172%  46%   -- -20% -26% -28%  -30% -44%     -57%     -60% -61%   -69%  -74%
        lua       189/s   309%  239%  82%  25%   --  -8% -10%  -13% -31%     -47%     -50% -52%   -61%  -67%
        luac      206/s   345%  268%  98%  35%   9%   --  -2%   -6% -25%     -42%     -46% -48%   -58%  -64%
        bash      211/s   356%  277% 103%  39%  11%   3%   --   -3% -23%     -41%     -44% -46%   -57%  -63%
        ocaml     218/s   372%  290% 110%  44%  15%   6%   3%    -- -20%     -39%     -42% -45%   -55%  -62%
        awk       273/s   491%  389% 162%  80%  44%  33%  30%   25%   --     -23%     -28% -31%   -44%  -52%
        subshell  357/s   672%  539% 243% 135%  89%  74%  69%   64%  31%       --      -6%  -9%   -26%  -38%
        ocamlopt  379/s   719%  577% 264% 149% 100%  84%  80%   73%  39%       6%       --  -4%   -22%  -34%
        c         394/s   751%  604% 278% 159% 108%  91%  87%   80%  44%      10%       4%   --   -19%  -31%
        py_pyc    485/s   950%  768% 366% 219% 156% 136% 130%  122%  78%      36%      28%  23%     --  -16%
        shell     575/s  1143%  928% 452% 278% 203% 179% 172%  163% 110%      61%      52%  46%    18%    --
    

I added hello world programs for C, SWI Prolog, and OCaml (byte and native
compilers). Timings on OpenBSD/amd64.

Edit: Since you can precompile Lua, I added that as 'luac'. It's not usually
done, since Lua compiles VERY quickly, and the source is more portable. It's a
data point, though. I also added a .pyc for Python - Python byte-compiles more
slowly. There's little difference between lua and luac, but the difference
between python and py_pyc is _huge_.

I also added shell with a new subshell, both sh and bash. And, source, as
requested.

OCaml:

    
    
        let _ = print_string "Hello world.\n"
    

Compile with "ocamlc -o ochello foo.ml" for bytecode, "ocamlopt -o ochello.opt
foo.ml" for native.

SWI Prolog:

    
    
        swipl => sub { system qq[swipl -g "write('Hello world.\n')." -t "halt."] },
    

luac:

    
    
        print "Hello, world."
    

And then compile with "luac hellow.lua", run as "lua luac.out".

------
mfollett
Great talk, Kyle. Also, the video turned out remarkably well given the camera
it came from.

~~~
kylecordes
Thanks. Here is the exact camera I used:

[http://www.usa.canon.com/cusa/support/consumer/digital_camer...](http://www.usa.canon.com/cusa/support/consumer/digital_cameras/other_powershot/powershot_sx100_is)

For the sake of any readers here who don't read the blog post: I do NOT
recommend this camera for video. I happened to have it sitting around for
family snapshots and chose to experiment with it here.

------
__david__
I've sat down to learn Lua a number of times because on the I really like the
idea of it (small, fast, safe, etc). It really has quite a beautiful
minimalism to it.

But each time I try I get to the part where I learn that array indices start
at 1 and I get annoyed. Have we not learned anything since BASIC? Sigh.

~~~
tryp
I found that adopting the native idioms meant never having to notice the 1-
based indexing. Everything is a hash table, and if you find yourself using
literal numeric keys, there's probably a nicer way to do it.

The lua users wiki is full of interesting ideas for tackling the basics in
ways that leverage lua's simple flexibility.

~~~
__david__
That is entirely possible. I can tell if someone doesn't know perl or python
because they write for loops like a C coder instead of looping over
containers. So I can believe that you don't come in contact with that detail
very often.

It just bugs me that such an obvious wart exists in an otherwise very clean
language.

~~~
silentbicycle
The reason the arrays index from 1 is that Lua is designed to pare down to a
data description & configuration language for non-programmers, and they felt
that starting arrays from zero would be confusing. I don't like it it either,
but in practice it's a minor issue.

People who write off Lua because of indexing from 1, Python because of the
significant whitespace, Lisp for its pares, etc. probably haven't gotten to
the really interesting stuff yet.

