[FoRK] Python, Re: The collapse of the .net ecosystem
Stephen D. Williams
sdw at lig.net
Sun Jun 21 15:44:19 PDT 2015
On 6/21/15 1:57 PM, Sean Conner wrote:
> 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 .
I'm foggy right this minute about the full set of things I have against it; I think I'd have to look at the language and
implementation / integration library to remind myself of the details.
The main remaining reason to use Lua in my ruleset is if you want to embed an interpreter that is very small and that is widely used
and documented. I remember something about the interpreter being as little as 11K or something. If you aren't constrained that
In the last instance where this came up for me, we wanted to be able to script complex C++ libraries on Android and desktop/server,
plus be able to script Java that used that C++ and/or script that C++ that was in a Java context (Android). We decided on Lua, got
started, and I found that none of the Lua->C++ generators really worked, were complete in any sense, or were worth the headache. I
was stuck in Lua versioning hell where some of the generators no longer worked with modern versions of Lua or Lua libraries. We
hand-coded for a bit, which worked but wasn't predictable or efficient.
I ended up going back to my JavaGlue (which I had initially avoided for fear of being provincial, and being curious about Lua) for
(Jython et al), and every other language available on top of Java. For our purposes, Lua was a broken, incomplete mess by
comparison. Now, it just happens that I'm the expert on JavaGlue (because it's mine), and I could fix and extend it (which I did),
and make it easy to integrate into a CMake or command line or Make build (which I did). There's only one notable hole, which seems
reasonable to me: A C++ function that uses a reference to an enum as an out parameter (i.e. called code wants to populate it) has
quite a gap to bridge when called from Java were enumerators are quite different. I conceived of a way to make it work, but it's
not easy to add and is likely to break other things for a few iterations.
This is still good to start with, although I need to update it:
This is pretty much the current code:
For a simple C++ class, you do this to generate / compile:
$(jg)/javaglue app jg $(jghome)/build $(jghome)/ignore_list.xml $(jghome)/examples/example/*
$(jg)/javaglue.compile app $(jghome)/build
Then do this to exercise the C++ code through Java:
$(jg)/jggroovy $(jghome)/build -e 'import org.javaglue.*; t = new org.javaglue.Test();'
$(jg)/jggroovy $(jghome)/build -e 't = new org.javaglue.Test(); print(t); t.setString("Hi"); p = t.getCString(); s =
#; print(t); t.setString("Hi"); p = t.getCString(); s = t.toString(p); print(s);'
$(jg)/jgjs $(jghome)/build -e 't = new org.javaglue.Test(); print(t); t.setString("Hi"); p = t.getCString(); s = t.toString(p);
$(jg)/jgjs $(jghome)/build examples/example/test.js
Can't put multiple statements on one line in Python, so I won't show the Jython version. ;-)
Does anyone care about Java->C++ autogenerated code? I should publish it more clearly, maybe write a book for it.
> 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.
I see his point, but it could be switchable when not in debug mode.
>  While not true threads, they do make writing asynchronous, event
> driven code much nicer than the call-back hell you get in
I learned to scale things in IO event processing, callback based systems (NCR Retail, AOL), so it seems natural to me. ;-)
>  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
Ughh. Not what you want to hear about a language.
>  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.
That sounds cool.
>  http://lua-users.org/wiki/LuaUses
More information about the FoRK