Why Metalua isn't Lisp | Hacker News Reader

Why Metalua isn't Lisp

metalua.blogspot.com

21 pointsgnosis9 comments

Sadly, no commit in almost a year: http://github.com/fab13n/metalua

(The article itself is from 2007.)

I moved on to an interesting job about a year ago, and there's only so much meaningful code you can write in a day...

I'm still working on metalua, but there are few things which are worth being published yet. Promising works in progress include:

- friendlier syntax to write grammar extensions (current grammars are too verbose, AST builders are ugly and barely readable)

- a library of "for ... in" generators, to walk through ASTs in a nicer, more lua-like way than with the current metalua.walk library. This should eventually become generic enough to become an interesting XML / JSON / whatever-kind-of-tree tool

- integration with LuaEclipse, and generally speaking, more focus on metalua as a way to manipulate / refactor plain Lua programs, rather than as an independent language.

Also see:

http://lua-users.org/lists/lua-l/2008-02/msg00247.html

Lua has its own corresponding social quirk: Its designers and community are extremely careful about adding anything to the language that wouldn't be trivially portable or would force any choices when running embedded inside another language/project. Consequently, there are several slightly different threading libraries, several slightly different bignum libraries, etc.

On the balance, I'm quite happy with the trade-off (it's strong pressure to keep Lua small, clean, and portable), but it makes using Lua standalone a bit weird. Particularly if you expect it to have "batteries included" like Python. It's very powerful combined with C, though, whichever is the primary language.

Also, the LuaRocks (http://luarocks.org/) project is growing a central, CPAN-ish module repository, which helps.

I love Lua, but trying to make it work standalone is working against its design goals --kinda like trying to use Javascript standalone. I push anyone with such ideas to really, really think about using Python instead.

I mostly agree with you, but don't overlook Lua+C with Lua driving. (I edited my comment a bit to make this clearer.) If you don't know C, Python's probably a better choice.

Granted, core language designers are very careful about what they add; but I don't think it is the main cause of the issue you mention (proliferation of incomplete and incompatible variants of useful libraries). De facto standards could have emerged wihtout PUC's blessings, and sometimes they do: luasocket comes to mind.

It seems to me that the main social reason is a love for poor, partial and repetitive wheel re-invention. People come and reinvent yet another OO framework, OS threading interface, preprocessor, bit shuffling lib, functional table handling lib, etc. again and again, instead of focusing their efforts on a couple of most promising candidates. Java, for instance, doesn't have this issue.

Why is it so? I'd guess:

- there's no std lib: therefore you look slightly less foolish trying to write a half-assed std lib for Lua than for Java or Python. For this reason Lua is probably doomed to consistently attract wheel re-inventors.

- the language is too fun for its own good, with all of its meta-mechanisms. You can have a lot of fun writing a bad library, much more than in Java or in Python. Java is dull, so people communalize their boilerplate; Python has an opinionated dictator, and a culture that frowns upon gratuitous reimplementations.

- Lua's canonical use-case is to provide logical glue around a C library. This means that "serious" Lua users don't need standardized libraries, and such wannabe-standard libs are therefore mostly written by "non-serious" Lua hackers.

I'm not sure that Lua presents enough advantages, compared to Python, to develop a high-quality "batteries included" libraries set. Python is good enough to prevent replacements from being completed, just as Emacs, or LaTeX, or Windows as a mainstream desktop OS, are good enough to prevent direct competitors from emerging.

There's an attempt to write a complete replacement for the OCaml standard library, actually. I know I'm not the only person who finds that deeply weird.

I think you're absolutely right about Python (and Emacs, etc.) being good enough to prevent many serious competitors.

> Finally, in the algol+macro category, the case of Dylan has to be mentioned. I have a bad feeling about this language, but I can't spot why exactly. That would be worth a separate post.

Actually .. what exactly is the problem with Dylan?

Reply on news.ycombinator.com