I can't escape the feeling that emacs got this right. Nobody wants their config to be lisp, but it fits the bill for what you needed. Especially combined with the custom sections. So nice.
Common Expression Language
41–50 of 111 posts
Re: Common Expression Language
#42I remember seeing this used inside config files for the Caddy webserver. Google seem to like these executable config languages because they've got another open source one ("Starlark") a few notches up in expressivity.
I'm an ardent supporter of executable config languages, especially for the infrastructure-as-code space (the only thing special about this space is that configs tend to be very large, so you're more likely to run into reuse issues), which markets itself as "it's just YAML!" but inevitably all of that copy/pasted YAML becomes unwieldy and you want reusability. At that point, you have a few distinct options: 1. Build a…
What about the option of just writing a regular, one-off program in a regular programming language, the output of which is your baked YAML config; and then having a pipeline that involves running that config-generator program, piping its output to your orchestrator of choice?
Nearly every programming language has a YAML serialization library†. And before that serialization happens, your config can be expressed using the regular-ass coding features of your program, however you like. (For optimal clarity, I personally would suggest creating a builder DSL and using it.)
† Technically a language doesn't even need a YAML serialization library to emit valid YAML; because valid JSON is also valid YAML. You can just serialize to JSON on your end, and feed the result into anything that's expecting YAML.
Re: Common Expression Language
#43Earlier quoted context omitted.
Google puts that on most of its open source products including both employee personal projects and projects where Google has employees whose job it is to contribute to it.
Does any project not include the waiver?
Yes, for example the Firebase Tools CLI is open source (MIT), but it does not include the waiver, because it is an official Google product: https://github.com/firebase/firebase-tools
Re: Common Expression Language
#44I can't escape the feeling that emacs got this right. Nobody wants their config to be lisp, but it fits the bill for what you needed. Especially combined with the custom sections. So nice.
Your config language being turing complete doesn't work if you need to accept/validate config files from untrusted parties
Re: Common Expression Language
#45This non-Turing-complete language space seems like it should be useful for UI themes and other user scripting in particular:
- hard to write exploits, can be shared/installed without warnings
- easy(-er) to predict behavior of themes so they won't break in new versions
Re: Common Expression Language
#46Earlier quoted context omitted.
There's a difference between pathologically high complexity functions and Turing completeness. Sub-Turing languages generally don't allow recursion or unbounded loops - your program is always making progress. Solving 3-SAT doesn't sound like it precludes sub-Turing completeness, since you'd have a finite number of solutions you're iterating over. It's still useful for a config language because it makes it harder to a…
How do you mean sub-Turing languages don’t allow recursion? Aren’t context-free languages, for example, literally recursive?
"Arbitrary recursion" is the correct claim; e.g. Coq allows recursion, but has restrictions so all programs terminate.
Re: Common Expression Language
#47Earlier quoted context omitted.
There's a difference between pathologically high complexity functions and Turing completeness. Sub-Turing languages generally don't allow recursion or unbounded loops - your program is always making progress. Solving 3-SAT doesn't sound like it precludes sub-Turing completeness, since you'd have a finite number of solutions you're iterating over. It's still useful for a config language because it makes it harder to a…
How do you mean sub-Turing languages don’t allow recursion? Aren’t context-free languages, for example, literally recursive?
I assume GP means general recursion.
Recursion in a pushdown automata (the equivalent machine for a CFL) is bounded by the input words being consumed, since each state transition consumes one input token. Since all input words are finite, indefinite recursion is excluded.
Re: Common Expression Language
#48I can't escape the feeling that emacs got this right. Nobody wants their config to be lisp, but it fits the bill for what you needed. Especially combined with the custom sections. So nice.
Your config language being turing complete doesn't work if you need to accept/validate config files from untrusted parties
While I don't disagree, you can get rather far by limiting what you allow in the evaluation. There is no reason you have to pull it in in your current environment directly.
And then you have an easy mechanism to allow some configs from trusted parties to be a bit more capable, if they need it.
Re: Common Expression Language
#49Earlier quoted context omitted.
I'm an ardent supporter of executable config languages, especially for the infrastructure-as-code space (the only thing special about this space is that configs tend to be very large, so you're more likely to run into reuse issues), which markets itself as "it's just YAML!" but inevitably all of that copy/pasted YAML becomes unwieldy and you want reusability. At that point, you have a few distinct options: 1. Build a…
What about the option of just writing a regular, one-off program in a regular programming language , the output of which is your baked YAML config; and then having a pipeline that involves running that config-generator program, piping its output to your orchestrator of choice? Nearly every programming language has a YAML serialization library†. And before that serialization happens, your config can be expressed using…
Yeah, I do this for quite a few things. It works pretty well. In my mind that was implicit in the fourth point, but I didn’t spell it out.
Re: Common Expression Language
#50Earlier quoted context omitted.
I'm an ardent supporter of executable config languages, especially for the infrastructure-as-code space (the only thing special about this space is that configs tend to be very large, so you're more likely to run into reuse issues), which markets itself as "it's just YAML!" but inevitably all of that copy/pasted YAML becomes unwieldy and you want reusability. At that point, you have a few distinct options: 1. Build a…
> someone inevitably shouts "use the simplest tool for the job!" I think one problem is that configuration needs start out simple and evolve to complex - as opposed to being obvious from the start you'll need dozens of discrete components to deploy. At that early stage, anything beyond a few lines of YAML seems like definite overkill. Eventually, it becomes clear that it's very hard to maintain, but by then there's t…
That’s where experience comes in. We should know that certain domains (e.g., Kubernetes configs) are going to get unruly fast and we oughtn’t waste time with YAML. I don’t think this will be a controversial opinion in a few years time.