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

71–80 of 142 posts

Re: Why Lua?

#71

Post by ktr »

haberman wrote: post #59
whatajoke wrote: post #49

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…

> And guile offers all of this while supporting native threading with a single heap. What is Guile's synchronization model for shared-state multithreading? > Guile is available on n900. So there. This appears to be a Linux-based phone, so that's not very surprising or impressive. Lua is straight ANSI C and can compile on much more limited systems than a Linux-based smartphone. One other data point: Guile is 5x the si…

> One other data point: Guile is 5x the size of Lua, in both source and binary forms.

This. We were considering using Guile before we ended up going with Lua and this was actually a big factor for us.

Re: Why Lua?

#72

Post by meric »

hythloday wrote: post #22
meric wrote: post #8

In lua, the metatable is the killer feature that python doesn't have.

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.

In addition to everything a python class can do, you can also use setmetatable() to modify the metatable of a table at runtime. A metatable is also just a table so you don't have to assign it to designated "metatables". You can for example even set the metatable of a table to itself.

The metatable is more general and conceptually simpler. It doesn't have to be the "class" of an "object", it can implement other patterns to OO without feeling weird, because the assumption that metatable is "Object Oriented" just isn't there.

Do you have python beginners touching metaclasses? I doubt it. Do you have lua beginners touching metatables? Certainly yes.

Re: Why Lua?

#73

Post by ktr »

groovy2shoes wrote: post #4

Good article, but one nitpick: not everything in Lua is a table. Tables are a versatile data structure that can be used as arrays, dictionaries, objects, etc. However, Lua provides many types besides tables: numbers, booleans, closures (functions), strings (which are interned), coroutines, and something called userdata (which are typically pointers to something implemented in C). Another cool thing about Lua, which w…

Good point. I was thinking (as jballanc sort of mentioned) of this with regards to composite types. E.g., there is no difference between lists versus hashes versus tuples versus objects, etc. But duly noted for any revised edition :)

Re: Why Lua?

#74

Post by ktr »

hythloday wrote: post #3

I love Lua, but when I read statements like this: >>> In Python, you might __import__('...')' some module and then the variables of the return value would be accessed like vars(module) it makes me wonder if the author is just unfamiliar with Python (and by extension, any language other than Lua) or if they're deliberately misrepresenting other languages to make Lua look good (which it definitely doesn't need).

Sorry, I would actually consider myself quite proficient in Python. What I was trying to [unsuccessfully] show was that the underlying mechanics of Python's import mechanism are different then, say, Python's dict or list implementations. Whereas in Lua everything really is just a table. I ran into this (in Python) when I was trying to dynamically import code based on command line arguments and access the functions in said script as strings. So in Lua, you just `x = require"script" ; x["fn"]` whereas in Python you sort of need to know this information up front unless you go through the machinations I outlined in the article.

But this was obviously a poorly written part of the article that could use improvement.

[EDIT] typos [EDIT2] less arrogance :)

Re: Why Lua?

#75

Post by marshray »

esrauch wrote: post #66
marshray wrote: post #19

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 first-rate IDE That is an interesting claim. What are the first rate IDEs for Javascript, Python, Ruby or C++? That isn't a rhetorical question I mean vim, emacs, textmate all seem equally good for Javascript and Lua. I know people use Eclipse for Javascript but it hardly seems like a killer integration.

Something like Xcode, Codeblocks, MS Visual Studio, Eclipse, Komodo, or Python IDLE.

Re: Why Lua?

#76

Post by marshray »

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

Re: Why Lua?

#77

Post by dustingetz »

whatajoke wrote: post #49

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

Rich Hickey: "Functional has been applied, you know, for a whole spectrum of things. I think there’s the haskell meaning of functional, which is sort of, the pure notion of function applied to absolutely everything in the language. And then there’s another notion of functional... lisps claimed to be functional early on, only for the simple reason that functions were first class objects or values that you can pass around. Those are the two ends. Somewhere in the middle, i think, is a style of programming that emphasizes programming with pure functions, in other words functions that are free of side effects, that operate only upon their arguments, which are values, and that only produce values as results. So that’s a pure function. Clojure emphasizes the style of programming using pure functions, where lisps, traditionally, have not. You could do it, but it was a choice. The key thing in forcing you to make that choice, is to have the core data structures be immutable, so they now can be treated as values, in a way that mutable things cannot. So Clojure emphasizes functional programming, by providing a set of immutable core data structures, including those ones that you use to represent code. They’re also persistent, which is a special characteristic we could talk about. Because of that, it encourages the functional style of programming, because you cannot change [the core data structures], so you have to write a function that produces a new value as a result. but there’s no enforcement. if you write a function and that does IO, well that’s not a pure function anymore, and I don’t preclude it, and there’s no type system to preclude it, its a dynamically typed language, which just respects the programmer’s right to do whatever they please." [1]

[1] https://docs.google.com/document/pub?id=1Vgbw3hGCye2rtmnZ6iS...

Re: Why Lua?

#78

Post by eridius »

batista wrote: post #67
sshumaker wrote: post #55

Earlier quoted context omitted.

Yes, but you use it to interface with native code. Normally, you'd write Lua_Cfunctions to achieve the same behavior - and those can crash your app just as easily, since they're native code. Perhaps more so, since it's easy to screw up the stack manipulation.

OK, native code can crash. Not much of a problem. He have been running servers written in C/C++ since the ancient times for more critical tasks than your average Lua program. From Apache to Nginx and from Qmail to MySQL to MongoDB. So what if a Lua program has the "potential" to crash if you interface with C? You do the interfacing because there is a need to do it, anyway. It's not like you go FFI for fun.

haberman's argument is making an assumption that perhaps you aren't. Namely, one of the benefits of Lua is that, barring behavior introduced by C extensions (and bugs in the Lua interpreter), it can't really harm your program. It can't crash or do anything else. It can suck up resources, but that's about it. As such, with whatever sandboxing you feel is appropriate, you can run arbitrary Lua code without worrying (e.g. World of Warcraft can run third-party addons). But with LuaJIT's FFI interface, it appears (note: I have never used LuaJIT or its FFI interface) that you can no longer trust arbitrary Lua because it can reach into your program and call whatever function it feels like, including the ability to crash you at random, or do other things that it's not supposed to be able to do. You can no longer just trust Lua code to not impact the rest of your program.

Re: Why Lua?

#79

Post by bch »

groovy2shoes wrote: post #60
bch wrote: post #21

Earlier quoted context omitted.

Tcl has lambdas (anonymous functions): http://wiki.tcl.tk/4884 . As of 8.6 (currently in beta), it also has coroutines, and has a non-recursive engine (stackless) among other niceties.

Shows how long it's been since I last used Tcl! Still, Tcl's anonymous functions aren't quite what many people consider to be lambdas: % set inc {x {expr $x + 1}} % apply $inc 1 2 % apply $inc 1 2 % $inc 1 invalid command name "x {expr $x + 1}" % inc 1 1 This works fine with `apply`, but if you treat it like a normal function, it does some strange things. Conversely, functions that are defined with `proc` aren't comp…

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". [incr] adds (by default) 1 to the named variable and returns its result. In this case, the variable name happens to be "1", later accessible via "$1", or [set 1], for example.

[edit: I erroneously initially described the "1" in [incr 1] as the integer constant 1; @groovy2shoes reply below reflects my original error. This does go to show another neat feature of Tcl: no keywords.]

Re: Why Lua?

#80

Post by mhd »

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…

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 etc.), you're actually more likely to find working Lua "Rocks" than tcl modules.

jim: http://jim.tcl.tk/

Post reply on HN