

Why Metalua isn't Lisp - gnosis
http://metalua.blogspot.com/2007/05/metalua-isnt-lisp.html

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

(The article itself is from 2007.)

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

------
gnosis
Also see:

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

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

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

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

------
troels
> 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?

