Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Lua?

blog.datamules.com

Post reply on HN
Print view View original

101–110 of 142 posts

Re: Why Lua?

#101

Post by groovy2shoes »

simon wrote: post #100
groovy2shoes wrote: post #10

Earlier quoted context omitted.

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.

You may be better off with Tcl, then, if you don't want to use a library for Unicode.

Re: Why Lua?

#102

Post by [deleted] »

sixcorners wrote: post #95
alanfalcon wrote: post #2

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?

[deleted]

Re: Why Lua?

#103

Post by anonymoushn »

ZitchDog wrote: post #54
moe wrote: post #47

Earlier quoted context omitted.

Why isn't Lua more widely used? I think the major, overwhelming reason is because it has no standard library, much less a package-ecosystem such as RubyGems or Python eggs.

You do know about LuaRocks, right? It's not as robust or vibrant as the Ruby or Python equivalent, but it certainly does exist. http://luarocks.org/repositories/rocks/

This could definitely stand to be better. I only learned about LuaRocks by googling around when make failed to build LuaSocket and the README was useless. By then I had been using Lua for about 3 years.

Re: Why Lua?

#104

Post by evgen »

sixcorners wrote: post #95
alanfalcon wrote: post #2

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?

As long as you are not running code that is downloaded after app install (e.g. either embedded in the app itself or entered by the user from the keyboard) you are good to go. This mod to the previously ominous app store policies is used by quite a lot of applications.

Re: Why Lua?

#105

Post by ww520 »

silentbicycle wrote: post #96
ww520 wrote: 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…

Thanks for the info. Very informative reply. Sounds like the network handling stuff should be in the C layer. And pass the parsed message/objects back to Lua is the way to go.

Re: Why Lua?

#106

Post by ww520 »

marshray wrote: post #76
ww520 wrote: 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?

I'll spare you the exact results of my recent web search, but my impression is that it seems to be a rapidly developing area. There are definitely some good libraries out there of varying scope and maturity. Lua seems to be such a good fit for this paradigm that I would bet the community is going to produce some outstanding frameworks. (Was kicking around the idea of implementing something myself.)

It would be interesting to monitor. Lua is a good fit for async programs with its coroutine support.

Re: Why Lua?

#107

Post by [deleted] »

ww520 wrote: post #105
silentbicycle wrote: post #96

Earlier quoted context omitted.

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…

Thanks for the info. Very informative reply. Sounds like the network handling stuff should be in the C layer. And pass the parsed message/objects back to Lua is the way to go.

[deleted]

Re: Why Lua?

#108

Post by peterbotond »

simon wrote: 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…

not often mentioned: tcl's slave interpreter, and command redirections from a slave interpreter to its master. a master interpreter can hold many slaves interps, and any slave can be a safe interpreter not execing anything that might be dangerous. redirecting, by renaming, a slave/safe interps commands the master will know. tcl's threading model (if needed): sending messages, one thread per interpreter, and one thread can have multiple interpreters. tcl-8.6 has a killer object model. tcl's vfs, and starkit/metakit makes distribution simpler.

what i do not use tcl for is: web. unfortunate lack of a framework.

it has good support for downloading stuff, ftp, http, bignums and algorithms if needed.

Re: Why Lua?

#109

Post by forrestthewoods »

If you want fast Lua I'd recommend checking out Havok Script (http://havok.com/products/script). Technically it's not Lua, but rather an extremely fast virtual machine that is compatible with Lua. I worked with it when it was Kore prior to Havok's acquisition, but it was substantially faster than the base Lua. It has some excellent debugging functionality as well.

No idea what it costs these days, but if you're writing Lua code and it's need to be fast I'd recommend checking it out.

Re: Why Lua?

#110

Post by silentbicycle »

sshumaker wrote: post #36
hythloday wrote: post #22

Earlier quoted context omitted.

Could you explain what you can accomplish with Lua metatables that you can't do with python __eg__ methods? I've only seen them used as a way to implement operator overloading.

__index and __newindex are the key ones - effectively equivalent to method_missing in Ruby. __index gets called if you try to read a non-existent key, and __newindex gets called if you try to write to a non-existing key. You can use these methods to implement inheritance, proxies, getters/setters, all sorts of stuff.

Yes, but in Python, you set them on every object. In Lua, you can set them once (in a prototype) and have each table share them (and possibly other methods, or a reference to another when lookup fails there). This makes certain behaviors (e.g. implementing your on object system) cheap and straightforward that would be impractical in Python.

Imagine if each Python object had one field that stored all the __blah hooks, and objects could share those. It's actually more powerful than that, but it's a good start.

Post reply on HN