[baq]

I hate yaml with a passion. It marginally better than xml for reading (wins huge on comment syntax) and worse for everything else. It makes zero sense we somehow ended up with it as standard configuration serialization format.

Note yaml is not a DSL. It's a tree serialization format! Everything interesting is happening after it is parsed. Extreme examples point to e.g. github actions conditions.

Anyway, back on topic - maybe not prolog for CDK, but still quite interesting: Dhall-kubernetes - https://github.com/dhall-lang/dhall-kubernetes

[eternityforest]

Better than making your own syntax for a declarative system, that now needs custom tools.

I'd prefer it to lisp, and to JSON if I have to hand read or write it.

What's the alternative, besides specifying your declarative stuff inside something like Python?

[baq]

I agree. For some things yaml is good enough. XML, JSON and s-exprs are also good enough. Everything is good enough until it isn’t. At that point your configuration becomes code becomes configuration becomes code you know the drill.

My point is that the more complex use cases like GitHub actions conditions invent their own DSLs in yaml string values anyway because nobody wants to write in a half broken lisp but in yaml instead of s-exprs, so suddenly you’re writing yaml but with JavaScript. Might as well start out with JavaScript and not pretend it’s a simple declarative language when it clearly isn’t. CDK people clearly saw that, not sure if execution is optimal, but at least the general purpose tooling works (libraries, types, tests, IDEs, etc).

[eternityforest]

I'd rather we just stop trying to be unixy and support every workflow instead of just having a large but fixed set of things.

Like, GitHub actions could afford to crappy if you rarely had to deal with them. It would be better if you did in fact have JS...

But GH actions take multiple minutes to run, and a linter is near instant.

A less powerful solution would be saying "Here's some prefab instant actions that don't spin up a new container, just tell us what paths to include in for this linter and this formatter and click this box, and since we control it we can optimize it and fix the bugs and all that".

People invent DSLs instead of just exposing code often because they want it to be easy and expressive, but they make the easy things moderately hard, and the hard things near impossible.

But if the easy common things are just built in, you don't need any DSL at all, and you're not tempted to, because you just say "We cover common stuff already, if you want to do weird stuff we have Python for that".

But for some reason programmers would rather spend 10x the effort on a custom system rather than implement a specific common feature, because they want everything to be like a math equation, a description of something general.

Back in the early desktop era, adding stuff just because X fraction of users want it seemed to be all the rage, now people add things based on whether it fits with a vision or an idea.