It would be nice to refactor some of these. Vas deferens and laryngeal nerve look like easy pickings. Leave me my ear-wiggling. Any last bit of expression matters.
I'm dreading the horror of genetic manipulation it would open. The gene editing craze feels like it is right around the corner.
Balancing trade-off is crucial in software design. It would be nice if the documentation listed the trade-offs of the structures compared to their native implementations. I imagine at least every mutation is consing? There are also larger fixed and slow-growing overheads in various operations.
Yeah, clojure gets away with it thanks to the high performance of the available gc in the JVM. In the Common Lisp world the compiler puts quite some effort into avoiding heap allocation ("consing"); the language was designed with that in mind. Not sure where it's now, but not too long ago SBCL's gc wasn't its strong point.
SBCL's gc is historically overly optimized for throughput at the expense of everything else. It also predates common availability of parallel systems. There's a new GC that addresses those things.
That being said, for batch processing in single-threaded applications, the older SBCL gc is actually pretty good.
Most lisp implementations use a moving collector of some kind, so heap fragmentation is less of a concern.
As far as constant factors go, this library is a middle ground; they strive for low constant factors in their algorithms, but it relies almost entirely on generic functions, so that alone is going to limit the maximum speed in e.g. tight loops.
Besides, one can easily code a skill+script for detecting the problem and suggesting fixes. In my anecdotal experience it cuts down the number of times dumber models walk in circle trying to balance parens.
It is probably the best Common Lisp compiler when it comes to type checking. However, it leaves a lot to be desired. For example, it cannot specialize an element type for lists. With lists being the go-to structure, if you attempt to (declaim) every function, you will immediately see how vague and insufficient the types come out compared to even Python.
The ability to specialize list parameter types would greatly improve type checking. It would also help the compiler to optimize lists into unboxed arrays.
Please don't tell me that static type checking doesn't lend itself to CL. The ship has sailed. It does work with SBCL rather well, but it can be better.
Some may blame the Common Lisp standard. It indeed doesn't specify a way for list specialization, but the syntax is extensible, so why not make it as a vendor extension, with a CDR? AFAIK CDR was supposed to be to Common Lisp what PEP is to Python.
I would use vectors and arrays, but in CL ergonomics is strongly on the side of lists. For short structures vectors and arrays don't make sense.
I think it is also a time to outgrow the standard and be more brave with extensions. A lot has changed since the standard. It is still very capable, but as powerful as CL is, some things just cannot be practically implemented in the language and have to be a part of the runtime. Yes, I'm talking about async stuff.
So I got the idea to see how difficult it would be to bolt on async runtime to SBCL. To my surprise the project is hosted on awfully slow SourceForge and project discussions are still happening on mailing lists. Sorry, but I am too corrupted by GitHub's convenience.
>if you attempt to (declaim) every function, you will immediately see how vague and insufficient the types come out compared to even Python.
Indeed, but 1) it is used by the compiler itself while cpython currently ignores annotations and 2) runtime and buildtime typing use the same semantics and syntax, so you don't need band-aids like https://github.com/agronholm/typeguard
But yeah, CL's type system is lacking in many places. In order of practical advantages and difficulty to add (maybe): recursive DEFTYPE, typed HASH-TABLEs (I mean the keys and values), static typing of CLOS slots (invasive, like https://github.com/marcoheisig/fast-generic-functions), ..., parametric typing beyond ARRAYs.
Let's be brave and deviate from the standard, preferably in a backward-compatible way, to provide the best achievable DX.
The CL committee, however smart it was, could not think through all the nooks and crannies of the system. Let's continue where they left off and progress.
Coalton [1] adds Haskell-style types (so typed lists, type classes, parametric polymorphism, ...) to Common Lisp, and compiles to especially efficient code in SBCL.
Describing Coalton as a CL add-on or even as a DSL has always seemed wrong to me. It's of course very tightly integrated with the Common Lisp runtime but it's also very different as an actual language. And I mean that in a positive way as being different from CL is both an achievement but also a requirement for doing what it does.
I just found it funny how Clojure's lack of cons pairs is enough to cause religious debates about its Lisp nature while (ISTR) adding symbols to Coalton basically requires foreign calls to the host system, but it still counts as a CL-with-types.
Wouldn't that be something that the tooling could deal with easily? I don't know if there is anything like that yet, but the last time I took a quick look at Coalton it seemed like some basic SLIME and ASDF etc support with its own filetype and Emacs mode to go with it could be potentially useful and fun little project.
Nice, pretty much what I had in mind. I think there could be some interesting potential there tooling wise. Combining a highly dynamic interactive environment with a good statically typed language sounds fascinating to me and it's something that at least to my knowledge has never been seriously tried. Only Strongtalk comes to mind but I have no idea how it was like in practice, and I assume the type system was something closer to Java.
It is not easy to tell because lparallel's documentation website has rotted away just the same as cl-user.net. Does anyone remember this beautiful wiki of CL libraries?
Anyway, it looks like lparallel is nice and has some very useful concurrency primitives, but it doesn't have lightweight scheduling, unlike Go. So no cheap async work with many open sockets, cheap context switching, better cache utilisation, simple language constructs and mental model for async tasks. Besides, Go has M:N scheduler. It has all these async benefits but in addition all the threading benefits. Such things can only be properly done by the implementation.
Looks like a sibling comment mentioned the proper documentation home. And OMFG cliki is still down... 17 days ago it was "being worked on, being brought onto new infrastructure". It will be back eventually... But a lot of Lisp people aren't really web dev people, for better and worse. (Having any significant downtime for such a service is nuts to me.)
You might be right about typically needing deep implementation support but that hasn't really stopped people from trying to do all sorts of concurrency approaches with Common Lisp including async ones. Ones of note are listed here: https://github.com/CodyReichert/awesome-cl?tab=readme-ov-fil... Usually they are still built on the native threads, though, but cl-coroutine is built on cl-cont (continuation passing style) which has also served as a foundation for building green threads with e.g. https://codeberg.org/thezerobit/green-threads cl-async is also odd as being built on libuv, and similarly there's libev bindings with https://github.com/fukamachi/lev that power the webserver woo: https://github.com/fukamachi/woo (Which as of 10 years ago, had comparable performance with Go in reqs/s.) (That timing makes me want to add that personally, after trying things and experiencing the hype of the 2010s, at the end of the day I think async-driven code is harder to understand than thread-driven code with some concurrent data structures, blocking queues, and the occasional promise/future. The need for more lightweight non-kernel threads is pretty context dependent.)
That explains why Opus was so dumb yesterday. It walked in circles on tasks it used to one-shot. With these companies and services you never know what product you are actually getting regardless what is said on the tin.
We all can google. Have you tried to install the plugin? It doesn't support the current version of the IDE and as the last commit was 8 months ago there is no hope it will get such a support soon.
TBH no people don't google (what they don't expect to see), repetition and showing links is necessary. I hadn't followed along. Hope it will get contributors.
One thing this specific feature was letting me do is seeing when Claude Code takes a wrong turn, read a wrong memory MD file. I used to immediately interrupt and correct its course. Now it is more opaque and there is less of a hint at CC's reasoning.
I'm dreading the horror of genetic manipulation it would open. The gene editing craze feels like it is right around the corner.
reply