Handwriting is not quite good enough to create a kitten. I remember this from C. Sidney Burrus on the fastest fourier transform in the west:
A human cannot meaningfully handwrite a discrete fourier transform program. However, a human can write a program that can write a discrete fast fourier program. This is a general principle of scientific programming.
I will find the citation for that later, but that is how I remember the line. A human can look up the equations and literally write in whatever programming language the equivalent statements to a Winograd fourier transform, but this is not what we usually mean when we say we want to do a fast fourier transform.
The amount of handwriting to do per single use is simply too high. Nor can I write a simple macro. We need a static program analysis that runs as part of compilation that chooses what program to write, writes it, and that gets compiled. As you know, cl-series is my favourite example of this. LLM generated code is known to never be possible as a replacement, because the static program analysis we are talking about must be rigorous. Similar to how an LLM cannot possibly do cryptography - that technology simply cannot do that.
Thanks for clarifying the spelling of Des Rivières, and I suggest anyone reading this go read that instead (as well! Come back here after the art of the metaobject protocol).
Jim des Rivières home page continues: MOTH IMAGES.
There are, I think, a lot of professional web programmers whose jobs are to handwrite good single websites for single customers some of whom have asked me why I do not just hand-write one kitten once. The implication is that the single website receives visitors constantly for a long time into the future, so a large up-front effort in handwriting this single site inevitably pays off. I think they are right that a lot of websites (literally, their customers’) are like this.
The Art Of The Metaobject Protocol (Kiczales, Des Rivières and Bobrow) gives the goal for lisp’s metaobject protocol like this:
Instead of the common lisp object system satisfying a single point in the space of possible object systems, the metaobject protocol fills an area of possible object systems.
Well, I will check “what it actually says” later and add a note if necessary. It points out that people who genuinely liked Flavors more than CLOS can simply MOP (use the metaobject protocol) the object system into literally doing what (mid-period Lisp machine generics) Flavors did.
This is a similar point to the fastest fourier transform in the west program generating programs for a space of possible fast fourier transform desires, in making a metaobject protocol for a space of possible object system desires.
In this lisp and broader programming tradition, I want to fill an entire space with kittens, not just have one kitten once.
I rhetorically pigeon-holed myself into using the mop here. I recall my friends and mentors on the Mastodon were extolling the book recently.
It was a long time since I last tangled with AMOP - at the time there was lots of ANSI CL I did not know enough about to appreciate where the MOP was coming from.
In terms of related examples, upto 2008, common lisp elephant used the MOP to define lisp standard-class as being backed by the ACID berkeley-db.
I’m going to reread the Art of the Metaobject Protocol before calling anything else. While it seems like I could use CLOS shared allocation slots and specialize method-qualified after shared-initialize to wire up a class that is a straightforward persisted, maybe automatically updated kitten, I think MOPing as we just said is a stronger approach for these reasons:
page metaclass should literally be the files in their kitten parentIn my opinion it is better for these to be literal truths about their metaclass than for this to be made-true by use of generics to syncronise manually in either direction, similar to how elephant changed standard-class.
Thoughts, opinions, criticisms, bids of good luck sought on the mastodon thread.
screwlisp proposes kittens