Lua Doesn't Suck – Strange Loop 2010 20-minute talk video

http://kylecordes.com/2010/lua-strange-loop

by kylecordes • 16 years ago

90 59 16 years ago

wyclif• 16 years ago

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

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.

silentbicycle14• 16 years ago

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.

tung• 16 years ago

Also available on its official site: http://www.lua.org/pil/

indigoviolet6• 16 years ago

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_chester2• 16 years ago

> 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.

kylecordes4• 16 years ago

(I'm the guy in the video.)

I haven't had a need for Unicode in Lua, but when I stumbled across some information about it, the essential story was that there is nothing stopping you from writing code to manipulate Unicode data (obviously), but there is also nothing built in to help you. All the built in string stuff is ANSI/ASCII/whatever.

However, the language Io (which often gets mentioned in the same breath as Lua, though it's quite different in some ways) has a stronger Unicode story: http://www.iolanguage.com/scm/io/docs/IoGuide.html#Unicode

benatkin• 16 years ago

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.

silentbicycle14• 16 years ago

More specifically, Unicode is one of those things (like bignum support) where Lua's design for embedding assumes that if it's a priority, your project will already have settled on a library for it, so anything Lua came bundled with would just get in the way. The GMP library, for example, is almost four times larger than the whole Lua runtime.

Besides, Lua strings are interned raw byte-arrays (like atoms in Erlang or Lisp atoms), and can have \0s and other arbitrary binary data. While the standard string library is ignorant of Unicode, there's nothing preventing extra libraries from providing Unicode-aware string operations.

Lua also left out native regular expression support, because it would be larger than the rest of the standard libraries put together. You can just load LPEG if it matters.

indigoviolet6• 16 years ago

slnunicode hasn't changed or been updated, and has no forum posts or bugs since 2006 [http://luaforge.net/projects/sln/]

ICU4Lua hasn't been touched since April 2009, and is at 0.2B. [http://luaforge.net/projects/icu-lua/]

That sort of status just doesn't inspire confidence in a language. I understand you can use it for game programming, or that you can write your own libraries for it, but that sort of thing doesn't encourage adoption.

metamemetics3• 16 years ago

http://luaforge.net/projects/ul-str/

Last updated June 21st 2010. Readme seems to indicate it supports all the important stuff like compare, concatenate, encode, lower<->upper, Regexp, url escaping.

Says beta and I haven't tried it yet tho : /

indigoviolet6• 16 years ago

Thanks, that's useful to hear. It isn't on the wiki page: http://lua-users.org/wiki/LuaUnicode (which hasn't been touched since Sep 2009).

SeanLuke3• 16 years ago

> 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.

Hear hear. I too don't care much for the argument that Lua doesn't have unicode because C doesn't have unicode. For two reasons. First of all, Lua can be straightforwardly embedded into a host of other languages (for example, http://tinyurl.com/39qhxzw). Second, who in their right mind thought that a language designed for embedding into commercial applications shouldn't have good I18N? (And honestly, how in the world could someone from Brazil develop a programming language that doesn't even support their own spoken language? It's as if Ruby was developed by someone in Japan.)

A bit of history. From what I have gathered in its documentation, Lua steals quite unabashedly from NewtonScript. NewtonScript was a proto-style OO language developed in a hurry for the Newton when the Dylan language wasn't going to deliver. Like Lua, it's a language designed originally for an interpreter, which runs embedded in an outer C++ environment and must interoperate with it. But NewtonScript doesn't just use Unicode pervasively: it was the first major language to do so. And C++ interoperability with the language is just fine. So this Lua-needs-to-work-with-C-and-thus-can't-do-unicode thing is nonsense both in fact and precedent.

And while we're on the subject of NewtonScript: Lua's let's-almost-do-proto-style-OO-but-require-the-user-to-do-extra-work is really incredibly annoying. Lua should have had proto OO built into the language, like NewtonScript, and not just "available", in a hacked way, through its meta model. Lua wants to be more "general" than NewtonScript, but it just winds up being (IMO) rather less usable.

silentbicycle14• 16 years ago

Lua is as old as NewtonScript. Its authors have mentioned Scheme, SNOBOL, awk, bibtex, Icon, and (IIRC) Self as influences, but I don't recall them mentioning NewtonScript. Javascript also has a lot in common with Lua. I think it's because the trade-offs inherent in embedded scripting languages are making them converge on a similar overall language design, rather than plagiarism.

If you're putting Lua in a commercial application, the commercial application itself will provide the i18n, and Lua can use it with very little trouble. Lua's strings are raw byte arrays - you can load arbitrary binary data in them. A library that reads UTF-8 strings (say) can work with them just fine. (And while I don't speak Portuguese, there are examples in PiL that use it without problems.)

I disagree with you about whether metatables are annoying, but it's a matter of taste. I haven't ever used NewtonScript, but I do use metatables for quite a bit more than just prototype OO - it's easy to turn a table into a proxy + cache to a function, for example. Also, my Lua redis library (http://github.com/silentbicycle/sidereal) turns table reads and writes into syntactic sugar for redis db key, list, and set operations.

netghost• 16 years ago

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.

silentbicycle14• 16 years ago

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. :)

kylecordes4• 16 years ago

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.

mfollett• 16 years ago

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

kylecordes4• 16 years ago

Thanks. Here is the exact camera I used:

http://www.usa.canon.com/cusa/support/consumer/digital_camer...

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__3• 16 years ago

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.

JulianMorrison• 16 years ago

What do you object to in counting from 1? (Other than it's not traditional.)

In C, it's an offset into a typed block of memory, so 0 indexing makes sense. But lua does not deal directly with memory.

__david__3• 16 years ago

It has nothing to do with indexing memory--it has to do with 1 based arrays causing "+1" and "-1" to be sprinkled all oever the place. I find Dykstra's argument to be compelling: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...

tryp• 16 years ago

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__3• 16 years ago

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.

pederb72• 16 years ago

Actually, Lua's table object is split into two parts. The array part, which is accessed using numerical indices, and the dictionary. It's done like that to enable fast array access, and I do find it an incredible useful feature in Lua.

In my experience 1-based indexing is not a problem when you're just writing Lua code. I've sometimes been frustrated when creating Lua bindings to C-modules which involved some kind of array access though.

olliesaunders2• 16 years ago

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

tl• 16 years ago

You forgot my favorite:

  $ time clojure -e '(println "Hello, world!")'
  real	0m0.781s

Yeah, I know it's the JVM but still.

avar• 16 years ago

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.

silentbicycle14• 16 years ago

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".

nickik• 16 years ago

the most senceless benchmark ever.

haberman• 16 years ago

Also interesting is how much memory is allocated running the empty program (detected with Valgrind):

    Lua 5.1.4: 34k allocated, all memory freed.
    Perl 5.10: 195k allocated (140k leaked!)
    Ruby 1.8.7: 670k allocated (665kb still reachable at exit)
    OpenJDK 6: 1.5M allocated (1M in use at exit).
    Python 2.6.5: 3M allocated (1.2MB in use at exit)

olliesaunders2• 16 years ago

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.

Lua Doesn't Suck – Strange Loop 2010 20-minute talk video

Related Stories