> Another example of this DSL model done mostly-right is Make.
I think you just internalized the pain of make. I used to be good at it, didn't program c for 20 years and came back to it for a few projects and wanted to tear my hair out.
The pls I'm currently working with have declarative build dsls in the same language (mix.exs for elixir and build.zig for zig) and this is fantastic.
So it should be for configs. Use a truly turing complete language if you need control flow. I think hashicorp got this right but by then everyone hated to have to learn ruby.
I think this is the real reason why yaml configs got popular. If you had a dsl in x language, programmers would get defensive that it was in blub and not their pl of choice. Yaml was a way of being a language agnostic neutral ground.
Regarding not wanting to learn Ruby, I wonder how much of the inertia is installation. I mean, some people seem to have visceral reactions to the syntax (I've even seen people say they dislike Elixir because it's like Ruby ). But the lesson I took away from using Ruby DSLs is users don't want to deal with figuring out how to safely install a new version without borking the system version, segregate workspaces, install packages, etc. Python suffers from that too but for some reason we all ignore it, maybe because a lot of people consider it a newbie or "easy" language and complaining about it would make them seem like "not a real programmer".
oh 100% specifically re: hashicorp using ruby, there was definitely a time between 1.8 and 2.x where installing ruby was a nightmare. That's when i quit using ruby! Even though I loved ruby. And when I saw hashicorp products using Ruby as their DSL a part of me was worried it was not a good choice for those reasons.
Python ecosystem definitely suffers from this. I tried to do some machine learning experiments and basically all of the repos I wanted to use were on 2.x and after 30 minutes of faffing around I gave up and moved onto other packages. However, the biggest pain points for Python came in the 2-3 transition (and TensorFlow x->y in general). By then Python had too much momentum and popularity (and every undergrad learns python). TensorFlow, well at least there is a competitor (torch) and so we see that TF's popularity has basically been sucked dry, and I have no doubt that a large portion of it is just how awful Google+Nvidia have been in managing the TF releases.
I think you just internalized the pain of make. I used to be good at it, didn't program c for 20 years and came back to it for a few projects and wanted to tear my hair out.
The pls I'm currently working with have declarative build dsls in the same language (mix.exs for elixir and build.zig for zig) and this is fantastic.
So it should be for configs. Use a truly turing complete language if you need control flow. I think hashicorp got this right but by then everyone hated to have to learn ruby.
I think this is the real reason why yaml configs got popular. If you had a dsl in x language, programmers would get defensive that it was in blub and not their pl of choice. Yaml was a way of being a language agnostic neutral ground.
And now we have n+1 blubs.