No mention of The Configuration Complexity Clock [1] which I always think deserves a link, but credit to the author for actually keeping it slim and readable over (IMHO) most of the newer additions to the landscape which either declare themselves as 'obvious' and aren't or just add features such as Pkl's extends keyword, moving us further round the complexity clock.
Of course just adding multiline strings is the start of the rabbit hole, now you need to think about leading line breaks, trailing line breaks, intermediate line breaks, whitespace chomping, and- oh heavens I've reinvented YAML, I think I need to lie down.
[1] https://mikehadlow.blogspot.com/2012/05/configuration-comple...
One kinda-exception I'd like to raise: Cases where you'd like to use the regular proper programming language from the very beginning, but there are trust issues, and there's no good/reliable sandboxing option.
For example, B2B stuff where every customer has their own idiosyncratic sets of rules for if-this-then-that, which change at a different cadence than your releases.
In those cases, it's less that configuration slowly becomes too complex and evolves into code, and more that code is wanted from the get-go but configuration is the compromise.
Just to ensure you're aware: This is why Google made Starlark. You can think of it as just enough Python for the exact use case you talked about. Deterministic + hermetic is great.
https://starlark-lang.org/
> every customer has their own idiosyncratic sets of rules for if-this-then-that
So Varnish Configuration Language? It's definitely an awkward case that doesn't seem to fit neatly into the landscape.
Nice article. I've definitely moved the clock to 6.
And I remember toying with the idea of 9 but I think for a different purpose, I don't remember what. Never did get that far though, I'm acutely aware that tooling is also important, but it's still oh-so-tempting.
I wonder where the company is at now. I don't think they would have moved the clock ahead but they may have moved it backwards to 12.
I don't regret my little rules engine though. It held up very well. It was intended for non-devs to be able to use, but the article is quite right, a complex set up was not easy to understand! I often got questions when things looked wrong but after much thinking the rules were usually calculating things correctly.
The alternative would have been 100 hardcodings because each client needed something different.
Thanks for this - it expresses something I've felt for a while. Solve too hard and you end up back at midnight.
I'm sure there's no relation to The Doomsday Clock.