3 ms·
> Why can't these use simpler [...] configuration schemes? Because you inevitably need something less simple at some point. It's a hard balance to strike. Want
by kodablah 8y ago
> Why can't these use simpler [...] configuration schemes?
Because you inevitably need something less simple at some point. It's a hard balance to strike. Want only a config format? Get angry advanced users. Want only a programming language? Get angry beginners. Want both? Get a hodge-podge of half-and-half configs calling out to built extensions and in general a bunch of beginners finding poor code-based solutions on the internet.
In general, you need a simple programming language to manage this stuff or it becomes unwieldy once it leaves hobbyist size. And mixing config formats and full-blown languages (or worse, template languages) just adds ambiguity on the best way to do something coupled with loose synchronization between the two formats, "extension hell", and half-developed code solutions with an exponential number of poorly tested combinations of exported features that beginners try to use. To see examples of all these problems, one simply has to look at the historical landscape of orchestration engines and build tools.
- edwintorok 8y agoSome food for thought: https://dhall-lang.org/ https://dhall-lang.org/ looks like an interesting balance between config file format and programmability. Would it be suitable for describing packages?
- Ambrevar 8y agoI don't think that would be enough. At the end of the article I linked the paper "Code staging in GNU Guix" (https://arxiv.org/abs/1709.00833 https://arxiv.org/abs/1709.00833) which explains why 2 stages of code execution are so central in Guix. In practice, this means that a Turing-complete language (Scheme) is used both at the declaration level and the build level. Lots of packages make use of this feature, it brings tremendous flexibility to packaging.