An honest question: for which use cases is Lua strictly better than Lisp?

silentbicycle · on June 17, 2012

Lua is designed specifically to provide a scripting/extension language for projects in C or C++, or projects where interop with C is key. This is where it really shines -- where most Lisps expect to be the primary language, but have FFIs to C for performance and integration reasons, Lua expects to be used for writing plugins, configuration, and the like. It handles those tasks well, and otherwise stays out of the way.

While it's good as a standalone language, it's an outstanding extension language. It's small, trivially portable, and has excellent interop with C. It's not competition for Lisp in general so much as Emacs Lisp or vimscript, designed for systems that have a core written in C but need a lot of customization layered on top. Configuration for window managers, scripting enemy behavior for game engines written in brutally optimized C++, that kind of thing. Systems with a "hard and soft layer" architecture (http://c2.com/cgi/wiki?AlternateHardAndSoftLayers). (Incidentally, Tcl was also designed with this use case in mind.)

That said, if you're using Lua as your primary language but are proficient in C, you can add a lot of power to it pretty easily. The emphasis on C interop goes both ways. (Also, the implementation is very intelligently engineered, and is worth study if you're interested in language design or virtual machines.)

pka · on June 17, 2012

Thanks for the comprehensive reply; however, a quick search turned up a couple of small, portable and embeddable Lisp dialects (Hedgehog, PicoLisp, ECL) that all seem to target the same niche Lua is apparently designed for. Admittedly, Lua has probably been developed for a longer period of time, but small Lisp interpreters shouldn't be very complex, so I guess they are pretty stable.

Lua is probably going to be faster, but one wouldn't exactly use a scripting language for math heavy stuff etc either.

silentbicycle · on June 18, 2012

Lua has had a long time to slowly and deliberately evolve, informed by feedback from a gradually growing group of users.

It's kind of the opposite of Javascript, which went from 0 to release in a few weeks and had a bunch of design errors become permanent as a result. Lua and Javascript have a lot in common, and studying Lua may be a good way to see where Javascript is going in the long term.

Lua is significantly smaller than ECL, and a bit smaller than PicoLisp. According to sloccount, they weigh in at 432,818 (ECL), 15,018 (PicoLisp), and 14,309 (Lua).

haberman · on June 17, 2012

Lua has the following advantages over Lisp-the-language:

  - only one dialect (sometimes changes between major versions,
    but there aren't multiple dialects evolving in parallel).

  - infix notation is preferred by many programmers, and is easier
    to use for non-programmers.

  - the language is small (more like Scheme than Lisp)

The Lua and LuaJIT implementations have the following advantages over SBCL (you didn't say which Lisp, so I'm just picking what seems to be the most popular one):

  - extremely portable
  - extremely small
  - easy to sandbox
  - very good integration with existing C and C++

liljimmytables · on June 17, 2012

A personal opinion: Lua comes close to having a predictable control flow, as more program structure stuff is built in to the language. One of the headaches I had with Tcl was maintaining heaps of scripts that implemented structural features (OO, object references, list comprehensions, to name a few that come to mind) in different ways _because you can_. Doing things the elegant way can sometimes be the enemy of doing things the predictable way.

This is strictly a limitation of languages like Lua, but in day-to-day use it sometimes becomes an advantage.