The description of uxn and varvara are also small and might need only two pages (I did not write it).

I also remember reading in a book that someone made a game on Atari in 2 kilobytes, and described how they could make it fit (by making the map symmetric, etc), which was rejected because they had 4 kilobyte cartridges by then. (The article in this submission also links to a different game that (probably) someone else made in 2 kilobytes, but this time with JavaScript and HTML. Atari and uxn/varvara are much simpler systems than HTML/JavaScript, though.)

The other part for me is working within tight constraints. A couple of years back I made an Operating System that fits a bootloader (I was low-key hoping to find in the list :P) Not really golfing but surely a good exercise in playing within constraints.

If anybody wants to take a look https://github.com/shikaan/osle

1: Design a bytecode. 2: Write a compiler. 3: Write an interpreter.

It seems like it would be simpler to not bother with 1 and 3 and instead use machine code as the bytecode. A side benefit is that programs will run faster.

I think it is easy to generate machine code for x86_64, ARM64 and risvc64, as long as you don't mind it being 3x larger and slower than an optimizing compiler would generate. It ought to be easy because it is possible to only target the common subset of features these architectures support.

I made a start, https://github.com/abainbridge/mortar, but haven't got much past being able to compile and run a Fibonacci sequence generator. I have no experience with language design or compiler implementation. I was somewhat gobsmacked when the fib generator ran 380x faster than an almost identical looking Python program.

Any comments or suggestions, including, "that's a bad idea, you will fail because of XYZ", or, "save yourself the effort, here's one I wrote earlier..."?

With an LLM, you can get a good-sized code base to converge on bug-free. The size of the code base your human mind can comprehend on its own is very small, so tiny pieces of code that do something interesting or useful seem beautiful and phenomenal to us. LLMs bust through that limitation and are capable of comprehending far more at one time than we are. Ultimately, human comprehensibility of code will no longer matter, and we will soon be guiding the evolution of vast towers of complexity that Just Work because they've been meticulously checked by machine at all but the highest levels of abstraction.

Where LLMs currently fall down is nuance, things like "business context" and what information resources users actually need.

Constructing Language Processors for Little Languages by Randy Kaplan - https://www.amazon.com/dp/0471597538?lv=shuf&channelId=500&p...

Also, JimTCL.