

The first rule of Lua - Adrock
http://www.goplexian.com/2010/02/first-rule-of-lua.html

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

------
kqr2
Posted previously:

<http://news.ycombinator.com/item?id=1130389>

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

~~~
jamesbritt
"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.

~~~
beagle3
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)

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

~~~
beagle3
(sorry for taking so long to reply)

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

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

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

~~~
silentbicycle
Again, thanks.

------
rufius
Don't talk about Lua!

