zlacker

> Ideally, codebases would grow by adding data (e.g. a json describing endpoints, UIs, etc), not repetitive code.

The problem with this configuration based approach is that now the actual code that executes has to be able to change its functionality arbitrarily in response to new configuration, and the code (and configuration format) needs to be extremely abstracted and incomprehensible. In the real world, someone figures out that things get way easier if you just put a few programming language concepts into the configuration format, and now you're back where you started but with a much worse programming language (shoehorned into a configuration format) than you were using before.

Boilerplate may be cumbersome, but it effectively gives you a very large number of places to "hook into" the framework to make it do what you need. AI makes boilerplate much less painful to write.

>>woah+(OP)
Working on a system like this (mostly configured with complex yaml, but extended with a little DSL/rule engine to handle more complex situations) a long while ago, I introduced a bug that cost the company quite a bit of money by using `True` instead of `true`—something that would have been readily caught in a proper language with real tooling.

>>macNch+o4
That would be caught by any schema validation system at runtime, e.g. Zod in typescript, Malli in Clojure, and so on.

>>woah+(OP)
There are always middle grounds to be explored. The way I see it, 80% of a "codebase" would be data and 20%, code.

Both worlds can be cleanly composed. For instance, for backend development, it's common to define an array (data) of middleware (code).

At a smaller scale, this is already a reality in the Clojure ecosystem - most sql is data (honeysql library), and most html is data (Hiccup library).