3 ms·
I've increasingly found myself drawn to writing declarations as programs, not as config in any plain textual format. Whether it's going all the way in the dire
by AaronFriel 5y ago
I've increasingly found myself drawn to writing declarations as programs, not as config in any plain textual format.
Whether it's going all the way in the direction of supporting general purpose languages like Pulumi does, or with a niche but still Turing-complete language like Nix's expression language, or even Dhall, which other commentators have mentioned. That isn't to say there is no place for simple, human readable schema. I think these tools need a fallback to something simpler.
Nothing these tools do couldn't be emulated by manual processes of hand-writing complex makefiles or YAML or whatever, but what is striking to me is the use of general purpose languages, usually with tooling to do type-checking and IDE assistance to writing these things, which lowers the barrier to entry and empowers someone who "just knows (Python|JavaScript|Go|...)" to contribute in a familiar environment.
A couple more examples:
Envoy: I have had the displeasure, recently, of writing by-hand a configuration for the Envoy load balancer. Envoy uses a "typed config language", which is often represented as YAML or JSON, but it's very painful to write by hand. On the other hand, if you have the protocol buffers/gRPC schema available in code, it's vastly less painful to use any programming language to build the typed objects and then export to plain text. The xDS protocol is designed for being interacted with via programs, not plaintext.
GitLab CI: GitLab supports writing a program, which runs as part of the CI/CD job, to generate the configuration for a subsequent pipeline. This makes writing complex jobs, or repetitive monorepo tasks much simpler. A 10 line Python program that effectively does "for each folder in `python`, emit this block of YAML" is incredibly powerful.
That last example is salient to me: markup languages are really easy to parse, but challenging to read when they're dynamic. Wouldn't it be nice to be able to mix and match? YAML/JSON where it makes sense and the intent and meaning is self-evident, and to write code where you need dynamism?
Full disclosure: I work for Pulumi, opinions are my own, etc.
- jandrese 5y agoIn the past it was fairly common to write configuration files in TCL and just running the script to parse them. This was generally considered to be a mistake. It opens up a huge threat surface for your program and few people ended up using the more advanced capabilities it created. If your config format supports simple globbing that covers the 95% use case for otherwise needing a turing compete language for your configuration files.
- AaronFriel 5y agoI think that speaks to having that flexibility when needed. The other 5% of use cases are significant too.
- jandrese 5y agoThe other 5% is generally solved by people who write scripts to generate the config files. It's not like they're up a creek.
- kaba0 5y agoThat’s why I think Dhall is really interesting, it being purposefully not Turing-complete, yet still very flexible.
- blacksqr 5y ago> This was generally considered to be a mistake. Pity. Tcl allows you to create safe interpreters within which you can disable any commands you want in order to have a trustworthy environment for running configuration scripts. Tcl itself uses them to build its internal list of available package modules.
- xelxebar 5y agoInteresting. I've been using Guix for about two years now and really love its approach to configuration. Everything is written in a general programming language, but Guix provides a really nice DSL that covers your package declarations, operating system declarations, etc. Guix uses Guile Scheme end-to-end, but you really don't have to know any lisp as a user. The DSL just reads in such an obvious way. However, since it's Just Lisp, you also have a full programming language and ecosystem available for the times you need it. In fact, this has been how I have begun to absorb lisp! I started off writing simple package definitions and slowly started tackling ones that require more hand-holding. Now I find myself even able to quickly sketch up scheme scripts for common system tasks and the like. EDSLs are great!