1. SBCL, the most popular open source implementation of Lisp, is seeing potentially two new garbage collectors, one of which is merged and open to beta testing. One of them is a parallel collector written by a university student (!!) which blows my mind.
2. SBCL has better and better support for deploying Lisp as a C-compatible shared library, using SBCL-LIBRARIAN. It makes it play nicer with other applications in C and Python, without the baggage of process wrangling and thick RPC (IPC/servers, serialization, ...).
3. Coalton is another exciting development that allows a Haskell type system and "Lisp-1" functional programming in Common Lisp. That means type classes (or traits), something Lisp hasn't really had a proper notion of, and full type inference. Persistent sequences based off of RRB-trees were recently merged [1], and interestingly, they're implemented purely in Coalton [2]. That means Clojure-like seqs.
It's interesting to see users of Lisp generating the above ideas and libraries, not a special in-group of committees, "official" developers, etc.
[1] https://coalton-lang.github.io/reference/#seq-type
[2] https://github.com/coalton-lang/coalton/blob/main/library/se...
I didn't let schooling interfere with my education.
side note: only two years ago we were complaining about the lack of support for VSCode or the Jetbrains suite, now we have working plugins for them: https://lispcookbook.github.io/cl-cookbook/editor-support.ht... in addition of Emacs, Vim, Atom/Pulsar (very decent support), Jupyter notebooks, Sublime, Eclipse (simple support), Geany, enhanced terminal REPLs, Lem (multi-language editor built in CL)…
Don't get me wrong, it's a great start, and I hope it gets polished. But as of 3 months ago, it still doesn't work well, so much so I'd never actually recommend it seriously to someone who wants to learn Lisp.
Have you tried using VS Code (or any other editor you mentioned) for any "serious" full-cycle Lisp development before, and do you believe it passes the minimum bar of stable and recommendable to another professional programmer or enthusiastic hobbyist? Do I need to try again?
I wrote that support mostly over a weekend, and judging by the lack of bug reports, either my code is flawless (doubtful) or nobody uses it.
What I want — what I really really want — is an Allegro CL experience. Unfortunately, nothing provides it, nor does it look like anyone has any interest in providing such an experience.
This isn’t just a CL problem. Janky debugger integration is widespread. It’s the pathetic that only commercial developers provide a polished debugging experience. Everyone else is satisfied with a basically a CLI tool running separately in a window. That’s like. 80% solution. We can do better. We should do better.
Kudos to things like the cookbook tho !
The documentation culture is the one thing I miss from Perl when I go to... well, any other language. Considering CL has DESCRIBE it's really something we need to get serious about.
For a lot of the commonly used libraries, the doc is sufficiently decent, though sometimes unintuitive to find. For core stuff I like the hyperspec as much as the next lisper (and opening it on a symbol is just ,h for me) but there's also http://clqr.boundp.org/ that not everyone knows about, it's a great little reference to have printed out at my desk. And there's situations like how part of pretty much every Lisp, available through ASDF, is UIOP, a great little portability library. Its doc is at https://asdf.common-lisp.dev/uiop.html and it originates in the source repo from a Lisp script taking doc info from the source and applying a .texinfo template to it. Pretty bespoke. But this is also just part of the cost/benefit of CL: it's very unopinionated, unlike say Java or Clojure, and so lets individuals and teams do what they want which naturally isn't going to be the same worldwide. I like certain doc (especially at least one example of using the thing) in repo README files, others don't, nothing forces one way or the other.
Once the confidence for Lisp is there though, you're right that it's not a big deal. It's very nice to jump-to-source for everything, including SBCL internals, and modify things even. I can fix some bugs in a dependency library, right now, without having to file an issue/pull request to the library maintainer and waiting for a new release, and that modification can even live in my source tree in the interim as just a bit of code that runs after loading the main library and then redefines one of its functions or whatever.
I disagree that any effort needs to be made on attracting lone wolves, less even than trying to make editor support better for beginners; the loners will come on their own in time. Not because CL can only be used by loners (million+ lines of code projects made by teams demonstrate otherwise), but because it's a very good multiplier for that situation.
[0] - https://en.wikipedia.org/wiki/ML_(programming_language)
Clojure has also successfully spawned in the last years enough variants/tools/libraries/practice, ... , that it is now a diverse language family on its own.
Calling Clojure a Lisp triggers some people.
That is an amazing system, that even now, could probably hang with the best of them. :/
I joke that the parallel GC is bringing SBCL to 2000s Java. It seems comparable enough to Java's Parallel, though SBCL aims for less space overhead by default, so you need to adjust either GC to have a fair comparison. The concurrent one is based off a collector for SML#, Haskell has a similar low latency "Alligator" collector too.
(Disclaimer: I wrote the parallel collector, and I want to be clear that latency and throughput differ here, because someone didn't before.)
1. It is optimized for throughput over pause-times
2. It is non-parallel
Wait what?! When was the last time programmers chose a language because it was "green"? What does it even mean for a language to be "greener" than the others?
Yeah, in that case Assembly/C is the greenest language but should we switch to them?
> The inefficiencies from extra human time would likely offset any potential gains from the pennies you'd save on CPU costs.
I'm not sure I follow what you mean here.
As someone who is neither a Common Lisp nor a JVM programmer, I’m genuinely curious to hear from experts whether the old trope of “JVM is slow and bloated” is even remotely true any more. Based on hearsay, the JVM often competes in language performance closer to C++, and has probably the best garbage collectors in the world as well as the best developer and operational tooling. How much do other platform developers leave on the table by ignoring the JVM these days?
As an aside, even the trope about us running out of energy, or energy usage directly corresponding to planetary destruction is becoming less and less true. With solar PVs and the sun, we truly do have a shot at a future with limitless energy and resources.
I am mostly a Java developer, but have had the opportunity to play with Common Lisp and many other languages.
While it's true the JVM is very performant, its performance actually comes at a cost: it has a JIT, Garbage Collector, a whole lot of machinery for Threads/VirtualThreads, JMX etc. all of which comes at a cost... thanks to multicore processors and lots and lots of RAM being available, this translates in really fast performance for Java applications... so that cost may be advantageous to you.
Common Lisp applications are much lighter than Java applications from what I've actually measured given its simpler model... it basically compiles Lisp code to machine code directly and then runs that (Java runs bytecode, and then at runtime the JIT selects which code to optimise, which continues to happen for the lifetime of the application). I would bet money on any application written in Common Lisp being significantly lighter, and hence "greener", than the equivalent Java application, while still running at nearly the same speed, or even faster.
For short running programs, Common Lisp is incredibly fast at starting up and getting stuff done - it competes with C and Rust in that regard, not with Java.
> How much do other platform developers leave on the table by ignoring the JVM these days?
Common Lisp tooling is integrated into the language itself. You can inspect the machine code it generates, ask it to instrument every function so you can profile, and so on without even needing any external tools - it's all built-in... but of course, using it from SLIME or SLY (in emacs) makes it a lot more pleasant. If you think Java tools are better, I believe you may not know Common Lisp very well.
I don't think it's even close. Benchmark game is one (biased) reference. And it's even worse because optimized Java is not canonical Java. Canonical C++ is pretty fast.
It means more energy efficient.
May be we should, at least for some things. For code that runs a very large number of times the energy savings will add up. Data centres do use a lot of energy. So do client machines in aggregate.
The GUI situation of the free lisps is pretty much a non-started for anything portable, just curious if there's a project bundling Common Lisp with a browser window, like Rust Taurus.
At this level, there's no reason to fret about download sizes anymore if you're comparing to something like Electron, so no real need to "shake the tree" or really limit the lisp image size. Modern lisps aren't that big compared to most anything else anyway.
Interestingly the clojure community at large does not really value or use it so much. I think even Rich Hickey commented on that at some point.
Do you have some examples and what language features are terrible?
Even then, the ecosystem is a Faustian bargain.
The sexp-based collection literals are very convenient, and coupled with the threading macros make writing and reading clojure code very productive and fun.
Clojure has a lot going for it.
The biggest issue I have with it is the same issue I have with any 'hosted' language. If it doesn't own the runtime, it risks being broken or held-back by changes it has no control over. Clojure is conceptually and syntactically simple, so it probably fares better than other JVM-hosted languages, and the JVM itself has historically been very stable at the bytecode level, but it still a risky thing to require your platform to stay stable for your language ecosystem to survive.
I love you Clojure, but I'd rather invest in a language that controls its own destiny.
The bloat of the JVM, and the implication of Java down the road, made me nauseous.
My eyes just rolled so far back in my head I can see my skull.
Slightly earlier he did discuss the general alliance against Microsoft. I thought it was funny he didn’t mention Netscape as part of the alliance. At the time they were considered far more important than IBM or Oracle for purposes of displacing Microsoft on the consumer side.
It’s fine in the grand scheme of things, a younger person who was not there trying to reconstruct what happened and slipping up a bit. But for someone who cares about the details of this sort of history I didn’t want to absorb any similar errors about Common Lisp which I’m genuinely curious to learn about.
A couple of C# features were born in J++, namely P/Invoke (J/Direct), events (influenced by Delphi before even Anders came to MS), and Windows Forms (WFC).
There is also FOIL, which runs JVM (or CLR) in a separate process and provides a bridge for calling into JVM from lisp. It was written by Rich Hickey (the future author of Clojure), who observed that the reflection overhead was similar in magnitude to the serialization overhead!
> "Aimed to counter Microsoft’s .NET framework"
First of all the alliace came to be during the 1996 - 2001 timeframe that predated .NET.
When Network Computer came out there was no .NET.
When Oracle adopted Java into their database ecosystem there was no .NET.
When IBM refocused from Smalltalk into Java, there was no .NET.
Secondly, .NET was only born with C#, after Sun's lawsuit due to J++ language extensions (J/Direct reborn as P/Invoke, COM interop, WFC reborn as Windows Forms, events).
Had it not been for the lawsuit, the updated COM Runtime being researched would have most likely used J++, as shown on the Ext-VOS paper.
Also 20 years later, Microsfot saw they had to embrace Java on Azure, and they are now an OpenJDK contributor with their own distribution, talk about strange ironies.
> I think he simply meant that Java was marketed and therefore prospered as a counter to Microsoft's dominance more generally.
i.e. ".NET" being used casually (and incorrectly) as a catch-all for anything Microsoft was doing in this space roughly around that period ...possibly suggests there's been an anti-M$ bias!
Windows hegemony should have been used instead.
Apparently, you can compile SBCL using ECL, so if you really want SBCL itself instead of just a Common Lisp implementation, that might be a path to it.
I'm not sure if the recursive hierarchical conceptual inference as well as many other things would have been possible without Common Lisp.
Aside: this is also an argument, for example, for even using python and rust (one of the most depressing things that led me to quitting Google last year was a manager that demanded C++ for performance reasons over Rust despite being off-g3 and it being an utter nightmare to bikeshed about C++ libraries) when someone tells you that you “need” to use C++ for performance.
