Guile is becoming really nice, and I find myself reaching for other lisps less and less.
Guile is becoming really nice, and I find myself reaching for other lisps less and less.
Meanwhile, implementations like SBCL are free, compile to machine code and are competitive on some benchmarks with C/C++.
Common Lisp — while it does have some warts — is intended for building long-lived, durable, full-featured systems. It's a really good language, and it standardises quite a lot. Often, what look like warts are actually useful features in large systems.
It really saddens me that so much effort has been expended trying to make Scheme a reasonable language for large systems, when there already exists one which is. That doesn't even get to the bits of Scheme which I believe are mistakes (e.g. a single namespace, making NIL, () & #f different).
I assure you, we look in envy at CL and what a standardised module system, portable networking and CFFI achieves. However, we still prefer scheme. Some of us actually like a single namespace, and don't mind the difference between false and nil (I have never really met a case where that distinction mattered much).
Are you familiar with the Blub Paradox[0]? I contend that the things you dislike about Common Lisp or don't mind about Scheme having or not having are precisely the things which make Lisp better for real-world systems.
My opinion — a professional, educated & considered opinion, but an opinion nonetheless — is that Scheme is simply not suitable for large-systems work, and that all attempts to take a Scheme core and make it suitable founder on the shoals of Greenspun's Tenth. The Scheme maintainers agree, because in R6RS they tried to build a more capable language. The Scheme community agrees, because it rebelled against R5RS, deeming a more capable Scheme an un-Scheme-like Scheme.
I like Scheme. It's a pretty, elegant language, with an exciting model. But the language as it exists simply isn't ready for systems work, and (due to its underlying philosophy) probably never will be. That's not a bad thing. Scheme is great for what it is. It's great for teaching; great for reasoning about computation; great for learning evaluators & compilers. But it isn't great for building systems like an OS, emacs, a distribution, a package manager, an init system or a window manager — and the effort spent working on making its inadequacies tolerable could instead be spent on implementing features in a more-than-adequate language.
Also, Lisp doesn't have portable networking. That's one of its warts (I did say it has them — and plenty of them! Lisp is not perfect!). It does have portable streams (and I think all implementations make sockets available as streams), but Scheme's ports are analogous.
Neither is CFFI standarised.
The only thing I really miss is conditions and restarts (which is a pretty big downside) and how integrated CLOS is (and the fact that LW pre-populates the CLOS caches is pretty neat!)
One of the flaws with this argument is insisting that comparisons be made between CL and standard Scheme. No one uses strictly standard Scheme. It's better to think of Scheme as a family of loosely connected languages. I know that both Guile and Racket are languages (and they are their own unique languages) capable of serious systems work. CL is great, too, but I don't know why you keep insisting that it's the only lisp worth using. The Guix developers have shown that Guile can be used successfully for the initial RAM disk, init system, package manager, configuration management system, continuous integration system, web site generator, etc.
Elisp code runs fine under guile, but it has seen virtually no optimisation work and does a lot of unnecessary work. I suspect there is an lot of low hanging fruit, but since there is virtually no interest in guile-emacs apart from in comments on HN and Reddit I doubt the situation will get much better.
The guile VM is getting better and better though. Maybe they'll come around by guile 4 :)
I have no idea how viable that is, but it would be pretty sweet. Too much for me to take on right now, but the idea has been rattling around my brain for a few years.
If you never used CML you should try it out.
The plan is to use the JIT as a first step to do AOT compilation to native code and thus come a bit closer to the speed of chez. Hopefully quite a bit closer.
This is what I have gathered from Andy Wingo's mailing list posts, so grains of salt for everyone!
ps: well I was wrong, it's wingo as usual https://news.ycombinator.com/item?id=18077710