LWN: Comments on "GNU Guile 2.0.0 released"

newLISP

roskegg — Wed, 18 Apr 2012 19:37:52 +0000

I said "does", not "has". True, newLISP, by design, lacks many of Guile's language features. But when it comes to buckling down and getting stuff done, newLISP does indeed "do" anything that Guile can do. Often much more simply.

Compilers? Who needs them. We have a linker that can create a "binary" blob that you can drop in place and run. Close enough.

Multi method dispatch? Our OO system (FOOP) does what we need it to. OO is an often over-used and overrated paradigm.

Hygeinic macros? They just tie you down. Yuck. First class and composable continuations? If you need them, you can implement them in a few lines of newLISP. Most people don't.

Full numeric tower? We use the Gnu GMP library when we need big numbers. Otherwise, we keep it close to the machine, just like C. floats and ints and chars. Saves cpu cycles, and let's me enjoy all the bit-banging fun I had back in my Assembly programming days.

Tail calls would be nice, but I really haven't missed them. The iteration primitives are well done, and tail calls can always be implemented with iteration, if speed turns out to be an issue.

GNU Guile 2.0.0 released

nix — Sat, 19 Feb 2011 23:09:54 +0000

Guile is clearly superior, in its underlying design, to all other scripting/extension languages in use.

That is very much a subject for (religious!) debate. It's good, certainly.

GNU Guile 2.0.0 released

ncm — Sat, 19 Feb 2011 19:32:59 +0000

Congratulations to all Guile participants. Better late than never! Guile is clearly superior, in its underlying design, to all other scripting/extension languages in use.

I commend the vision of the original Guile developer, Tom Lord, in recognizing Lisp's true nature as an excellent scripting-language design. Perhaps all Guile needs now is pool-based garbage collection, so it can ignore memory malloc'd by the C and C++ libraries it calls. (Or is that what Boehm-Demers-Weiser does?)

The Wikipedia page, http://en.wikipedia.org/wiki/GNU_Guile, deserves an update.

newLISP

mhw — Thu, 17 Feb 2011 23:28:29 +0000

And everything Guile does, newLISP does.

I will try to be polite, but this is an extremely ignorant statement. Guile has many features which newLISP lacks. To give just a few examples: modern hygienic macros, first-class continuations, composable continuations, an extensible compiler system allowing new languages to be added easily, a far more powerful object-oriented programming system with multi-method dispatch based on a real meta-object protocol, a full numeric tower including arbitrary-precision integers and exact rationals, proper support for tail calls without using stack space. And that's just what I could discover in about 5 minutes of research.

Now, I have nothing against newLISP. I'm sure it's well-suited to many tasks, but please don't make ignorant claims that it does everything that Guile does.

newLISP

roskegg — Thu, 17 Feb 2011 22:25:24 +0000

It is nice to see Guile still progressing. If only they had been this far along five years ago. For now, newLISP fits all my needs. It is like all the best bits of original LISP, Common Lisp, and Scheme, combined with bits from Rexx, Algol, SAIL, Perl, Python, and other languages, all packaged in a way that is intuitive to the Unix C programmer. I can't imagine LISP being any sweeter and Unixy than newLISP. And everything Guile does, newLISP does. And its garbage collection is faster, better, and consistent. Consistent enough for repeatable timing runs.

GNU Guile 2.0.0 released

nix — Thu, 17 Feb 2011 10:59:59 +0000

Even if you do that, V8 is still a lot slower than LuaJIT ;}

GNU Guile 2.0.0 released

elanthis — Thu, 17 Feb 2011 02:42:32 +0000

You need an awful lot more than a JIT to get comparable performance to V8 and the other modern JS engines.

GNU Guile 2.0.0 released

atai — Wed, 16 Feb 2011 22:48:33 +0000

Will be interesting to see how the Javascript performance goes using the Guile VM. Can an JIT be added to this to make it comparable performance wise with V8, and other Javascript engines, someday, on both x86 and ARM...