Very cool idea. I'd be curious to find out more about what it is being/might be used for
Envoy proxy uses it for conditions in RBAC filter.
Common Expression Language
81–90 of 111 posts
Re: Common Expression Language
#82Earlier quoted context omitted.
> 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.
Also; more generally: it makes sense to KISS, and the key risk here isn't somebody using yaml or json or whatever initially - even where experience shows that's insufficient, it's just not that costly either. The question is what to do when that becomes unwieldy. And I think it's pretty clear that kinda-sorta-programming that tries to incrementally extend stuff like static config languages - but only slightly - doesn't work well and is a bad idea. It's inconvenient; it results in many of the same issues as a full programming language, and it's often really inconsistent in its expressiveness - as in, for any given application thereof you're likely to run into limitations.
I think it's wise to try and skip as many of those intermediate stages as possible. Of course; that's not a clear-cut solution strategy either; because what's "as possible"? Exactly how high up the language chain do you need to go; conversely which language (and environment) features are too powerful, rendering the language difficult to contain?
Re: Common Expression Language
#83Earlier quoted context omitted.
> Ideological answer: For the same reason HTTP/2.0’s binary protocol didn’t instantly obviate/deprecate HTTP/1.0’s text protocol. Text has advantages: text is debuggable, and prototypable. If the interface between two programs is a text based declarative language, you can audit that text, diff that text, edit that text to see how changes affect the result, mock one side or the other by producing or consuming that tex…
But the third-party tool frequently isn’t intended to (only) consume machine-generated config. It’s usually built to consume a format that could equally be machine-generated or hand-authored. Usually with an emphasis on hand-authoring, where machine-generation is an automation over hand-authoring that will only need to happen as one scales; and so high-complexity machine-generation will only be relevant to the most e…
In most programming languages you can hand author a value just fine - that part isn't an advantage to something like YAML or json. Given the use of variables and a few other similar simple techniques, I dare say many programming languages are more amenable to hand-authoring static config objects than most static config languages.
I think the real issue is reproducibility; and that boils down to purity. Fully fledged languages all come with lots of apis and features to interact with the rest of the world, and it's quite unclear which apis have such dependencies and which do not - and it's seductively easy to do something actually useful in a "real" programming language that will make the whole configuration process unwieldy later - like, say, reading parts of the config from disk, getting some services public key off the internet, embedding a timestap, or even writing some computed config like a random key to a bit of storage for a later config process to consume. And once you do that, then the whole thing gets flaky, fast.
If you can rigorously avoid that, there's not too much advantage to a static config language.
Re: Common Expression Language
#84I 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
Though in that case you definitely want to disable macros for this config (as they allow for exponential time/space) and be very careful with any additional functions you expose.
Re: Common Expression Language
#85Googler here: for those of you who have ever used Firebase this is the language that powers Cloud Firestore / Cloud Storage security rules.
Specifically in our rules everything after the "if" is Common Expression Language.
See: https://firebase.google.com/docs/firestore/security/rules-co...
The efficiency and safety of CEL enables us to put security rules in the critical path of every database request.
Re: Common Expression Language
#86Earlier quoted context omitted.
At that point why use YAML at all? If it's generated by a program and fed to a program, you're better off using protobuf or something like that. In fact, since you're probably using the same language on both ends, why not just write a regular value in your language? This probably sounds like a strawman, but it's not. It's how a lot of e.g. Python projects are configured - the "config" file is just a normal bit of cod…
Things like AWS Cloudformation require YAML input, so there's no real choice on what you emit. But writing the YAML is fiddly and annoying, so that's a good example of something where it is better to generate it via troposphere (a python module) or some similar system. To be less specific I guess the answer is that sometimes you don't control both ends - the part that emits and the part that consumes, and having faug…
Just write JSON and pretend it's YAML. YAML is a superset of JSON so there's no need to generate "nice" YAML if there isn't a human reading or writing it.
Re: Common Expression Language
#87Very cool idea. I'd be curious to find out more about what it is being/might be used for
Used in Tekton triggers.
Re: Common Expression Language
#88Googler here: for those of you who have ever used Firebase this is the language that powers Cloud Firestore / Cloud Storage security rules. Specifically in our rules everything after the "if" is Common Expression Language. See: https://firebase.google.com/docs/firestore/security/rules-co... The efficiency and safety of CEL enables us to put security rules in the critical path of every database request.
“this is the language that powers Cloud Firestore / Cloud Storage security rules”
This really needs to be stated on its front page. Right now it’s all “Hows” and no “Why”.
First question anyone looking at it asks: What problem does it solve?/What need does it fill? A real-world use case provides an easy relatable answer.
Incidentally, with existing links to protobuf and no halting problem to worry about, it sounds like you’re halfway to having a remote query language a-la SQL too.
https://www.researchgate.net/publication/221553413_Safe_Quer...
Re: Common Expression Language
#89Googler here: for those of you who have ever used Firebase this is the language that powers Cloud Firestore / Cloud Storage security rules. Specifically in our rules everything after the "if" is Common Expression Language. See: https://firebase.google.com/docs/firestore/security/rules-co... The efficiency and safety of CEL enables us to put security rules in the critical path of every database request.
“this is the language that powers Cloud Firestore / Cloud Storage security rules” This really needs to be stated on its front page. Right now it’s all “Hows” and no “Why”. First question anyone looking at it asks: What problem does it solve?/What need does it fill? A real-world use case provides an easy relatable answer. Incidentally, with existing links to protobuf and no halting problem to worry about, it sounds li…
I actually looked at this thinking it was pretty cool and could come up with usecases immediately–it is a great way to do simple query/matching in a consistent way. If I'm not mistaken, this could be used for something like Gmail's advanced search? There are tons of interfaces where everyone designs their own ad-hoc expressions and having something like this would be very useful in those cases.
Re: Common Expression Language
#90The creator of Apache Ant, James Duncan Davidson, wrote about choosing XML as the “language”:
> Now, I never intended for the file format to become a scripting language—after all, my original view of Ant was that there was a declaration of some properties that described the project and that the tasks written in Java performed all the logic. The current maintainers of Ant generally share the same feelings. But when I fused XML and task reflection in Ant, I put together something that is 70-80% of a scripting environment. I just didn't recognize it at the time. To deny that people will use it as a scripting language is equivalent to asking them to pretend that sugar isn't sweet.
https://web.archive.org/web/20041217023752///x180.net/Journa...