Unexpected numerological finding. I'm allocating memory for objects in sizes that are powers of two, in order to be able to manage separate freelists for each size to make GC easier. My hashtables have a header overhead of 4 words. My namespaces need a write access control list and a mutex in addition, so an overhead of 6.

It turns out that there are quite a lot more primes which are almost (- (expt 2 n) 4) for some n, than which are almost (- (expt 2 n) 6).

#Lisp
#PostScarcitySoftware

OK, folks, I've written yet another incomprehensible essay on the intricacies of implementing a software environment for the hardware of the deep future.

Read this only if you're incurably geeky, and, ideally, interested in #Lisp.

#PostScarcitySoftware

https://www.journeyman.cc/blog/posts-output/2026-03-28-Nodes-threads-locks-links/

Nodes, threads, locks and links

Up to now, I've been building a single threaded Lisp. I haven't had to worry about who is mutating memory while I'm trying to read it. The idea that this is a mostly immutable Lisp has encouraged me to be blasé about this. But actually, it isn't entirely immutable, and that matters.

The Fool on the Hill

@yogthos The inference engine I was working on for my thesis (and never completed), Wildwood, assigned objects to classes automatically based on their features; so that

1. one object could be in many otherwise unrelated classes; and
2. you could define a new class, and it would be automatically populated with every object already known to the system which met its criteria.

I wrote about this idea in my first essay of the #PostScarcitySoftware project.

https://www.journeyman.cc/blog/posts-output/2006-02-20-postscarcity-software/#social-mobility

Post-scarcity Software

For years we've said that our computers were Turing equivalent, equivalent to Turing's machine U. That they could compute any function which could be computed. They aren't, of course, and they can't, for one very important reason. U had infinite store, and our machines don't. We have always been store-poor. We've been mill-poor, too: our processors have been slow, running at hundreds, then a few thousands, of cycles per second. We haven't been able to afford the cycles to do any sophisticated munging of our data. What we stored — in the most store intensive format we had — was what we got, and what we delivered to our users. It was a compromise, but a compromise forced on us by the inadequacy of our machines.The thing is, we've been programming for sixty years now. When I was learning my trade, I worked with a few people who'd worked on Baby — the Manchester Mark One — and even with two people who remembered Turing personally. They were old then, approaching retirement; great software people with great skills to pass on, the last of the first generation programmers. I'm a second generation programmer, and I'm fifty. Most people in software would reckon me too old now to cut code. The people cutting code in the front line now know the name Turing, of course, because they learned about U in their first year classes; but Turing as a person — as someone with a personality, quirks, foibles — is no more real to them than Christopher Columbus or Noah, and, indeed, much less real than Aragorn of the Dunedain.

The Fool on the Hill

I've written another essay about my mad #PostScarcitySoftware #Lisp system.

"We don't need to know, or have known, these people to build on their work. We don't have to, and cannot in detail, fully understand their work. There is simply too much of it, its complexity would overwhelm us.

We don't know. We don't care. And that is a protective mechanism, a mechanism which is necessary in order to allow us to focus on our own task, if we are to produce excellent work."

https://www.journeyman.cc/blog/posts-output/2026-03-20-Dont-know-dont-care/

Don't know, don't care

Modern computing systems are extremely complex. It is impossible for someone to be expert on every component of the system. To produce excellent work, it is necessary to specialise, to avoid being distracted by the necessary intricacies of the things on which your work depends, or of the (not yet conceived) intricacies of the work of other people which will ultimately depend on yours. It is necessary to trust

The Fool on the Hill