Hacker News Reader

Comment by haberman | Hacker News Reader

A programming language runtime is a whole package; just because some elements of previous system designs are reused does not mean that we are "reinventing the wheel."

To pick Lua (my favorite of the technologies you listed), it has the following things that Tcl does not have:

  - strict ANSI C implementation
  - small implementation (15k sloc vs. 110k-160k for Tcl, depending on how you count)
  - a fast implementation, with an even faster JIT

If you follow your argument to its logical conclusion then everything is just a reinvention of Lisp (including Tcl). But we have tools available to us today (like Lua) that are strictly better than Lisp or Tcl for some use cases.

View on HN

From the article: Use Lua for scripting. Use Tcl for command line interaction.

He has a point there. Lua is nice enough to write, but it is `func(arg, 'strarg')` where Tcl is appearantly `func $arg arg`. If I have to type that into an interactive prompt 200 times, I'd take the latter. If I want to write some complex program, I'd take the former. In other words, Tcl is optimized for writing, Lua is optimized for reading.

And following the argument deeper, Lisp is just an implementation of lambda calculus.

No, it's not. It started off that way, but a modern lisp is rather far away from "just an implementation of the lambda calculus". Named functions, for one, are a significant departure.

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

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

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

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.

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

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.

From that list of languages, how does Lua / LuaJIT performance compare, generally speaking?

Reply on news.ycombinator.com