[FoRK] Python, Re: The collapse of the .net ecosystem
sean at conman.org
Sun Jun 21 13:57:45 PDT 2015
It was thus said that the Great Stephen D. Williams once stated:
> Python is now the go to language for learning to program. Like Java,
> Visual Basic, etc. before, this is going to boost it. With great
> libraries, and easy ways to integrate C++ into it to create scripting for
> powerful C++ code, and the ability to be embedded easily (which Java fails
> at) while being better than a toy language (Lua), it is going to go strong
> for a while.
I'm curious as to why you consider Lua a toy langauge. It too, is easy to
embed (one of the main features, infact), has true tail-call optimization
, has coroutines , closures, first class functions, etc. And while
Lua isn't thread-safe (that is, two threads can't use a single Lua instance
, you can easily give each thread its own instance of Lua .
And least of all, while the stock Lua interpreter is one of the fastest,
it's not the fastest Lua interpreter---that goes to LuaJIT, an almost
seamless replacement  of stock Lua which can get you very close to C
speed, if not C speed entirely (I suspect for math-heavy code). Also,
LuaJIT has a seamless FFI module that makes it even easier to call to C than
the stock Lua API interface to C.
About the only lack Lua has is an extensive standard library which I can
see as being a showstopper. But I, among others , don't consider Lua a
toy language (heck, I'm using it at work to process SIP messages ).
-spc (It's even been embedded in the NetBSD kernel ... )
 Somethign that Guido absolutely refuses to add, becaues "it would
make debugging harder." Sorry, don't buy that one. Also, tail-call
optimizations make writing state machines much nicer.
 While not true threads, they do make writing asynchronous, event
driven code much nicer than the call-back hell you get in
 Technically, you can, if you recompile Lua and define an
implementation for the functions lua_lock() and lua_unlock(), but
then, you've just added the big GIL to Lua, something that Phython
users have been wanting to remove for *years* if I understand
 The entire interpreter context is stored in a single structure, and
because of this, Lua *is* re-entrant.
 If you are using stock Lua 5.1, then it's seamless. If you are
using Lua 5.2, then it's somewhat seamless, kind of. If you are
using Lua 5.3, then you probably can't use LuaJIT at all.
Unfortuantely, the author of LuaJIT doesn't care for some of the
changes in Lua 5.2 and Lua 5.3 so the two implementations are slowly
 Which mostly deals with parsing, and for that, I use LPeg, a
Lua-based parser expression grammer. It compiles to its own VM (a
parsing-specific VM in fact) and because it's just expressions, you
can compose gammars as needed. It's quite nice.
More information about the FoRK