[OJFord]

I think calling terraform a DSL in comparison to general purpose programming languages misses the point. If it used a declarative GPPL instead of HCL I wouldn't care, but imperative alternatives general purpose or not are 'a waste of time' & not fit for the domain, IMO.

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

[gregmac]

Pulumi is an example that proves the exception: using a general purpose language, you create a declaration of desired state.

Think of it like if you used a GPPL to emit HCL. You get the power of that language: loops, function calls, unit tests, or even the ability to call external APIs. You're declaraing desired state and letting the framework sort it outb which is you say you aren't writing imperative code like:

    if (!exists(dnszone)) create(dnszone);

[OJFord]

I didn't name it, but Pulumi's the main (multiple) GPPL alternative I was thinking of. I don't think emitting/compiling to something declarative makes it any better; maybe if you normalised that being the key checked-in thing, a bit like a lockfile, but which people really checked and cared if it changed, more so in a way than the source.

I want to write and review declarative, not compiles-to-declarative.

[AaronFriel]

Hey, Pulumi engineer here.

The engine doesn't compile to a declarative template. It's a common misconception, however because the user's program runs concurrently with the Pulumi engine, fully dynamic resource graphs are possible, including those inexpressible using templates.

This is Pulumi pseudocode:

    const group = new ldap.DirectoryGroup("$saas-users);

    // or any other runtime query:
    for (const member of group.getMembers()) {
      new saas.User(member.id, {
          email: member.email,
          name: member.fullName,
      });

      // could also do some other dynamic action, such as 
      // calling a webhook to complete user setup

And in ~10 lines of code you have a script or webhook you can use in situations where SCIM would normally be required.

(n.b.: this is a simplified, illustrative example that the program drives the graph using its own using loops or other control flow.)

[OJFord]

Ok. I've never actually used Pulumi, I was responding to GP's description. Personally I want declarative for IaaC; some here are advocating for imperative generation of declarative IaaC (and claiming Pulumi as an example), which I think is barely an improvement (but nevertheless..) over imperative IaaC.

[ec109685]

That’s the key. Declarative converging systems so much better than imperative and all the edge case handling necessary.

[OhMeadhbh]

Sure. But some people don't want to do that.

[tekla]

Some people like to overcomplicate things but that's not a reason to care.

[OhMeadhbh]

Sure. But some people don't want to do that.