Dnjs: A pure subset of JavaScript that wants to replace configuration languages
github.com
github.com
IMO better strategy would be to reduce config files to absolute minimum and let the code that reads them handle all the complexity. Whatever is your main language, it is better supported than any of this.
It was a great learning experience though and I'm glad I did it, both in terms of learning how to write grammars (I used Clojure's Instaparse) and interpreters, and in learning about the users needs and wants.
But I shudder to think about if anybody else would have had to use it...
[1] Some interesting (IMHO) technical details: it was a synchronous language (of the transformational system variety), meaning that while it was executing, time was essentially frozen: it would gather all of its inputs, then evaluate the code as a pure transformation of its inputs (made it very easy to interpret!) and then write its output. The inputs are essentially immutable while the evaluation is happening. This was run in a database transaction for consistency. Each individual script was basically stop-the-world non-concurrent, but the scripts were independent and many could execute at once. I'm a very big fan of event driven synchronous languages.
However I argue that I haven't seen many cases where configuration DSL were well justified.
By configuration here I mean something that describes differences between different deployed instances of the same code. If you take all deployed instances of the existing system and see what is minimal amount of configuration to describe these, you would usually find that very little information, just a few lines would be enough.
The rest of configuration file complexity comes from the designer's attempts to predict the future extensions. My point is, these should be resisted for the sake of future generations of maintainers.
Overall, I completely agree with you, but I do find that HCL seems to be a pretty good fit for what its used for (at least for Terraform, which I have more experience with than their other tools).
My little story was really just me dumping my thoughts after reading about Stevecode, as someone who made a little language (not a configuration language though) and isn't an argument for doing so at all. I'm definitely in favour of sticking with an existing format for configuration (personally, I like to use TOML or EDN for my own projects' configuration needs, or JSON if its not normally meant to be edited by humans) and even for scripting, normally I'd stick with Lua or Javascript. My language came into existence because neither of those was sandboxed in the way I wanted (it was also deterministic and guaranteed to halt as there were no unbounded loops).
The whole point of configuration is that it's not code.
I use a simple litmus test: can your system work at least to some extent with empty configuration file? If not, you went too far and need to simplify.
1. Using a file format that depends on a particular engineer
2. Static vs dynamic configuration
3. Volume of configuration
For example, you can reduce your configuration to a minimal set of files which use a standard dynamic configuration format (e.g., starlark).
Note that The principle of lesser power should guide your decision between static and dynamic config format; however, if you find yourself building dynamism atop YAML (e.g., CloudFormation) or doing text templating of YAML (e.g., Helm), you’re misunderstanding the principle and suffering unnecessarily.
The problem with what you call the principle of lesser power is that people fail to accurately predict "suitability" of their solution and choose wrong tool for the job. They start with "I just want to set a couple of variables" and end up with full-scale development system with IDE, debugger and profiler, badly designed and partially implemented.
> Starlark is not configuration, it's a Turing complete "feature-challenged" programming language.
It's both. Programs are configuration. Not all configuration can be expressed statically except by expressing the program that derives it. That's what we mean by "dynamic configuration". Further, for the purposes of configuring most common applications, we want the language to be free of side effects ("feature-challenged" as you call it) because we want the execution to be reproducible--note that this is also an application of the principle of least privilege. There are also lots of practical reasons not to use Python or the JVM, notably the dependencies on big bulky runtimes.
> After suffering few thousand lines of a bloody mess created in this language, I can certainly say that Python, or Java would have been much better in this context. Pants (Twitter's version of Bazel) looks much better architected system in this respect.
I've used Pants in vain and I wasn't able to discern much 'architecture' in the original version. The rewrite seems to be better thought-through, benefiting from the experience of the initial version, but time will tell how it fares. That said, Bazel also left a lot to be desired in the way of extensibility, usability, quality, documentation, etc the last time I looked into it. In whichever case, the configuration language isn't the problem with either system. That said, as I respond to this comment, I'm building my own build system that is dramatically simpler and friendlier than existing systems, and it also uses Starlark as its configuration language (only because it's familiar and the most straight-forward to integrate).
Determinism is essential for a configuration language. I don't want to load configurations that may or may not crash your computer.
You get a cleaner literal syntax than Json, and easily composable functions.
The hiccup list syntax for html in clojure is a joy to work with.
- I'm aware of dhall, jsonnet and friends, I think they're cool, but I think the most important for me is this is just js - that means nothing new to learn + you can use it from front end code + free linters etc.
- I think the to-html bit is important, this is something I tangentially talked about in more detail here - https://leontrolski.github.io/dom-syntax.html. There was some discussion on hacker news about that one too, again, I think the important "feature" is that it's just js. Again, to me that's really important, so hiccup, jsx, etc don't cut it.
- render entire pages from a Python backend
- use as components in mithril https://mithril.js.org/
Therefore I think it's very understandable why people come to that conclusion so often.
{
“type”: “div”,
“style”: “...”,
“children”: [ ... ]
}
{
“type”: “div”,
“attributes”: {“style”: “...”},
“children”: [ ... ]
}[1] https://github.com/lightbend/config/blob/master/HOCON.md
Are there other advantages to a custom runtime that I'm missing? Even if it's only a subset of the language, the Python runtime probably isn't faster than Node.js.
Great for machine learning and generic config too
Oh no. This sort of implicit magic has no place in my hear and my configuration files.
Your JS/Python/Lua code could do plenty of non desirable stuff (infinite loop, download trojan from the internet...etc).
Dhall lang for example forbids all this, but still allow you to write simple functions to avoid repeat yourself.
- purity (within bounds of the local filesystem state; no dynamically computed imports; no networking; no file writes)
- declarative, lazily evaluated
- override syntax (allowing for a balance between explicitly defined APIs and some level of monkeypatching)
- file-relative import syntax
- simple interpreter that's easily embeddable into tools (no modules, no interpreter path, no global configuration files, etc)I think that's a typo?