Its certainly useable - usually on par with Python... But picolisp, Gambit, SBCL are more on par with D or Rebol.
So when newLISP claims to be great for embedding, I feel cautious.
Its certainly useable - usually on par with Python... But picolisp, Gambit, SBCL are more on par with D or Rebol.
So when newLISP claims to be great for embedding, I feel cautious.
Gambit internals does kind of look like black magic half the time, but the author implemented environments because I asked [0], which is very cool.
The more experimental lisps, the better we can make the future. I love how the lispish community views PLT, and always tries out someone's new idea. (Bayes integration in newLISP is cool. LFE is also cool.)
Xtlang in Extempore is a whole lot of fun [1].
Echolisp has amazing built-ins and runs in the browser [2].
Gambit is great to get C code out of.
I like LFE, but I have to learn more OTP/BEAM to really use it.
Wasp Lisp is a lot of fun for me, and for playing with distributed programs.
They're functions whose args are passed unevaled.
It kills a whole variety of compiler optimizations, but in an interpreter, there's no reason not to have them.
The reason for that lies in the fact that newLISP's interpreter does not have to do that much of pointer chasing as other interpreters which implement some kind of lexical scoping. In dfsch I found out that about 80% of time is spent in symbol-lookup related code and had to resort to some ugly tricks (inlining constant references in AST, microoptimalizations in lookup code...) to get it's performance to be somewhere between CPython and newLISP.
Python is a magnitude of order slower [1] than most things, and that was my point. newLISP is slow.
I do have to take exception to you calling interpreted slow - because you've called Python interpreted, I'm guessing bytecode interpreted fits your view. Picrin [2] is bytecode interpreted, and isn't slow. [3]
By Rebol I mostly meant Red, which isn't exactly slow, as it aims for 1-3x the speed of C. (Though I can't find any decent set of benchmarks for it currently).
[0] https://benchmarksgame.alioth.debian.org/u64q/lisp.html
[1] http://benchmarksgame.alioth.debian.org/u64q/python.html
Those measurements seem to show Picrin at-least an order of magnitude slower than Larceny?
Doesn't mean Picrin is slow, though. It matches Chicken in most of the stats, and Chicken uses the same process (Cheney on the MTA), but Chicken is compiled. Picrin is bytecode interpreted.