[jen20]

CDK for Prolog would be quite the trip.

As it turns out, what matters is whether the model is declarative. As some uses of YAML go to show, declarative vs not is an orthogonal axis to how general purpose or otherwise a language is, and orthogonal again to whether it looks like a configuration file or code.

[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.

[OhMeadhbh]

CDK for Prolog sounds sick and disgusting. I LIKE IT!

I'm a little more familiar with DSLs w/ Lisp, but I built a simple make replacement with Prolog a few decades ago and it turned out to be useful. Replacing CloudFormation or TerraForm with a Prolog based DSL seems like it could be a win. I like Prolog much more than Pulimi in this role as you can succinctly and unambiguously declare dependency relations.

[jen20]

> I like Prolog much more than Pulimi in this role as you can succinctly and unambiguously declare dependency relations.

Prolog for Pulumi is an absolutely doable thing - and indeed sounds sufficiently diabolical that someone should do it ;-)

[OhMeadhbh]

Or even Prolog w/ the AWS CDK. Hmm.. that might even be a business.

[jen20]

It's probably not a business... someone will just fork it ;-)

[ljm]

I could see a prolog based solution being quite powerful if used to its advantage.

Someone would say…why not hold your state in SQLite and make it queryable that way? And it would be fair. But nowhere near as exciting a problem.

[OJFord]

Yes I absolutely wasn't saying declarative means not GP or vice versa, that was really my only point: I don't mind a terraform alternative that uses (or if terraform switched to) a general purpose language as opposed to 'DSL', if we can call the current incarnation that, as long as it (the GP language) is declarative.