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

121–130 of 142 posts

Re: Why Lua?

#121

Post by Confusion »

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.

Ruby: RubyMine Javascript: integration in IntelliJ IDEA was always very good

Re: Why Lua?

#122

Post by loup-vaillant »

groby_b wrote: post #114
loup-vaillant wrote: post #25

Earlier quoted context omitted.

The simplicity of any code is really underrated. Like 4 orders of magnitude underrated: http://www.vpri.org/html/work/ifnct.htm (Long story short: a typical mainstream desktop weights more than 200 millions lines of code. The guys at the Viewpoint Research Institute can simplify it down to 20.000 lines.)

"We have a technique to reduce the complexity by four orders of magnitude, but unfortunately can't even give a summary of that technique here". I reserve judgment till I see an actual proof of that.

The proof is not far. See their last report here: http://www.vpri.org/pdf/tr2011004_steps11.pdf Also, a good deal of their code is accessible here: http://vpri.org/fonc_wiki/index.php/Installation_Guide

As far as I can tell, several things can explain how they fit a whole library in a single book (assuming 50 lines per page, 400 page books, 10.000 books in a library). First, the use of dedicated languages instead of C and C++ seems to explain 2 orders of magnitude. The 2 remaining ones are explained by feature creep and plain lack of reuse (in the Franck system for instance, they use a single library to draw everything, from characters in a word processor to the frames of the windows.)

They also claim specific achievements: a full self-implementing compilation stack in less than 2Kloc, on top of which implementing something like Javascript or Prolog takes less than 200 lines (see http://piumarta.com/software/maru for actual code). A Lex/Yacc equivalent in 400 lines or so (see http://www.tinlizzie.org/ometa/ for actual code). A Cairo equivalent that run with acceptable performance in about 500 lines. A TCP-IP stack in 160 lines, stable enough to run a web site.

If half of that is true, we can effectively talk about a silver bullet. That bullet won't kill the complexity werewolf of course, but it will seriously cripple it.

Re: Why Lua?

#123

Post by dagw »

Confusion wrote: post #121
esrauch wrote: post #66

Earlier quoted context omitted.

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

Ruby: RubyMine Javascript: integration in IntelliJ IDEA was always very good

There's also WebStorm which is the JavaScript/HTML/CSS specific IDE from Jetbrains.

Re: Why Lua?

#124

Post by chalst »

haberman wrote: post #14

The more I learn about Lua's design and implementation, the more impressed I am. It's very rare to see software that does so much with so little code. The design is extremely clean and the code is extremely fast. The C API is easy to use and gives good performance, and yet encapsulates enough of the VM's implementation that C modules are source and binary compatible with both Lua and LuaJIT, two very different implem…

Norman Ramsey's answer to an SO qn of mine is interesting

    http://stackoverflow.com/a/2102399/222815
Roberto provided a ref to the way Lua implements closures, which is certainly innovative.

One things I like about Lua is that it's TCB is small. This matters when you are embedding code.

Re: Why Lua?

#125

Post by antirez »

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…

I suggest you to use Tcl, and I think I'm not biased since for instance the Redis unit test is written in Tcl but I'm using Lua as scripting language for Redis.

But as a language, Tcl will allow you to experiment a completely different way of thinking. Lua is neat but not so different from what you already know.

Re: Why Lua?

#126

Post by hythloday »

ktr wrote: post #74
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…

Hey, thanks for the reply, I do see your point now--I thought you were referring to the usual case of importing modules. It's true that Python modules aren't implemented in terms of dicts or lists and that Python is a larger language than Lua, so I think I completely agree with the point you were making. :)

For future reference, I'd implement your dynamic module importer like this:

  def dynamic_import(name):
       import imp
       return imp.load_module(name, *import.find_module(name))

  os = dynamic_import("os")

Re: Why Lua?

#127

Post by zeen »

jballanc wrote: post #37
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…

To nitpick your nitpick: in Lua tables are the only composite data structure. Everything you listed is either atomic or opaque (you can hide composite datatypes in userdata, but you can't introspect the values). If you think about it, this is very similar to C where the only composite datatype is a struct (arrays are just sugar on pointer arithmetic). In fact, I think if you wanted to make a scriptable dialect of C,…

Well, since we are nitpicking nitpicks, allow me to nitpick your nitpick of a nitpick: Lua closures are also composite data structures. You can get/set their upvalues via the debug API. Behold:

  function create()
    local a,b,c,d,e,f,g,h,i,j;
    return function() print(a,b,c,d,e,f,g,h,i,j); end
  end
  function array_get(f, index)
    local k,v = debug.getupvalue(f, index);
    return v;
  end
  function array_set(f, index, value)
    debug.setupvalue(f, index, value);
  end
  function map_get(f, key)
    for i=1,math.huge do
      local k,v = debug.getupvalue(f, i);
      if k == key then return v; end
      if k == nil then return nil; end
    end
  end
  function map_set(f, key, value)
    for i=1,math.huge do
      local k,v = debug.getupvalue(f, i);
      if k == nil then return; end
      if k == key then
        debug.setupvalue(f, i, value);
        return;
      end
    end
  end
  
  function test()
    local f = create();
    array_set(f, 1, "one")
    assert(array_get(f, 1) == "one");
    map_set(f, "b", "something");
    assert(map_get(f, "b") == "something");
    print("Success!")
  end
  test();
If table creation was disallowed, you could use functions in place of tables. And you could repurpose an existing table as the function type's metatable, allowing syntax like func.x=func[y]

Oh, and coroutines probably also fall under composite data structures technically...

Re: Why Lua?

#128

Post by seclorum »

larubbio wrote: post #86
peregrine wrote: post #29

Earlier quoted context omitted.

Could you name a few, alls I see are kepler based ones..

I work at Zipline Games and we're building out a server side hosted lua system. We're targeting it at game developers, but there is nothing game specific about the lua handlers you can write. You can find out more about it at http://getmoai.com If you don't want a hosted solution you can look into mongrel2 and tir http://tir.mongrel2.org/

I just want to say: thank you for MOAI. It is an awesome way to get an app done for Android/iOS platforms simultaneously, and I really look forward to the future of this framework. Without question, it has been a very enjoyable experience - develop on Mac OSX, simultaneously deploy on both Android and iOS, and then ship. Really, a pure joy to use.

Re: Why Lua?

#129

Post by pygy_ »

fab13n wrote: post #30
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 an easy-to-use symbolic debugger. > * It lacks a first-rate IDE. This is changing http://eclipse.org/koneki/ldt/ ; > * Array indexes start at 1. This sounds dangerously similar to "I can't use Python because it has significant whitespaces". Developers might like or dislike it, but if you can't get over _that_, you either lack important cognitive abilities, or you're suffering from a very serious case of…

> * It lacks an easy-to-use symbolic debugger.

> * It lacks a first-rate IDE.

>> This is changing http://eclipse.org/koneki/ldt/ ;

This looks excellent, even for people who don't like Eclipse. Lua sorely lacks an interactive debugger, and your DBGp-based solution is portable beyond Eclipse.

Very nice :-)

Post reply on HN