As someone who values simplicity, minimalism, portability, and good performance, Lua is a constant source of inspiration to me. I frequently look at its design for ideas.
1) Lua takes a page from the Scheme book in that the authors try to give a very minimal yet very extensible core -- they don't give you tons of features, but they try to give you the baseline constructs you need to build other features. It's easy, as it is in Scheme, to do procedural, object-oriented, and functional programming in Lua (and even mix them).
2) Lua syntax can be pretty (although I've found that it doesn't lend itself well to embedded DSLs).
3) Lua is distributed as a very small library with an intuitive (at least for me, YMMV) C API, which makes it trivial to embed.
4) The Lua VM is more performant than Python, Ruby, Perl, PHP, and Tcl (although you get far fewer libraries; no batteries included). There's also the LuaJIT implementation, which is the fastest dynamic language implementation I know of (and it's fully compatible with the stock C API).
5) Lua is straightforward to learn (at least as straightforward as Python or QBasic), yet has a lot to offer the more knowledgeable programmer.
6) The documentation is detailed, specific, and concise.
All of these points make Lua an excellent language for embedding into applications (which is what it was originally designed for), but it's not often an excellent choice for general-purpose programming or even general-purpose scripting. Point 1 is a double-edged sword, just like it is in Scheme: you often end up with many different object systems, module systems, etc. in different codebases which can be painful for interop. I hear that this is also a painpoint for Tcl.
It seems to me the outstanding feature of Lua's design history is its designers' determination to make the core ever simpler and more general. That takes vision and courage over a long period of time. What emerged is truly interesting and inspiring (much more so than cobbled languages that grow only by accretion of features) and is likely to grow in importance.
Yes, that is very much how I feel about it. They boil every concept down into its purest essence, and always avoid having two abstractions when one will do. Other languages grow when they need new features, Lua refines.
But in a blog entry I'd like to address several of Lua's core abstractions and how they are cleaner and more general than competing languages. For example, the Lua thread data structure encapsulates all necessary state for a thread, but is general enough that it actually allows for multiple thread execution models. By default only coroutines are provided (which use the thread data structure). But you can implement lua_lock()/lua_unlock() to have a Python-like model with preemptive threads and a GIL. Or you can use lua_sethook() to implement a "green thread" model where multiple pre-emptive Lua threads run inside a single OS thread.
Three options for threading models (probably more if you dig in), one core abstraction and implementation. Remarkable!
I wonder what examples one could dream up where manipulating that thread data structure in an application-specific way would be a win. i.e. some kind of domain-specific threading model.
Manipulating the thread data structure directly would violate the encapsulation of Lua and prevent you from being portable to eg. LuaJIT. But there are still lots of opportunities for building custom threading models; see:
