7 ms·

I learned to stop worrying and don't really care, I'll happily use xml, json, yaml or toml . To me, it doesn't really make a lot of difference, and yes, there

I learned to stop worrying and don't really care, I'll happily use xml, json, yaml or toml . To me, it doesn't really make a lot of difference, and yes, there are a bunch of reasons why various formats have different advantages, but it really doesn't take much of my life, things don't really go wrong with any of them, and while I have a preference, pragmatically, I just don't care.

xcambar 4y ago
In a team of engineers, find one that complains about the configuration formats or linting rules, and with 100% confidence, you know who will ruin your meetings. Source: empirical study from me Thanks for not being that person.
- ResearchCode 4y ago
  The one that sent out the invitation
- IshKebab 4y ago
  I'm that person and I don't ruin meetings. I find it's the opposite - there are one or two people that obstinately refuse to allow any improvements and derail meetings with endless naysaying and stuck-in-the-muddery. It's wearing.
  - JonChesterfield 4y ago
    Beware the cost of those improvements. I never want to have another discussion about whitespace layout.
    - carlmr 4y ago
      I'll accept 2, 4, 8 spaces or tabs, but it should be consistent.
      - xcambar 4y ago
        Here's my rule of thumb: * for new projects, use a well-established, reputable standard * for existing projects, use what is already in place if it is consistent * in case of inconsistency, fix to the closest industry standard
        bschwindHN 4y ago
        My favorite: * Use an auto-formatter and enforce it in CI
        IshKebab 4y ago
        Yeah this is what I was trying to enact. They had sort of done that but the autoformatter had been broken for years and they wouldn't let me fix it and reformat everything.
        WorldMaker 4y ago
        Git supports revision ignore files for tools like git praise/blame, so that excuse that they don't want to reformat everything to avoid git praise blowout can be easily worked around by checking in an ignore revisions file and pointing them how to use it. Github even has public beta support for it, though they require a specific name for the ignore revs file: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view https://docs.github.com/en/repositories/working-with-files/u...
      - abdouls 4y ago
        Definitely, as long as it's consistent - I personally like to go for 4 spaces everywhere, I would say it makes the code look easy and readable.
        carlmr 4y ago
        Me, too, it's the default for almost every editor and code formatter. That makes it the most likely choice for projects. But if this project made a weird decision I'm ok with it, as long as it's enforced consistently.
- hotpotamus 4y ago
  I can't say that I've ever complained about any one of the rules; it's the constant churn of them that drives me insane.
- make3 4y ago
  that's the thing, i wish yaml was just a config format, that it does other weird shit like calling functions is the problem
  - xcambar 4y ago
    The article makes excellent points on this very topic.
gorgoiler 4y ago
The “code” rot creeps in over the years. Especially so if you work with a lot of people on the team. If they view the infrastructure-as-“code” parts of the project as somehow lesser in stature than the rest of the actual code, then they more than likely see the YAML as a legitimate place to make drive-by tweaks without much care for “code” quality. Because they are programmers though, they might actually try to make the “code” better: First they refactor everything using ‘extends:’ to use inheritance for infrastructure “code” sharing. Then they started sharing “code” between blocks by using YAML references. This removes duplication, except for the edge cases that need to be different. Hmmm. Then the YAML file became a Jinja / Jsonnet / M4 / C-preprocessed template. That means there’s now another programming language involved so on the upside there’s some hope of finally being able to express computation, but with the downside that it somehow plays second fiddle to the YAML despite the latter having nothing to do with computation. The downsides of trying to prematurely capture your ideas as config are real. If you don’t focus on all of the key variation points you’re going to see people start hacking and templating at some point. It’s inevitable. I like how Ansible didn’t even try to avoid templating and ran with it straight off the bat. Config DSLs are hard. OpenSMTPD’s is beautiful but they didn’t get it right until version 6. Even then I bet some people are generating the config. Caddy’s dual approach of letting you use their DSL or give it generated JSON is nice. They have a config DSL for the use cases they could think of, but recognise that there will probably be other cases they didn’t think of, and so support you calling their API with machine built configs instead. Configuring a system with a programming language is difficult too. If you had a Python module to set up Apache, and your config was particularly lengthy, you can guarantee someone on your team is going to come up with a “clever” abstraction at some point via a pull request that links to the DRY Wikipedia page. It’s just that with Python etc — vs YAML “programming” in “code” — they are more likely to actually get it right.
- TobTobXX 4y ago
  VimL carries its scars from this process. At first just a configuration DSL for settings, nowadays the language truly sophisticated plugins are written in. I'm not decided whether I'd want something vim-like for infra as code. On one hand, in VimL, simple things remain simple and complex things are possible, alas you could say perfect design. On the other hand, everyone who has programmed something non-trivial with vim knows the pain.
resonious 4y ago
Not to derail too much from the original article, but I've been starting to feel the same about entire tech stacks. Building CRUD apps is annoying no matter what. Every time a framework makes one thing easy, it makes a couple of other things hard. No matter what tech you're using, there are some generalizable skills that are indispensable for project longevity: good testing, organization of files, consistency in concepts, and thoughtful comments that tell you why things are the way they are. The idea that we can replace skillful software engineering with the right abstraction just hasn't panned out for me.
- thehappypm 4y ago
  Mechanical engineers don’t attempt to have “one part that does everything”. Maybe we should think more like them.
  - chii 4y ago
    well, they don't have a silver bullet part, but there are standardized components like screws, gears, levers etc. It's just that mechanical engineering is constrained by physical laws, and that gives design constraints that don't exist in software.
    - wtetzner 4y ago
      Standardized parts sound a lot like libraries implementing common interfaces.
  - carlmr 4y ago
    Libraries over frameworks. It's that simple. Frameworks always make something hard the initial authors didn't think about. That happens a lot. Libraries provide some small set of well-tested functionalities, which you can replace if they don't serve you well. Every framework I've worked with had some issues, and because it's a framework it becomes a herculean effort to switch to something else. If it's only a single functionality that's much easier.
    - 4y ago
CipherThrowaway 4y ago
This feels tangential to the article. The article doesn't situate YAML against XML, JSON, TOML etc but against general purpose languages. The differences between the configuration approach and the GPL approach are pretty substantial compared to the differences between individual config formats.
- rich_sasha 4y ago
  To me that is the axis of discontent though. To me the badness is something like: - just want a static unconditional config -> YAML - ah but I want to pass around some variables -> YAML with some custom syntax for vars - ah but I want conditionals based on system properties -> ... And you end up with an awkward programming language with YAML syntax. I don’t much care if it’s XML or JSON at this stage, I just don’t want to write programs this way.
  - imtringued 4y ago
    I am very confused by everyone abusing YAML for weird crap. For me YAML is just an alternative to writing an application.properties file (in Spring or Micronaut). Yes I do use environment variables for secrets/passwords but that is about it.
    - TillE 4y ago
      Yeah, I think 99% of the real-world usage of YAML would trivially convert to JSON. Just static data. If you need weird complex stuff, use a real scripting language like Lua or something. It should be faster than a YAML parser, at least.
  - pydry 4y ago
    #2 onwarda means you need an API or a library or something. Unfortuntely many app creators dont recognize when their app has passed to stage #2 so we get all these unholy hacks.
jaxxstorm 4y ago
You’re generally lucky then I’d say. The point of the article was to try and see the other side of the equation for those people who do spend a lot of their lives writing long long YAML documents. If you just need a configuration format for your application then none of this applies, there is however a whole school of tech job that has to deal with this every single day
Cthulhu_ 4y ago
That's just it, a lot of things are optimized for maintainability or "what if", but in practice, a lot of code or config is written once and only occasionally tweaked; sometimes the whole codebase is just rewritten for something else. In the past ten years or so, I'd guess that the average lifetime of a customer facing website or -app is about five to ten years before it's rewritten by a new generation, a new IT director, or a new batch of overpriced consultants. I've had one project - consumer investing web application - that has had a number of iterations. a Flash / Flex app, then when the ipad came by and Flash died, a BackboneJS + Bootstrap app, then rewritten to AngularJS, then some ex googler came by and decided it should all be rewritten again in Polymer for some reason. Last I heard is there was "rebellion" and they were building things in React. I mean I kinda knew it was all futile anyway, but that experience, where years of my own labor was just discarded in favor of an experimental and unfinished technology, made me real jaded about things.
beanjuiceII 4y ago
Agreed, so many wasted cycles on all these yak shaves.
deleted 4y ago
[deleted]
dkarl 4y ago
That's exactly how I feel, except you're always running a risk. Somebody on the team might read the YAML standard and discover a bunch of cool features to use, and next thing you know, you have a lot of lines of YAML that are a razor's edge away from an edge case, and half the people on your team don't understand why. In your config files, no less, the last place you should have to devote scarce time and technical brainpower. Any sufficiently powerful language has the same hazard. It's natural to want to know everything about the technology you use and want to use everything you know. It's how we expand our skills, and the sheer pleasure of it is why a lot of us got into programming in the first place. But not everybody considers the interests of their team and their coworkers when they choose outlets for that impulse. A single selfish person can run a C++ or Scala codebase clean off the rails. It takes strong management to make sure the team has good collective boundaries and to crack down on people who go too far. Since senior developers are now largely left to manage themselves, you're at the mercy of the savant who knows 98% of the YAML standard to understand why they're being asked to only use it 70% of it, and to pay attention to the opinions of people who know less (about YAML) than them. Or you can just use JSON or TOML.
- woojoo666 4y ago
  Might be worth it to enforce StrictYaml [1], which fulfills all the major use cases and doesn't include the weirder, more complex features [1]: https://hitchdev.com/strictyaml/ https://hitchdev.com/strictyaml/
  - marcosdumay 4y ago
    Hum... That's one parser, in one language. Between all those links there doesn't even seem to exist a design document, much less a full specification for the language. That is really not enough. If it solves your specific use case, great, use it. But it's not a solution to the YAML problems.
- tomc1985 4y ago
  That doesn't seem like anything house rules and code reviews can't fix. "No fancy YAML bullshit allowed" aaaaaaaand done.
sunjester 4y ago
I 100% agree. They are all just data to read from a flat file. I wish we could just pick one already.

xcambar 4y ago

In a team of engineers, find one that complains about the configuration formats or linting rules, and with 100% confidence, you know who will ruin your meetings. Source: empirical study from me Thanks for not being that person.

ResearchCode 4y ago
The one that sent out the invitation
IshKebab 4y ago
I'm that person and I don't ruin meetings. I find it's the opposite - there are one or two people that obstinately refuse to allow any improvements and derail meetings with endless naysaying and stuck-in-the-muddery. It's wearing.
- JonChesterfield 4y ago
  Beware the cost of those improvements. I never want to have another discussion about whitespace layout.
  - carlmr 4y ago
    I'll accept 2, 4, 8 spaces or tabs, but it should be consistent.
    - xcambar 4y ago
      Here's my rule of thumb: * for new projects, use a well-established, reputable standard * for existing projects, use what is already in place if it is consistent * in case of inconsistency, fix to the closest industry standard
      - bschwindHN 4y ago
        My favorite: * Use an auto-formatter and enforce it in CI
        IshKebab 4y ago
        Yeah this is what I was trying to enact. They had sort of done that but the autoformatter had been broken for years and they wouldn't let me fix it and reformat everything.
        WorldMaker 4y ago
        Git supports revision ignore files for tools like git praise/blame, so that excuse that they don't want to reformat everything to avoid git praise blowout can be easily worked around by checking in an ignore revisions file and pointing them how to use it. Github even has public beta support for it, though they require a specific name for the ignore revs file: https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view https://docs.github.com/en/repositories/working-with-files/u...
    - abdouls 4y ago
      Definitely, as long as it's consistent - I personally like to go for 4 spaces everywhere, I would say it makes the code look easy and readable.
      - carlmr 4y ago
        Me, too, it's the default for almost every editor and code formatter. That makes it the most likely choice for projects. But if this project made a weird decision I'm ok with it, as long as it's enforced consistently.
hotpotamus 4y ago
I can't say that I've ever complained about any one of the rules; it's the constant churn of them that drives me insane.
make3 4y ago
that's the thing, i wish yaml was just a config format, that it does other weird shit like calling functions is the problem
- xcambar 4y ago
  The article makes excellent points on this very topic.

gorgoiler 4y ago

The “code” rot creeps in over the years. Especially so if you work with a lot of people on the team. If they view the infrastructure-as-“code” parts of the project as somehow lesser in stature than the rest of the actual code, then they more than likely see the YAML as a legitimate place to make drive-by tweaks without much care for “code” quality. Because they are programmers though, they might actually try to make the “code” better: First they refactor everything using ‘extends:’ to use inheritance for infrastructure “code” sharing. Then they started sharing “code” between blocks by using YAML references. This removes duplication, except for the edge cases that need to be different. Hmmm. Then the YAML file became a Jinja / Jsonnet / M4 / C-preprocessed template. That means there’s now another programming language involved so on the upside there’s some hope of finally being able to express computation, but with the downside that it somehow plays second fiddle to the YAML despite the latter having nothing to do with computation. The downsides of trying to prematurely capture your ideas as config are real. If you don’t focus on all of the key variation points you’re going to see people start hacking and templating at some point. It’s inevitable. I like how Ansible didn’t even try to avoid templating and ran with it straight off the bat. Config DSLs are hard. OpenSMTPD’s is beautiful but they didn’t get it right until version 6. Even then I bet some people are generating the config. Caddy’s dual approach of letting you use their DSL or give it generated JSON is nice. They have a config DSL for the use cases they could think of, but recognise that there will probably be other cases they didn’t think of, and so support you calling their API with machine built configs instead. Configuring a system with a programming language is difficult too. If you had a Python module to set up Apache, and your config was particularly lengthy, you can guarantee someone on your team is going to come up with a “clever” abstraction at some point via a pull request that links to the DRY Wikipedia page. It’s just that with Python etc — vs YAML “programming” in “code” — they are more likely to actually get it right.

TobTobXX 4y ago
VimL carries its scars from this process. At first just a configuration DSL for settings, nowadays the language truly sophisticated plugins are written in. I'm not decided whether I'd want something vim-like for infra as code. On one hand, in VimL, simple things remain simple and complex things are possible, alas you could say perfect design. On the other hand, everyone who has programmed something non-trivial with vim knows the pain.

resonious 4y ago

Not to derail too much from the original article, but I've been starting to feel the same about entire tech stacks. Building CRUD apps is annoying no matter what. Every time a framework makes one thing easy, it makes a couple of other things hard. No matter what tech you're using, there are some generalizable skills that are indispensable for project longevity: good testing, organization of files, consistency in concepts, and thoughtful comments that tell you why things are the way they are. The idea that we can replace skillful software engineering with the right abstraction just hasn't panned out for me.

thehappypm 4y ago
Mechanical engineers don’t attempt to have “one part that does everything”. Maybe we should think more like them.
- chii 4y ago
  well, they don't have a silver bullet part, but there are standardized components like screws, gears, levers etc. It's just that mechanical engineering is constrained by physical laws, and that gives design constraints that don't exist in software.
  - wtetzner 4y ago
    Standardized parts sound a lot like libraries implementing common interfaces.
- carlmr 4y ago
  Libraries over frameworks. It's that simple. Frameworks always make something hard the initial authors didn't think about. That happens a lot. Libraries provide some small set of well-tested functionalities, which you can replace if they don't serve you well. Every framework I've worked with had some issues, and because it's a framework it becomes a herculean effort to switch to something else. If it's only a single functionality that's much easier.
  - 4y ago

CipherThrowaway 4y ago

This feels tangential to the article. The article doesn't situate YAML against XML, JSON, TOML etc but against general purpose languages. The differences between the configuration approach and the GPL approach are pretty substantial compared to the differences between individual config formats.

rich_sasha 4y ago
To me that is the axis of discontent though. To me the badness is something like: - just want a static unconditional config -> YAML - ah but I want to pass around some variables -> YAML with some custom syntax for vars - ah but I want conditionals based on system properties -> ... And you end up with an awkward programming language with YAML syntax. I don’t much care if it’s XML or JSON at this stage, I just don’t want to write programs this way.
- imtringued 4y ago
  I am very confused by everyone abusing YAML for weird crap. For me YAML is just an alternative to writing an application.properties file (in Spring or Micronaut). Yes I do use environment variables for secrets/passwords but that is about it.
  - TillE 4y ago
    Yeah, I think 99% of the real-world usage of YAML would trivially convert to JSON. Just static data. If you need weird complex stuff, use a real scripting language like Lua or something. It should be faster than a YAML parser, at least.
- pydry 4y ago
  #2 onwarda means you need an API or a library or something. Unfortuntely many app creators dont recognize when their app has passed to stage #2 so we get all these unholy hacks.

jaxxstorm 4y ago

You’re generally lucky then I’d say. The point of the article was to try and see the other side of the equation for those people who do spend a lot of their lives writing long long YAML documents. If you just need a configuration format for your application then none of this applies, there is however a whole school of tech job that has to deal with this every single day

Cthulhu_ 4y ago

That's just it, a lot of things are optimized for maintainability or "what if", but in practice, a lot of code or config is written once and only occasionally tweaked; sometimes the whole codebase is just rewritten for something else. In the past ten years or so, I'd guess that the average lifetime of a customer facing website or -app is about five to ten years before it's rewritten by a new generation, a new IT director, or a new batch of overpriced consultants. I've had one project - consumer investing web application - that has had a number of iterations. a Flash / Flex app, then when the ipad came by and Flash died, a BackboneJS + Bootstrap app, then rewritten to AngularJS, then some ex googler came by and decided it should all be rewritten again in Polymer for some reason. Last I heard is there was "rebellion" and they were building things in React. I mean I kinda knew it was all futile anyway, but that experience, where years of my own labor was just discarded in favor of an experimental and unfinished technology, made me real jaded about things.

beanjuiceII 4y ago

Agreed, so many wasted cycles on all these yak shaves.

deleted 4y ago

[deleted]

dkarl 4y ago

That's exactly how I feel, except you're always running a risk. Somebody on the team might read the YAML standard and discover a bunch of cool features to use, and next thing you know, you have a lot of lines of YAML that are a razor's edge away from an edge case, and half the people on your team don't understand why. In your config files, no less, the last place you should have to devote scarce time and technical brainpower. Any sufficiently powerful language has the same hazard. It's natural to want to know everything about the technology you use and want to use everything you know. It's how we expand our skills, and the sheer pleasure of it is why a lot of us got into programming in the first place. But not everybody considers the interests of their team and their coworkers when they choose outlets for that impulse. A single selfish person can run a C++ or Scala codebase clean off the rails. It takes strong management to make sure the team has good collective boundaries and to crack down on people who go too far. Since senior developers are now largely left to manage themselves, you're at the mercy of the savant who knows 98% of the YAML standard to understand why they're being asked to only use it 70% of it, and to pay attention to the opinions of people who know less (about YAML) than them. Or you can just use JSON or TOML.

woojoo666 4y ago
Might be worth it to enforce StrictYaml [1], which fulfills all the major use cases and doesn't include the weirder, more complex features [1]: https://hitchdev.com/strictyaml/ https://hitchdev.com/strictyaml/
- marcosdumay 4y ago
  Hum... That's one parser, in one language. Between all those links there doesn't even seem to exist a design document, much less a full specification for the language. That is really not enough. If it solves your specific use case, great, use it. But it's not a solution to the YAML problems.
tomc1985 4y ago
That doesn't seem like anything house rules and code reviews can't fix. "No fancy YAML bullshit allowed" aaaaaaaand done.

sunjester 4y ago

I 100% agree. They are all just data to read from a flat file. I wish we could just pick one already.