9 ms·

I love this article, but I also hate that Pulumi has created yet another bad DSL using YAML. One day, somebody in charge of product design will also be a good e

I love this article, but I also hate that Pulumi has created yet another bad DSL using YAML. One day, somebody in charge of product design will also be a good engineer, and the crazy shit customers ask for will not end up a terrible feature. Until that day...

oneplane 4y ago
It's a bit of an XKCD where they keep re-inventing YAML-based DSLs. We have weird "native" YAMLs for AWS, GCP and Azure, and then YAML DSLs to generate those YAML DSLs. Even SaltStack and Ansible do it... It's almost like someone had a bad idea and put XKCD and Xzibit in a blender...
- chupasaurus 4y ago
  Ansible even states that it doesn't have DSL while it actually is when you go to the rabbit hole deep enough.
  - deathanatos 4y ago
    … you don't have to but peer slightly into that rabbit hole; your first example Ansible playbook should very clearly demonstrate it has a DSL…
throwaway894345 4y ago
All of this IAC crap was sold to barely-tech-literate engineering managers as “declarative makes the complexity go away!” so every IAC vendor wed themselves to YAML or HCL or JSON, but of course the complexity doesn’t go away and so the vendors came up with increasingly absurd ways to DRY up this YAML (text templates a la Helm or encoding a DSL into your config language a la Terraform and CloudFormation). Eventually people realized this was madness and what’s really needed is a programming language that can resolve to these static manifests, so these vendors in their zeal to forever misunderstand the assignment came out with CDKs so we can compile source code to YAML with a whole bunch of pointless inheritance to really make a mess of things.
- datalopers 4y ago
  It’s okay they’ll all be unemployed by Christmas 2023 and we’ll look back on this tech boom with “maybe we should have solved business problems instead of spending all our time rewriting from one devops tooling to the next?”
  - Jenk 4y ago
    That claim is more absurd than those you mock.
    - datalopers 4y ago
      This tech bubble already popped a leak (Nov 2021) and is deflating rapidly. There’s enough runway to last another year or two. Down-rounds and lay-offs are coming fast. Companies with ample cash will be fine, of course, but all these spurious startups with egregious VC funding, overpaid Pulumi and Kubernetes and <insert all the other unnecessary tech> engineers will soon be out of work and unable to find similar employment comp. People who get shit done and can run lean profit driven businesses will continue to survive just fine.
      - mardifoufs 4y ago
        We've been hearing the same exact thing since at least 2013. I remember when 2015 was going to be the next huge tech crash, but nothing happened.
        baq 4y ago
        stop listening to cnbc, start looking at the numbers. shit's gone really bad really fast and it's only starting. first signs of weakness in LQD, HYG and JNK have been there since december and it's been straight down from there. stay aware.
        datalopers 4y ago
        https://en.wikipedia.org/wiki/Dot-com_bubble https://en.wikipedia.org/wiki/Dot-com_bubble > Low interest rates in 1998–99 facilitated an increase in start-up companies > In 2000, the dot-com bubble burst, and many dot-com startups went out of business after burning through their venture capital and failing to become profitable. Sound familiar? It should, because history rhymes.
Jenk 4y ago
You guys will just love the shared mentality on /r/DevOps. Apparently YAML is the one true declarative language that all others are failing to imitate. I'm literally Judas for preferring to use typescript with pulumi.
- baq 4y ago
  i hate yaml more than xml and that is saying something. i get looked at strange when i say this loudly, like i'm from mars or whatever. it's like being in a collective hallucination where you know you're right and everybody else is wrong and nothing makes sense anymore. i've tried to fight this by leading by example with https://dhall-lang.org/ https://dhall-lang.org/ but apparently having a configuration compiler is too much... unless the compiler takes yaml as input, then it's fine.
phillipcarter 4y ago
why-not-both.jpg? I hate yaml as much as the next developer, but I've met plenty of folks who far prefer it to using a "real" language. Different strokes for different folks? The challenge from a product standpoint is how to balance these different ways to do something without (a) ostracizing one group, and (b) creating a confusing mess on the "get started" path.
- 0xbadcafebee 4y ago
  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.
  - phillipcarter 4y ago
zozbot234 4y ago
This article gets one thing right: if you're going to autogenerate something as complex as YAML, you'll really, really want to stick to a sane subset of the underlying language (here, JSON).
phlakaton 4y ago
It's a trade-off. In exchange for a hair-tear-outable user experience, you get the ability to (relatively) easily load and transform that data, which gives you lots of automation and integration options. It's not unlike LISP's predilection for sexpr-based DSLs, I suppose.

oneplane 4y ago

It's a bit of an XKCD where they keep re-inventing YAML-based DSLs. We have weird "native" YAMLs for AWS, GCP and Azure, and then YAML DSLs to generate those YAML DSLs. Even SaltStack and Ansible do it... It's almost like someone had a bad idea and put XKCD and Xzibit in a blender...

chupasaurus 4y ago
Ansible even states that it doesn't have DSL while it actually is when you go to the rabbit hole deep enough.
- deathanatos 4y ago
  … you don't have to but peer slightly into that rabbit hole; your first example Ansible playbook should very clearly demonstrate it has a DSL…

throwaway894345 4y ago

All of this IAC crap was sold to barely-tech-literate engineering managers as “declarative makes the complexity go away!” so every IAC vendor wed themselves to YAML or HCL or JSON, but of course the complexity doesn’t go away and so the vendors came up with increasingly absurd ways to DRY up this YAML (text templates a la Helm or encoding a DSL into your config language a la Terraform and CloudFormation). Eventually people realized this was madness and what’s really needed is a programming language that can resolve to these static manifests, so these vendors in their zeal to forever misunderstand the assignment came out with CDKs so we can compile source code to YAML with a whole bunch of pointless inheritance to really make a mess of things.

datalopers 4y ago
It’s okay they’ll all be unemployed by Christmas 2023 and we’ll look back on this tech boom with “maybe we should have solved business problems instead of spending all our time rewriting from one devops tooling to the next?”
- Jenk 4y ago
  That claim is more absurd than those you mock.
  - datalopers 4y ago
    This tech bubble already popped a leak (Nov 2021) and is deflating rapidly. There’s enough runway to last another year or two. Down-rounds and lay-offs are coming fast. Companies with ample cash will be fine, of course, but all these spurious startups with egregious VC funding, overpaid Pulumi and Kubernetes and <insert all the other unnecessary tech> engineers will soon be out of work and unable to find similar employment comp. People who get shit done and can run lean profit driven businesses will continue to survive just fine.
    - mardifoufs 4y ago
      We've been hearing the same exact thing since at least 2013. I remember when 2015 was going to be the next huge tech crash, but nothing happened.
      - baq 4y ago
        stop listening to cnbc, start looking at the numbers. shit's gone really bad really fast and it's only starting. first signs of weakness in LQD, HYG and JNK have been there since december and it's been straight down from there. stay aware.
      - datalopers 4y ago
        https://en.wikipedia.org/wiki/Dot-com_bubble https://en.wikipedia.org/wiki/Dot-com_bubble > Low interest rates in 1998–99 facilitated an increase in start-up companies > In 2000, the dot-com bubble burst, and many dot-com startups went out of business after burning through their venture capital and failing to become profitable. Sound familiar? It should, because history rhymes.

Jenk 4y ago

You guys will just love the shared mentality on /r/DevOps. Apparently YAML is the one true declarative language that all others are failing to imitate. I'm literally Judas for preferring to use typescript with pulumi.

baq 4y ago
i hate yaml more than xml and that is saying something. i get looked at strange when i say this loudly, like i'm from mars or whatever. it's like being in a collective hallucination where you know you're right and everybody else is wrong and nothing makes sense anymore. i've tried to fight this by leading by example with https://dhall-lang.org/ https://dhall-lang.org/ but apparently having a configuration compiler is too much... unless the compiler takes yaml as input, then it's fine.

phillipcarter 4y ago

why-not-both.jpg? I hate yaml as much as the next developer, but I've met plenty of folks who far prefer it to using a "real" language. Different strokes for different folks? The challenge from a product standpoint is how to balance these different ways to do something without (a) ostracizing one group, and (b) creating a confusing mess on the "get started" path.

0xbadcafebee 4y ago
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.
- phillipcarter 4y ago

zozbot234 4y ago

This article gets one thing right: if you're going to autogenerate something as complex as YAML, you'll really, really want to stick to a sane subset of the underlying language (here, JSON).

phlakaton 4y ago

It's a trade-off. In exchange for a hair-tear-outable user experience, you get the ability to (relatively) easily load and transform that data, which gives you lots of automation and integration options. It's not unlike LISP's predilection for sexpr-based DSLs, I suppose.