Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Expression Language

github.com

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Common Expression Language

#101

Post by alfnoodles »

dathinab wrote: post #100
alfnoodles wrote: post #95

Earlier quoted context omitted.

Go on... :-). Why don't you like them?

Nesting them can lead to very not-so-easy to understand logical expressions, furthermore if the parts between ?: is long enough it can also noticeable reduce readability. Instead of ` ? : ` I prefer `if { } else { }` the additional brackets noticeable improve readability and you can extend it to support `if { } else if { } else { ` instead of ` ? : ? : `. (Oh and that last example might be wrong needing brackets depe…

Ah. The biggest difference between ?/: and if/else is that ?/: is an expression (returns a value) and if/else are statements (a step/command/declaration/etc). You can build statements on top of CEL (lots do), but the core Common Expression Language (CEL) doesn't actually have them.

Note that python uses if/else for the ternary expression form as well: `a = b if c else d`

Though personally, I like to have the condition in the front, instead of in the middle.

Re: Common Expression Language

#102

Post by blandflakes »

otabdeveloper4 wrote: post #78
didip wrote: post #10

Earlier quoted context omitted.

I am with you, I wish the world would just adopt Lua as their config files.

Then you'll need config files for your config files, and we're back to square one. The scope and capabilities of the config language needs to be limited, otherwise we lose the ergonomic benefits of configuration in the first place.

I sort of agree with this, except that I don't think it's square one. The ability to change config without rebuilding your artifact is one of the advantages of separate config files, and using an embedded language like lua wouldn't remove this advantage.

Re: Common Expression Language

#103

Post by nojvek »

sbarzowski wrote: post #94
nojvek wrote: post #93

If you’re constantly fighting yaml, consider jsonnet. It’s another project by google and similarly not Turing complete. Works wonderful at generating templates.

Well, actually Jsonnet is Turing complete. Anyway, thanks for the shoutout.

TIL. AFAIK jsonnet can’t do while loops so I assumed it wasn’t Turing complete and I didn’t see a way of writing a non-halting program.

But now I see, since it has recursion, there are tricks to make it go in an infinite loop.

Thanks for the pointer. I read the rationales again in the doc.

Re: Common Expression Language

#104

Post by st1ck »

alfnoodles wrote: post #101
dathinab wrote: post #100

Earlier quoted context omitted.

Nesting them can lead to very not-so-easy to understand logical expressions, furthermore if the parts between ?: is long enough it can also noticeable reduce readability. Instead of ` ? : ` I prefer `if { } else { }` the additional brackets noticeable improve readability and you can extend it to support `if { } else if { } else { ` instead of ` ? : ? : `. (Oh and that last example might be wrong needing brackets depe…

Ah. The biggest difference between ?/: and if/else is that ?/: is an expression (returns a value) and if/else are statements (a step/command/declaration/etc). You can build statements on top of CEL (lots do), but the core Common Expression Language (CEL) doesn't actually have them. Note that python uses if/else for the ternary expression form as well: `a = b if c else d` Though personally, I like to have the conditio…

if/else doesn't have to be a statement:

    max = if a
You may also like `jq` syntax with `elif`s:

    if cond1 then res1 elif cond2 then res2 ... else res end

Re: Common Expression Language

#105

Post by boublepop »

lmm wrote: post #56
derefr wrote: post #42

Earlier quoted context omitted.

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…

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…

> It's how a lot of e.g. Python projects are configured - the "config" file is just a normal bit of code that gets run to produce a value.

Which is the root of a ton of different problems and issues and generally regarded as a bad idea. See pep518 and pyproject.toml vs setup.py

Re: Common Expression Language

#106

Post by acm1899 »

partialstate wrote: post #97

The goal of CEL is fast, scalable, and portable expression evaluation. Fast - CEL runs without the need for sandboxing, making it much faster than sandboxed solutions like WebAssembly, Lua, and embedded JavaScript. Scalable - Features like variables and functions would make CEL more expressive, but also less scalable as it's easy to write a few lines of code with functions that consume exponential amounts of memory a…

Can you please share more on "Java open sourcing in development"? Any release plan?

I am also interested to contribute.

Re: Common Expression Language

#107

Post by emn13 »

derefr wrote: post #92
emn13 wrote: post #83

Earlier quoted context omitted.

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…

> In most programming languages you can hand author a value just fine But keep in mind that we’re not inherently talking about programming languages here — nor are we necessarily talking about people capable of programming as our configurators. We’re talking about third-party components that need to be configured by ops people, who may or may not be DevOps people. Usually they’re not — most ops people are just pure o…

Yeah, there's something to be said to a format that makes it hard to shoot yourself in the foot; essentially. That point is somewhat orthogonal to the issue of how easy it is to author a config value, however.

By the way, you conflate purity with turing completeness; but the two are not really all that strongly related. It's possible to have a turing incomplete language that is nevertheless impure (public I/O without unconstrained repetition), and conversely a turing complete language that is pure (i.e. keep your tape private).

I'd argue that turing completeness isn't as relevant as people make it out to be here. It's not a good thing, mind you, but it's just not that problematic either; externally imposed termination and storage limitation can render any turing complete system into a turing incomplete system - that's easy - but a system with uncontrolled sideeffects is almost intrinsically hard to manage. In fact, even technically turing-incomplete systems may well need to impose similar limitations anyhow, because a technically turing incomplete language that allows (say) nested loops or iteration - albeit bounded - may well not practically terminate, or nevertheless cause too much I/O. Some languages are really limited, and perhaps then you can get away without externally imposed resource constraints, but it's not clear to me how realistic that scenario is.

The real problem (to my mind) in general-purpose languages when it comes to using them for config-specification is not turing completeness, it's purity (i.e. reproducibility). And that's not even really a language issue alone, it's because those languages tend to come with large, pervasively used libraries, to the point that it's not trivial to just take some code off stackoverflow (say) and reliably tell whether it's pure or not - because that depends on the internals of all of those library methods too.

Re: Common Expression Language

#108

Post by lmm »

emn13 wrote: post #107
derefr wrote: post #92

Earlier quoted context omitted.

> In most programming languages you can hand author a value just fine But keep in mind that we’re not inherently talking about programming languages here — nor are we necessarily talking about people capable of programming as our configurators. We’re talking about third-party components that need to be configured by ops people, who may or may not be DevOps people. Usually they’re not — most ops people are just pure o…

Yeah, there's something to be said to a format that makes it hard to shoot yourself in the foot; essentially. That point is somewhat orthogonal to the issue of how easy it is to author a config value, however. By the way, you conflate purity with turing completeness; but the two are not really all that strongly related. It's possible to have a turing incomplete language that is nevertheless impure (public I/O without…

> and conversely a turing complete language that is pure (i.e. keep your tape private).

A Turing complete language can't be pure because there is no value that is equivalent to a nonterminating computation.

Re: Common Expression Language

#109

Post by emn13 »

lmm wrote: post #108
emn13 wrote: post #107

Earlier quoted context omitted.

Yeah, there's something to be said to a format that makes it hard to shoot yourself in the foot; essentially. That point is somewhat orthogonal to the issue of how easy it is to author a config value, however. By the way, you conflate purity with turing completeness; but the two are not really all that strongly related. It's possible to have a turing incomplete language that is nevertheless impure (public I/O without…

> and conversely a turing complete language that is pure (i.e. keep your tape private). A Turing complete language can't be pure because there is no value that is equivalent to a nonterminating computation.

That's irrelevant right? The point is that it's reproducible. Whether you define purity as to include non-termination or not is besides the point; the point is to avoid side-effects. Lack of side effects matters in the context of configuration, non-termination does not (and see the thread you're replying to for an argument as to why that is). That's kind of the whole point of the argument.

Re: Common Expression Language

#110

Post by lmm »

emn13 wrote: post #109
lmm wrote: post #108

Earlier quoted context omitted.

> and conversely a turing complete language that is pure (i.e. keep your tape private). A Turing complete language can't be pure because there is no value that is equivalent to a nonterminating computation.

That's irrelevant right? The point is that it's reproducible. Whether you define purity as to include non-termination or not is besides the point; the point is to avoid side-effects. Lack of side effects matters in the context of configuration, non-termination does not (and see the thread you're replying to for an argument as to why that is). That's kind of the whole point of the argument.

> That's irrelevant right? The point is that it's reproducible.

It's not reproducible if it's not a value. The point of a pure function is that you can replace it with the value that it evaluates to.

If you include nontermination as a value in your language then your language becomes almost impossible to reason about as you break almost every equivalence property you could think of. E.g. you can no longer say x * 0 = 0.

> Lack of side effects matters in the context of configuration, non-termination does not (and see the thread you're replying to for an argument as to why that is).

I don't find "but terminating code may still take a long time" to be a convincing argument that nontermination isn't important; rather it's an argument that code taking a long time might also be important (at least to the extent that it actually comes up in practice, which I'm not convinced of).

Post reply on HN