Live data from Hacker News

Why Lua?

blog.datamules.com

91–100 of 142 posts

Re: Why Lua?

#91
post #79

Earlier quoted context omitted.

I can't speak to what most people expect from lambdas; I force myself use Tcl's [apply] occasionally just to try slightly different paradigms, so I appreciate your commentary. One thing to note though, your final [inc 1] has nothing to do w/ $inc. In the interactive REPL (which I'm assuming you used), Tcl will (by default) essentially autocomplete commands if it can, and [inc] completed to [incr], which is "increment…

I didn't know that tclsh autocompletes commands; that's pretty neat. In this case, it looks like [incr 1] is incrementing a variable called 1, and appears to start from zero if the variable isn't initialized. I find Tcl's command model interesting because it leads to a very tiny semantics. A few years ago I spent a lot of time thinking about how it could be extended to have lambdas, and I couldn't come up with a way…

@groovy2shoes (and anybody else who's interested in modern (or historic, for that matter) Tcl), you should drop by #tcl on irc.freenode.net. We'd love to have you visit.

Re: Why Lua?

#92

To echo chubot: Why isn't Lua more widely used? * It lacks an easy-to-use symbolic debugger. * It lacks a first-rate IDE. * It lacks a standard way for people coming from OO/Java to define objects and interfaces. * It lacks a GUI toolkit. * It has a great set of manuals. It lacks an O'Reilly book with a woodcut animal on the cover. * Arrays indexes start at 1. Except for the last item, these are all relatively small…

It lacks a standard way for people coming from OO/Java to define objects and interfaces.

If you ask in IRC or google around you can find this pretty easily. The first result on google for query "lua class" is http://lua-users.org/wiki/SimpleLuaClasses.

Re: Why Lua?

#93

Not criicizing lua, but worth comparing to guile. > Integration with C (and C++ for that matter) Guile does it better. You can use shared memory threads in guile without any penalty. Atmost you have to allow for the garbage collector to run when inside FFI functions. But that is a small price to pay in case you need to use multiple parallel-concurrent threads with a single heap. Guile was built with FFI in mind and h…

Not sure if I'd agree that Guile's FFI bindings are better than LuaJIT's FFI. It's certainly easier to declare a function in LuaJIT - you can take the definition directly from the header file, rather than transcoding it into s-exps. Compare: (define memcpy (let ((this (dynamic-link))) (pointer->procedure '* (dynamic-func "memcpy" this) (list '* '* size_t)))) vs. ffi.cdef [[ void * memcpy ( void * destination, const v…

"As for the speed, there's no reason that a lot of dynamic languages couldn't be as fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster than V8 on the PC, and faster than Java on Android. And that's the interpreter - the JITed code is way faster."

[Citation Needed]

I know of old benchmarks (pre Crankshaft) that showed the interpreter being faster than V8, but my own tests using the same benchmarks from the computer language shootout show V8 to be about 1.5x faster than luaJIT now.

I did some searching, and the most recent (though still way out of date) comparison I could find was this: http://attractivechaos.github.com/plb/

Re: Why Lua?

#94

Not criicizing lua, but worth comparing to guile. > Integration with C (and C++ for that matter) Guile does it better. You can use shared memory threads in guile without any penalty. Atmost you have to allow for the garbage collector to run when inside FFI functions. But that is a small price to pay in case you need to use multiple parallel-concurrent threads with a single heap. Guile was built with FFI in mind and h…

With a small patch to add coroutine.clone[1], you can have continuations in Lua[2]. [1] http://lua-users.org/lists/lua-l/2006-01/msg00652.html [2] https://github.com/torus/lua-call-cc

Which is to say, Lua's coroutines are isomorphic to single-shot continuations* - you can implement either in terms of the other.

* Full continuations, with copying.

Great paper: "Revisiting Coroutines" (ftp://ftp.inf.puc-rio.br/pub/docs/techreports/04_15_moura.pdf)

Re: Why Lua?

#95

I took some Visual Basic programming courses in high school, some PASCAL courses in college, and then didn't program anything other than basic HTML/CSS for the next eight years. Last year I programmed an iPhone game in Lua (using the Corona SDK) and it was easy as Tau. Sure a better programmer would have finished the programming aspects in a quarter the time it took me, but I started by looking at Objective-C and I'm…

Doesn't Apple forbid applications built using things like this?

Re: Why Lua?

#96
post #52

Does anyone know how good is Lua's support for async IO? Especially the handling of large amount of connections and the memory footprint for each connection?

Luasocket does async IO. It uses poll or select on Unix (calling it 'select'); I'm not familiar with what it uses on Windows. It's not "web scale", but is very easy to use, and works well enough for a couple hundred simultaneous connections.

Lua's convenient C API means that wrapping libev, libuv, or libevent is really not hard, if you want to go that route. (I have a libev wrapper on github, FWIW.)

The thing to keep in mind is that if you're writing high-throughput servers, you probably want to avoid parsing the network IO via Lua. While Lua strings are fine with arbitrary binary data (i.e., \0s are fine), it interns all strings; you'll have the overhead of converting every read into an atom/symbol, and it will spend a lot of time garbage collecting. (Lua makes this daring trade-off because it's usually a net win, and when it isn't, you still have the option of doing things in C instead.) Lua's great for handling all the control logic, though. Coroutines are particularly applicable there.

In a nutshell: If you're good with C, and understand the issues involved with performant async IO, Lua can work very well.

Re: Why Lua?

#97
post #88

Earlier quoted context omitted.

Ya -- interactive tclsh has a few creature-features. The autocomplete we're discussing, automatic fall-through to exec as if via sh(1), command history, history editing, and perhaps more I'm forgetting. kamloops$ tclsh8.6 % info commands up* update uplevel upvar % uptime 7:17PM up 1 hr, 7 users, load averages: 0.06, 0.12, 0.17 % ls fu ls: fu: No such file or directory child process exited abnormally % ls -ld fu ls: f…

> automatic fall-through to exec as if via sh(1) That explains why X11.app launched that one time I forgot a `$` before my `x`...

That sounds likely. Note that is strictly for interactively typed commands. Witness:

  kamloops$ cat ls.tcl
  #!/usr/pkg/bin/tclsh8.6

  ls foo

  kamloops$ ./ls.tcl 
  invalid command name "ls"
      while executing
  "ls foo"
      (file "./ls.tcl" line 3)
  kamloops$ tclsh8.6
  % source ls.tcl
  invalid command name "ls"
  % ls foo
  foo
  % 
Now, back to your regularly scheduled Lua topic :)

Re: Why Lua?

#98
post #80
post #5

The article seemed a little short for me, but then I am actively trying to select between Lua and TCL for some personal scripting projects. There are many fine features with each language and few downsides, so the selection process is hard. Of course, that's a nice problem to have. TCL is ahead by a nose at this point with Unicode support baked in (vs. using a library) and file system handling built in (again vs. usi…

If you're considering TCL, the Jim implementation might also be worth a look. It has most of the features of the core language, some extensions to enable even more and a very small footprint. If I recall correctly, it's even faster for some things and does lambdas etc. a bit better. The bad thing about Tcl is probably its library support. It has an extension mechanism, but for a lot of "contemporary" projects (web et…

Interesting, thank you. I will take a look.

Re: Why Lua?

#99

Not criicizing lua, but worth comparing to guile. > Integration with C (and C++ for that matter) Guile does it better. You can use shared memory threads in guile without any penalty. Atmost you have to allow for the garbage collector to run when inside FFI functions. But that is a small price to pay in case you need to use multiple parallel-concurrent threads with a single heap. Guile was built with FFI in mind and h…

Can't get more functional than scheme :) Sure, per his def of FP, scheme is numbers 1 through 18 on the league table ;-} Other defs:

http://dl.dropbox.com/u/7810909/docs/what-does-fp-mean/what-...

http://existentialtype.wordpress.com/2011/03/16/what-is-a-fu...

http://stackoverflow.com/questions/2254368/if-java-people-go...

I'm not taking sides, i like haskell, scala, clojure just fine, I'm sure I would like racket or CL if i picked them up.

Re: Why Lua?

#100
post #5

The article seemed a little short for me, but then I am actively trying to select between Lua and TCL for some personal scripting projects. There are many fine features with each language and few downsides, so the selection process is hard. Of course, that's a nice problem to have. TCL is ahead by a nose at this point with Unicode support baked in (vs. using a library) and file system handling built in (again vs. usi…

Tcl is an interesting little language as well, and the niche it was created for is similar to the one Lua was created for. The biggest advantages that Lua has over Tcl, off the top of my head, are speed and lambdas. Tcl's semantics make it very hard to optimize because it is stringly typed (with some bytecode and value specialization in the background, but with conversions between strings and other values as needed).…

More good points for both sides. This is not making it easier.

I don't need speed as I'm doing offline processing and not worried about lambdas at this point. The unicode is important as I am looking to take Greek and Hebrew text and process it.

Post reply on HN