Live data from Hacker News

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

kylecordes.com

41–50 of 61 posts

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

#41
post #12

Earlier quoted context omitted.

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…

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.

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?

At the very least, there should be a first-class type that maps 1-to-1 with a Unicode CodePoint. Then there should be easy ways to do common operations on strings in terms of CodePoints. (Like string comparison, substring matching, concatenation.) Furthermore, the encodings should be handled in a transparent way.

If the goal is to keep Lua to a 200k core, then there should be a mechanism to add such functionality as if it's built in.

EDIT: "transparent" meaning, it looks like core functionality.

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

#42

Earlier quoted context omitted.

(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…

Are you affiliated with Lambda Lounge in STL?

I'm Alex Miller, the founder of Lambda Lounge. If you want to drop me a line email me at

contact at puredanger.com

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

#43
post #33

Earlier quoted context omitted.

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.

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.

Where "obvious" = something only someone with a foreign viewpoint thinks about.

("foreign" with regards to programming language.)

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

#44

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

You forgot my favorite:

  $ time clojure -e '(println "Hello, world!")'
  real	0m0.781s
Yeah, I know it's the JVM but still.

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

#45

Earlier quoted context omitted.

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.

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? At the very least, there should be a first-class type that maps 1-to-1 with a Unicode CodePoint. Then there should be easy ways to do common operations on strings in terms of CodePoints. (Like string comparison, substring matching, concatenation.) Furthermore, the…

> If the goal is to keep Lua to a 200k core, then there should be a mechanism to add such functionality as if it's built in.

There is. See "metatables" - the behavior of tables (Lua dicts) and userdata (handles to C pointers, or raw C pointers) is intentionally left minimal but extensible, so that new first-class ("transparent") types can be added.

For example, Lua doesn't have full regexp support* , but there's LPEG (http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html), a library that adds a PEG-based matching/parsing engine (which is a superset of REs). It's no less usable for being in a library rather than the core.

* Though what it does have (http://www.lua.org/manual/5.1/manual.html#5.4) if often good enough - the main thing missing is groups, e.g. "a+(ab|bc)?d".

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

#46

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

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.

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

#47
post #33

Earlier quoted context omitted.

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.

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.

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.

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

#48
post #46

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

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

[deleted]

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

#49

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

the most senceless benchmark ever.

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

#50
post #46

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

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

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".
Post reply on HN