I'm strongly against going down the rabbit hole of implementing something like this. I often encounter the situation where configuration files become complex an

I'm strongly against going down the rabbit hole of implementing something like this. I often encounter the situation where configuration files become complex and it would be a nice-to-have thing to embed logic in them. But then you start slow, maybe add conditions, then function calls, then loops, then variables and soon you have implemented your own Turing complete language by accident, spending countless hours re-inventing the wheel. The demonstrated approach IMHO leads to situations where N implementations share the same code, like the "atNight" function he shows. So each new feature requires synchronous changes to N codebases. I would probably opt to rather embed a "real" scripting language lika Lua or Groovy (or today, maybe even some JS dialect), provide it the spec object, the seasons and countries and be done with it. I instantly gain a ton of features, existing documentation for end users and no endless river of "please add condition X to the config language" tickets.