Steel Bank Common Lisp version 2.6.7

In my first job, grumpy Martin had as one of his many indispensable tasks, to build cmucl. (Itasoftware, one of the main lisp shops of the age)

It is my understanding that easing bootstrap was the original motivation of the fork of CMU CL. I'm a bit confused about that, since CMU CL supports compilation to byte-code (which should make a port to a new architecture comparatively easy), a feature which was dropped in SBCL.

I collected the disparate words of Dang here: https://lisp-journey.gitlab.io/blog/hacker-news-now-runs-on-...

It still uses Arc. The original implementation was written in Racket, then rewritten in Common Lisp and run on SBCL.

And the very recent https://old.reddit.com/r/lisp/comments/1v6kyyn/so_they_say_l...

Yeah, but I am guessing one needs a bit more info on how this works together with GC. For example, once an arena goes out of scope, what happens to allocations made inside it that have been returned and thus are referred to from outside that scope? Are they copied out or do we have a dangling pointer? Stuff like this needs some decent documentation in order to be able to use a low level feature like this properly.

Common lisp isn't functional in that sense.

Common Lisp is pretty much the opposite of what people think of as functional nowadays. You're constantly changing the image and everything is mutable.

> Personally I think/hope they would have earlier discoveries / more broad usage of the deterministic systems like nix etc, which are built upon functional principles of immutability etc.

Yeah, that, uh, doesn't sound like Lisp

You probably want Clog: https://github.com/rabbibotton/clog

sbcl can compile to a single executable (the image is embedded in the binary). From a deployment standpoint, the only real issue is if you depend on a dynamically linked C library like OpenSSL.

Docker deploys is a bit like that I think. Overall, I think many languages and programming systems pick up pieces from each other nowadays. PHP almost by accident can be quite stateless. Yet it's looking more like Java. Many things which could be deployed as an executable, are deployed as VM images. I'm sure we can come up with more things...

Images can be saved out as files, so I don't see why not. Also, I recall it was the expensive commercial licensing along with the rise of cheap PCs as competition to Lisp and ST machines. That and Java being free with a focus on networking and the web was the final nail in squashing Lisp or ST popularity.

Not sexps, but better.

Quite a while back I have read about a system based on Scheme , called termite (I don't remember which scheme that was) that can actually sling live running code/closures across network and execute them remotely..

Boggles my mind even today.

in at least Common Lisp world slinging s-expressions is considered to be a hack, at best something you do in a development environment, like swank/slime wire protocol. one of the reasons is that a readtable is both powerful, user extendable, and has all kinds of default ways in which a malicious input would be detrimental. you can remove all kinds of reader macros like #.(xyzzy), but to make a truly bulletproof s-expression reader you'd have to build a json like subset from first principles. even things like colons in symbol name package:symbol will trip you up. it's been understood since long time ago, that common internet standards, like RFCs, are the preferred method. in which case the fact that it's an s-expression versus a json is pretty much irrelevant. it's a kind of reader/writer anyway.

Nobody stopped anyone to come up with variants, just from calling those ANSI Common Lisp compliant. There are after all many, most of which are long dead already.

The worst and best thing.

For non-LISP languages on k8s, you have Tilt (https://tilt.dev/) or Skaffold (https://skaffold.dev/) nowadays to support continuous development.

Not In production yes?

Also not sure what is SDE.

Uhm. I can think of more differences

The problem is that the type of developer you're talking about is the kind who invents a thousand excuses about anything. It doesn't begin and end with different languages. Using a different subset of their favorite language? A different toolchain? A radically different build process? You'll hear plenty of whining about it. Even just moving them to a different codebase will make them miserable. You put a Lisp or a Prolog in front of them, and their attention flows upwards to the most general principles to whine about. The entire thing is that if you stick them into an unfamiliar environment, they will vocalize their discomfort through rationalization. I think most people who have led teams will know exactly what I'm talking about.

Not that these people are necessarily bad at their jobs, but they're definitely a personality type you should learn to identify so you can manage them properly.

I was fortunate enough to use lisp professionally for nearly 20 years. The only reason that gig ended was the unfortunate demise of the majority owner and founder, and his heirs selling the shop to a competitor that only wanted the customer database imported. Lisp was never the problem, nor particularily messy.

On the contrary, we considered it a major reason we were able to build a quite successful stock broker and bank from scratch with a team of 4-6 people, who doubled as datacenter ops (we ran on-prem), internal tech support for the rest of the firm (~20 people) and 2.line customer support.

We quite naturally converged on a set of internal libraries for various tasks. Understanding and fixing each other’s code was not a big deal.

Coincidentally, our frontend was php. That was messier, and we conciously kept that layer as lean as possible.

I disagree with this profoundly. There is no argument that Lisp in general can get you in a terrible mess. So can C, or pretty much any language (I well remember a case of 11-way multiple inheritance in C++ game code). If I were running a Lisp-based project, there would be project standards (like no exported macros without signoff, and a list of standard library dependencies), documentation requirements, and code review.

The fact that Lisp is the “programmable programming language” doesn't mean that every engineer should be inventing weird versions of while loops. What it does mean is that a skilled Lisp programmer can build a domain-specific language that substantially helps in development.

One good example of this is the Crash Bandicoot games, along with the same studio's Jax and Daxter, which were built with dialects of Lisp (yes, they had to compile the code, and take care with storage allocation, just like any other game code). Cisco hired Kent Dybvig, principal author of the Chez Scheme system, and open-sourced that software; I have no clue what they use it for, to be honest, but I assume that they had some reason for doing this. Companies using various Lisp languages have been documented in areas from fintech to quantum computing.

>> said: lovely, but I ain't using it at work.

Says who, you? Wrong. I use Common Lisp at work.

edit: and not just use as in a side toy, design and writing software in CL is my primary responsibility. FWIW, at a FAANG!

I use Common Lisp at work.

> The very power of Lisp, macros, dynamic programming, reflection lead to a mess of an ecosystem where every single developer reinvents the wheel and nobody can understand yet another DSL invented by the next developer next to them.

Have you like looked at anything in the Clojure ecosystem because this description makes no sense of any kind. Clojure has macros but less powerful than common lisp and Clojure code in the ecosystem tends to be small and understandable.

+1 upvote

I don’t agree with you but your comment is very well thought out and doesn’t deserve downvotes.

I have a complete and utterly opposite experience. I have used and shipped all sorts of solutions in dozens of different languages before getting to know Lisp. My only regret is that I have not tried learning Lisp sooner - it feels like such a walloping waste of my life.

Lisp dialects turned out to be extremely practical - I just can't even imagine doing the things I do today with Emacs in anything else. Achieving similar effects with any other tool would be enormously more time consuming and far more frustrating. Sure, it really took me years to get to that point, but even though I had already knew all sorts of other tools which I could've picked to achieve similar results - from bash/zsh, awk, sed and tcl to python, golang and a bunch of others, the way Lisp-driven Emacs lets me get there is beyond meaningful comparison. Nothing even comes close and I'm enormously proficient in vim, I spent almost a decade in IntelliJ and used tons of different IDEs before - from Delphi and Eclipse to Visual Studio and VSCode.

Clojure, at which I scoffed at some point, turned out to be an immensely pragmatic tool for dealing with data. Any kind of data - big or small. It effectively replaced jq in my toolbelt, all my API interrogations happen in a Clojure REPL today. Fetching data from psql, mysql, sqlite and sorting, slicing, dicing, transforming that data interactively, directly from my editor is an absolute delight.

Building simple web-scraping scripts with nbb driving Playwright is so much faster than using any other stack, even javascript is no longer "an obvious choice" for me, even though I spent decades learning its quirks.

Babashka has replaced any kind of bash-scripting - anything longer than three lines almost has no reason to be made in bash/zsh/fish anymore.

Anything Lua-driven is now done with Fennel. It's not even funny how a dozen-lines boilerplate of Lua can be compacted into a simple, reasonable three-liner Fennel macro. Or the way how I can connect to the Hammerspoon REPL and poke through visual elements of any app on Mac, interactively and with ease - is complete and total bananas.

Era of LLMs incidentally highlighted another enormous advantage of Lisp - when you give an LLM a true Lisp REPL, agents stop guessing and start empirically analyzing current state of things and produces working solution faster, costing far less tokens. And you get to watch it solve things interactively, e.g. I often let AI poke through our UI (via Playwright-driven Clojurescript REPL), while monitoring situation in k8s - through nrepl port, connected to Clojure REPL. It literally interactively walks the DOM, finds the selectors, clicks buttons, etc. All without restarts, complex state management and all.

"Well", you may say: "these examples exactly what I'd consider a 'hobby language' territory".

Alas, I have worked in teams where Clojure was used for shipping commercial software and I have seen truly complex projects - Cisco's infosec infrastructure and FindingCircle's complex Kafka topologies. I have met and talked to people working at Netflix, Apple, Amazon, Nubank, CircleCI, etc., and I can confidently say: your self-conviction is absolutely backwards.

Lisp-world has never been more cornucopian than today; we see the proliferation of different tools and new Lisp dialects popping almost every passing week - Jank, Jolt, ClojureDart, Squint, Coalton, Clojerl, LFE, uLisp, etc. It is frankly inconceivable to find today any platform where you can't really run a Lisp. My advice to any programmer who's aspired to become a hacker - do learn Lisp. It comes in handy. For real.

Anywhere is where exactly? I've been thinking of where I could use it for like 10 minutes, and I couldn't come up with anything. Maybe a game engine or web services. It wouldn't make much sense for any kind of desktop software or command line utilities that are supposed to start really fast and have minimal runtime.

I have a todo list longer than the Tour de France I want to tackle first!

Behold! https://www.lambda-symbolics.com/autolith

Not mine, but interesting.

But then again, why would I use CL for this when I can use Elixir? I’m not the original commenter but I too can’t find a use case for CL.

Use `C-c C-]` (`slime-close-all-parens-in-sexp`) in SLIME ;)

In Common Lisp it'd be:

  (funcall (funcall (funcall (funcall ; ...

...though I don't think that functions which return functions which return functions which return functions ad infinitum are a great idea. Simply taking a value and returning a value means you can use a pipelining operator:

  (~> some-data
    function-1
    function-2
    (function-3 _ some-other-data)
    ; ...
    function-n)

That’s Scheme, not Common Lisp.

I’d recommend using close parens for your code sample. Those are portable between the two.

#|))))