Application systems have completely different tolerances than libraries. Chromium can take a completely bespoke build system, equipped with its own C++ code generator, vendoring every library that it tends to use. Interoperability to downstream projects is so far in the rearview mirror, that it may as well exist as its own operating system. Same goes for Emacs. The same goes for Blender.

What we need for building large and complex application programs is not the 100-year language, it’s the 1-year language.

Fortunately, this space is not the barren wild west of technology. Great pioneers have already trodden down at least one path ahead of us. Consider Terra. It’s a fully dynamic, very flexible scripting language Lua equipped to generate high performance C (and C++) code. It’s not without its footguns and design inconsistencies, but it should prove very useful.

The utility of Chromium and Emacs comes precisely from its performant basis, equipped with a very scripting language. Customizing Chromium UI is very simple, you write HTML/CSS/JS automatically harnessing the underlying framework. Customizing Emacs is the same.

Bindings are evil. Bindings are a waste of the universe’s limited entropy. Bindings should only be summoned when it is absolutely necessary, when it is to bring external incantations into your own spell. It should /never/, ever to bind together parts of your own spell. We need to get rid of sol2 and boost.python and guile.

The better approach is to build the binding into the language implementation being bound to. Instead of building a bespoke C program that implements computational geometry and crazy fast rendering of said geometry, and building a Python library for manipulating geometries, and bindings which glue the Python onto the C. Instead of this, we should build Blender as a flexible program which generates its necessary fast C. And in the process of which the binding is placed into place, automatically.

We should build a glorified macro assembler for the modern age, and pack it along with the application.

Lua is the base interpreter. Terra is merely a Lua program that spits out low level code. Terra, or whatever our new thing is, should mix Lua into its milk and egg and truffles, and build it all. This way all the power of Lua shall be present for harness at its heart content.

In this sense, we shall build a new lisp, a new SBCL, for its output is not merely the image, but also itself. Its image includes not only the program but also its environment and the capability of producing said environment. Its language shall not be constricted to whatever arcane dialect of lisp, but rather any two language of our choosing. Our creator of godotengine shall not be free to choose from whatever his heart contents, from C to Pascal to Rust to Nim to Odin to Jai to Carp.

—Sunday, 2025-08-24, from the dinner table. Edited 2025-09-01 for grammar and spelling.

Addendum on the macro-assembler construction

It is obviously no trivial feat to design a macro language around an existing language. Conceivably, every target one may wish to choose will need a specially designed macro language. Yet some parts should inevitably remain the same. Quoting and quasiquoting, file structure organization (coarseness of our macro; does it produce functions at a time or files at a time?). These may be reusable. Value roundtripping, memory model, specific syntax needs tweaking.

The outer language in which the macro assembler is built needs special consideration too. Lua is probably a pretty good choice, given its apt as an embedded scripting system in the final application. It’s also good for being small. Perl and python and ruby may be good in all aspects except its desirability as an embedded script. Their execution semantics are somewhat complicated. JS would be a horrible choice for its semantic complexity (and thus implementation complexity). Also, characteristics of the available implementations (fast) makes it very desirable as an embedded script. So this may make it desirable despite its negatives. Janet, Guile (-scheme) would sort of defeat the whole purpose of not invoking lisp, so as to not scare off people in the first place.