The reason Lua has a small standard library is because making it substantially larger would undercut one of its major strengths. (Look at the difficulties people have with embedding Python.)
There are quite a few semi-standard libraries (such as LPEG, LuaSocket, LuaDoc, lfs, Lanes, etc.), but they can evolve outside of the core language. It's always easier to add libraries than remove libraries people assume you have.
If you want a "batteries-included" setup, there's Lua for Windows (http://luaforwindows.luaforge.net/), LuaRocks (to automatically install packages), etc. I'm going to post several new/updated OpenBSD ports related to Lua once the ports tree is out of lock for release, too.
Lua seemed very 'correctness over convenience' to me, similar to the mzscheme or haskell mindset, and I just can't get enthusiastic about language/communities like that.
"Lua seemed very 'correctness over convenience' to me, similar to the mzscheme or haskell mindset, and I just can't get enthusiastic about language/communities like that."
Interesting. The notion of correctness, that there are a set of core properties for a language that are always true, is appealing to me. It's one of the things I like about Haskell[0]. I'd much rather be able to deduce some property or behavior from a set of principles than have to memorize a set of one-offs and special cases.
In fact, that "correctness" ends up being a major convenience, especially when compared to languages that follow the idea of "These are the rules, except when they aren't".
[0] To the extent I know Haskell. It may well be that, as with many languages, this purity is put aside for certain pragmatisms. But what seems to be an effort to keep things consistent is a win for me.
You'll love K / Q (unfortunately, not open source -- but you can download a copy from the kx developer site). You have to know 20 orthogonal functions/concepts, and everything else combines from there; There's no standard library to speak off, because there is hardly a need for one; Most "library functions" in other language are idiomatic expressions in K which are shorter than the name of the function they describe: +/ is "sum" (left fold +), (+/x)%#x is average (sum of x divided by length of x). maximum running sum is |/0(0|+)\
No magic; All semantics derived from very basic blocks.
(not affiliated with Kx in any way -- just like the idea)
Are you familiar at all with J? I've done some of the labs, and I'm getting fascinated with it. J and K are closely related, I'm wondering if someone more familiar with both could compare them.
Yes, I'm familiar with J, and it is indeed closely related to K -- J was inspired, and in many ways evolved from A - an APL interpreter written by Arthur Whitney in one afternoon (see http://www.nsl.com/papers/origins.htm for more details).
J tries to be complete and nice in the mathematical sense, e.g. having forks and trains, and functional inverses, as part of the language.
K tries to be the simple practical language, rather than the philosophically consistent one: e.g. like APL and J, it is left-of-right long-right-scope, meaning 1+2+3+4+5 parses 1+(2+(3+(4+5))). However, the fold/over operator associates left - thus, +/ 1 2 3 4 5 actually computes (((1+2)+3)+4)+5 which seems inconsistent but is much more useful in practice.
K (conceptually) has 3 data classes: atom (int, float, char, symbol), list (data indexed by sequential integers) and dict (data indexed by data -- an associative array); Everything else is an implementation detail (and these matter -- they make K blindingly fast -- but you can ignore them when trying to grok k). Multidimensional arrays are implemented as "list-of-lists" or "list-of-lists-of-lists ...." etc. (thus no "boxing" is needed).
All list/dict access is done by indexing. Compress/expand are replaced by the "where" function which converts a list of booleans to their indices -- e.g. to zero all elements less than 3 you can do:
x[where x<3]:0 / use : for assignment
K has a much simpler base (which is surprisingly sufficient in practice), and the symbols make more sense to me. YMMV
Thanks, that's helpful. J and K do some sort of cache-friendly dataflow analysis (not just lazy evaluation), yes?
I've seen that draft J interpreter before - It crashes immediately now, but I spent most of a Saturday morning with GDB picking it apart. That convinced me there's deep ideas there, not just a brainfuck-ish obfuscated thing.
Actually, they don't. They just have cache-friendly primitives, and a compact interpreter that mostly sits within the i-cache of modern processors.
It makes a world of a difference -- staying in the i-cache and doing mostly sequential access is easily 10 times faster than random, non-i-cache-friendly access.
Can you explain what you mean by "connectness over convenience", here? I find Lua to be much less so than Python, which has heavy-handed ideas about what isn't "Pythonic". With Lua, the elements I suspect you're referring to are because the language is targeted at making embedding convienient - for example, there's no threading in the core language because concurrency decisions will probably be decided by the project Lua is running inside.
Also, the small and completely portable standard library keeps it small enough to trivially embed. One common response to wanting a batteries-included Lua to be standard is essentially, "If you want Python, you know where to find it." (There are such distributions, such as Lua for Windows (http://luaforwindows.luaforge.net/), they're just not the primary one.)
Maybe that explains it.
What I mean is things like Lua doesn't have a popen in its standard library that lets you both read and write to the subprocess, because there's a case where this can break (if what you're sending over the pipe is bigger than some internal buffer). Ruby and Python both let you do this, even with the potential for breakage, but Lua prefers correctness over convenience. A lot of the library calls in Lua seem closer than I'd prefer to the underlying C, because they don't want to provide abstractions over it that could break (even if the case where it breaks is something you'd never do). I guess this is because they don't know where it could end up getting embedded, but that kills it as an everyday scripting language for me.
There are quite a few semi-standard libraries (such as LPEG, LuaSocket, LuaDoc, lfs, Lanes, etc.), but they can evolve outside of the core language. It's always easier to add libraries than remove libraries people assume you have.
If you want a "batteries-included" setup, there's Lua for Windows (http://luaforwindows.luaforge.net/), LuaRocks (to automatically install packages), etc. I'm going to post several new/updated OpenBSD ports related to Lua once the ports tree is out of lock for release, too.