A reasonable configuration language
ruudvanasseldonk.com
A reasonable configuration language
1–10 of 111 posts
Re: A reasonable configuration language
#2The configuration rabbit hole, for practically any system that becomes widely applied or through large amounts of feature iterations. With provisioning systems you rapidly walk the ladder because they are basically starting about five steps down on this already:
You start with an INI/yaml/json
Then you might have several overlaid INIs
Eventually: https://docs.spring.io/spring-boot/docs/2.1.13.RELEASE/refer...
Go ahead and make a java crack or something similar. Every line of that hierarchy is bathed in the blood of IT workers in the real world.
Wait! Not even close to being done.
Templating, expansions, "classes", embedded expressions: now we have computation folks!
I don't actually know the computational power of HCL, but eventually you end up with a Turing Complete configuration input that the poster wants.
And I'm actually leaving a lot of things out.
So many systems go through this, picking their own path. Kind of like workflow engines, almost all major systems will end up with a workflow engine in it (and the builds are workflow anyway). But there aren't well-conserved implementations of these overarching meta-patterns, so everyone bespokes it or picks from a mind numbingly vast array of pseudo-matching options.
Good luck!
Re: A reasonable configuration language
#3A reasonable configuration language blog post. Explains the motivation, provides some meaningful examples and a happy accident, and concludes with an overview of prominent alternatives.
Worth a read, and worth trying out sometime, if nothing else because I too don't use jq often enough to remember more complex usages.
Re: A reasonable configuration language
#4jsonnet[1] and kapitan[2] are the tools I currently use. Their learning curve is not optimal (and I tried to contribute to smoothen it with a jsonnet course[3] and a 'get started wit kapitan' blog post[4]), but once used to it it's hard to do without, and their combination makes them even more useful (esp. if you deploy K8s).
In Ruud's case, Jsonnet might have been worth looking at as Hashicorp tools can be configured with json in addition to HCL. But that would have been less fun I guess ;-)
I hope for Ruud it finds its niche, there's quite some competition in this field!
3: referal link: https://www.udemy.com/course/jsonnet-from-scratch/?referralC...
Re: A reasonable configuration language
#5This looks very restrained. Well done!
Re: A reasonable configuration language
#6The configuration rabbit hole, for practically any system that becomes widely applied or through large amounts of feature iterations. With provisioning systems you rapidly walk the ladder because they are basically starting about five steps down on this already: You start with an INI/yaml/json Then you might have several overlaid INIs Eventually: https://docs.spring.io/spring-boot/docs/2.1.13.RELEASE/refer... Go ahea…
The article did not advocate for a TC config language. I think Ruud would probably have been happy with a total primitive recursive language.
Re: A reasonable configuration language
#7Reading through this I'm reminded of another article from about a month ago, An app can be a home-cooked meal [0]. Whenever someone starts on a new language or framework, people are quick to ask "why" and bemoan the proliferation of languages and frameworks. I think this article is a good illustration of the "why".
What the author understands that so many don't is that a language can be a home-cooked meal. A programming language is nothing more or less than a tool for use by a programmer. Compilers have a lot of mystique about them because of all the crazy optimizations that production-grade compilers put in, but fundamentally a compiler is just a pipeline that transforms a data structure from a format that the human would prefer to interact with into a format that a specific machine can work with.
rcl is a home-cooked meal kind of configuration language. It was never intended to serve a wide audience, it was intended to solve a specific human's pain points and help that specific human with their task. Its value lies in that it doesn't need to try to be anything else.
[0] An app can be a home-cooked meal (1051 points, 288 comments) https://news.ycombinator.com/item?id=38877423
Re: A reasonable configuration language
#8I have seen many of these posts now and I have a simple question. Why do we need special configuration languages? Why not just use existing languages?
I understand why data formats like JSON and YAML are valuable, and I understand why it would be valuable to use a programming language to automate the generation of such formatted data. But the niche of the configuration language remains mysterious to me.
Re: A reasonable configuration language
#9The configuration rabbit hole, for practically any system that becomes widely applied or through large amounts of feature iterations. With provisioning systems you rapidly walk the ladder because they are basically starting about five steps down on this already: You start with an INI/yaml/json Then you might have several overlaid INIs Eventually: https://docs.spring.io/spring-boot/docs/2.1.13.RELEASE/refer... Go ahea…
The article did not advocate for a TC config language. I think Ruud would probably have been happy with a total primitive recursive language.
To me the distinction is not important. It is possible to write programs that take too long to execute in non-Turing complete languages, and when a program hangs, you just terminate it. I think what people really want is for their configuration to remain simple, but not being Turing complete does not guarantee that. For RCL I added a limit on the number of evaluation steps, because without it some programs trap the fuzzer.
Re: A reasonable configuration language
#10I have seen many of these posts now and I have a simple question. Why do we need special configuration languages? Why not just use existing languages? I understand why data formats like JSON and YAML are valuable, and I understand why it would be valuable to use a programming language to automate the generation of such formatted data. But the niche of the configuration language remains mysterious to me.
I'm guessing here, but maybe you see these configuration languages as templates? However a configuration language is much more than that.
For example, jsonnet lets you combine objects and override deeply nested fields [1]. I'm not sure how practical it would be to achieve the same result with a general purpose language.