Comptime as Configuration
3 comments
·January 10, 2025kevmo314
vermon
Reminded me of this post https://medium.com/wise-engineering/where-to-put-application...
MathMonkeyMan
I saw a talk at a C++ conference where the presenter floated the idea of writing a compile-time C++ GUI library for use in industrial equipment UIs.
Why parse markup and generate objects on the fly when there is exactly one UI that will ever be burned into the CNC machine's firmware? Why even bother with an object library that instantiates components at runtime when you know upfront exactly which components will be instantiated and all of the interactions that can occur among them?
At the time, I filed the idea under "C++ wizard has too much fun with metaprogramming," but he was probably on to something.
Another way to think about the idea is "let's invent a new programming language that allows us to express a single UI, and the output of the compiler will be a native program that IS an optimized implementation of that UI."
Fun story, while at FAANG I was once tasked with making a parameter configurable via flag. This wasn't super easy for various reasons, but I pointed out that it was configurable already: all you had to do was submit a PR to change the hardcoded value in the code and it would update everywhere and that wasn't much different from how we already configured runtime parameters by submitting a PR that updated the config file.
I got a good chuckle out of my coworkers but as I've gotten more experienced there's a grain of truth in that. Actually the main non-joking objection was that deployments are slow so if we needed to, reconfiguring runtime flags was a good amount faster. But that made me think: if deployments and builds are super fast, would we still need configuration in the conventional yaml and friends sense? It could save a lot of foot guns from misconfiguration and practically speaking, we essentially never restarted the server to reconfigure it. From the article,
> Unless you have really good reason to, you probably should not do this for normal options - it makes your library much more rigid by requiring that the user of your library know the options at comptime.
I dunno, actually that sounds really great to me.