[anothernewdude]

It is a bit telling those were the best reasons they could think of for lack of adoption. Just "ignorance".

Not we thought that maybe specifying a DSL rather than a library would leave our users and clients in a state of having to banadage over the constraints of a DSL that doesn't handle future use cases, like say dealing with control flow in a half-assed YAML based language, I'm looking at you Ansible.

I don't want MAKE, or whatever DSL, I want to be able to drop into a real programming language when necessary. So libraries. Not frameworks, Not DSLs, libraries.

And thankfully, it seems the world agrees with me.

[rualca]

> I don't want MAKE, or whatever DSL, I want to be able to drop into a real programming language when necessary. So libraries.

That's one opinion, sure.

However, DSLs are always in a far better position to solve domain-specific problems because, unlike generic programming libraries, they not only reflect domain-specific knowledge and best practices and represent standardized solutions for recurring problems.

Consequently, Makefiles and other DAG-related DSLs are omnipresent and dominate domains such as build systems, and generic library-based proposals always failed to gain any form of traction.

And it's not just Makefiles or build systems. There's also markup languages, infrastructure as code, CICD/processing pipelines, configuration, etc etc etc.

[cle]

It’s funny you mention the latter, I’ve seen an industry-wide trend toward using standard programming languages with those things (Pulumi, CDK, et al). I’ve started using them myself. I’m not convinced yet that they’re better.

Gradle seems to be an interesting case of a successful build system with an interface in a real language (Groovy), although Groovy is so dynamic that the line between Groovy and DSL is pretty blurry.

I think another big issue is the generally terrible interop between programming languages, each language has a silo of excellent libraries and the only way to move things between silos is with unsophisticated data formats.

I’ve also made a handful of developer libraries and always pick a cludgy data format for configuration, the ergonomics are quite nice—it’s easy to reason about as a user (no head scratching about what the config will look like at “runtime”), there’s generally no tooling setup required and no additional compilers or interpreters to install, and I’m free to use whatever languages as a tool designer I like and can move freely between them (at this point they all support YAML, JSON, et al). We want to make the barrier to entry as low as possible and simple data formats do just that.

[rualca]

> I’ve seen an industry-wide trend toward using standard programming languages with those things (Pulumi, CDK, et al).

I can't really talk about Pulumi, but CDK is just a high-level CloudFormation generator, and arguably one whose only usecase is to serve as an ad-hoc template engine, much like SAM.

CDK is currently one of 3 or 4 offerings from Amazon that handle the same usecase, thus it's strange that you decided to refer to it as an industry trend when at most is a cherry-picked example.

Meanwhile, should we ignore how the entire industry, from Kubernetes to Docker Swarm and passing through Ansible and Chef and whatever other tools, runs on tools that use domain-specific languages?

> Gradle seems to be an interesting case of a successful build system (...)

...yet it's market share is completely eclipsed by the dominant tool, Maven, in spite of Android's push.