Some people prefer some things just because they haven't learned a better way, but if you show them a better way, they'd gladly use it. I think the mission of a product designer should be to see through what the user thinks they need, and provide something that solves their real problem in the best way.
In the case of IaC, what the customer really wants is a programmatic way to generate instructions for Pulumi to use to build infrastructure. The dream of "declarative" anything is to explain what you want and have a machine make it reality, right? But in practice that's hard to do. The machine needs to be very, very smart.
But it's not that smart. So we cheat and invent non-programming-languages, so that people end up telling the machine in far too much detail what they want. Do I really want to tell the machine to "go in a loop creating resources as long as there are resources in a list" ? Or do I really want to do some other thing, and making these resources should just be an incidental part of that that I shouldn't have to explain at all?
Programmers who like YAML for anything other than pure data serialization don't actually like YAML, they just like that they can cheat with it. No need to write a configuration format if you read your configuration from it. No need to write a DSL if you execute logic based on it. The programmers who don't like YAML wanted to do the same things, but were bitten by all the problems that came from using the wrong thing for the wrong purpose.
So really, the product person and experienced engineer need to work together to prevent this whole situation from ever occurring. Create a schema, and create libraries that can generate YAML based on the schema, but do it in such a way that no human would ever want to edit it by hand, and too complicated to ever write a generator for it without the schema. This way the customer can't shoot themselves in the foot, or demand changes which would make everything worse.
You're speaking my language here, FWIW. I just think that the market for IaC is big enough for a product to have its cake and eat it too. Doing that well is extremely challenging, though.
In the case of IaC, what the customer really wants is a programmatic way to generate instructions for Pulumi to use to build infrastructure. The dream of "declarative" anything is to explain what you want and have a machine make it reality, right? But in practice that's hard to do. The machine needs to be very, very smart.
But it's not that smart. So we cheat and invent non-programming-languages, so that people end up telling the machine in far too much detail what they want. Do I really want to tell the machine to "go in a loop creating resources as long as there are resources in a list" ? Or do I really want to do some other thing, and making these resources should just be an incidental part of that that I shouldn't have to explain at all?
Programmers who like YAML for anything other than pure data serialization don't actually like YAML, they just like that they can cheat with it. No need to write a configuration format if you read your configuration from it. No need to write a DSL if you execute logic based on it. The programmers who don't like YAML wanted to do the same things, but were bitten by all the problems that came from using the wrong thing for the wrong purpose.
So really, the product person and experienced engineer need to work together to prevent this whole situation from ever occurring. Create a schema, and create libraries that can generate YAML based on the schema, but do it in such a way that no human would ever want to edit it by hand, and too complicated to ever write a generator for it without the schema. This way the customer can't shoot themselves in the foot, or demand changes which would make everything worse.