Embed Notice

@mnl @clacke

The thing is, we already have constraint solvers and optimizing compilers.

The *common* solutions (like template expansion systems) are a nightmare, sure: nobody wants to write m4 code. But if you have a requirement, and you want to generate code to satisfy the requirement that actually works without writing any code yourself, the right way to do this is to use a constraint solver.

Normal code-monkey ecosystems have almost no interaction with the kind of tooling that solves these problems reliably -- they aren't covered in most university undergraduate CS programs, and they were too slow and awkward to use for this purpose when they were originally invented in the late 60s -- but there's no theoretical reason why we can just write formal requirments as prolog & generate javascript or whatever, provided somebody writes an ontology for doing it.

Retaining compatibility with popular and widely-used technical stacks is a killer in this respect, though: prolog is slow because optimizations intended for early-70s hardware (now incorporated into the standard) prevent certain modern hardware features from being used, algol68-like languages (i.e., basically every 'mainstream' language) are structured in a way that makes most tasks unnecessarily verbose but people don't want to learn the 'weird' languages that make these tasks easier, etc. Languages and development tools, outside of the esolang context and the occasional weird experiment like smalltalk, are designed to resemble and interact with the rest of the development ecosystem (and thereby inherit the ecosystem's attitudes and problems).