5 ms·

stronly agree, I came to that conclusion before k8's even existed because I myself thought to use it as a configuration file format and the second I started rea

stronly agree, I came to that conclusion before k8's even existed because I myself thought to use it as a configuration file format and the second I started realizing some of the ambiguity in it's syntax I walked away from it. The only thing I disagree with is that Coffeescript is still useful. I had the same reaction to Coffeescript that I had with yaml, Coffeescript _never_ had any real point outside of a segment of people preferring to write javascript in Ruby syntax. The biggest issue Coffeescript had is that debugging meant reading through the javascript anyway so you never really got away from javascript. I'm a fan of either using a full-blown programming language or ini files, and yes I realize that seems insane to many people but at the end of the day ini files are stupidly easy to edit and if you can get away with not needing a full-blown turing complete language then convention based ini files are vastly easier on the human than yaml or json. I'm either a greybeard that never got with the times or I'm a rebel, probably depends on who you talk to.

smaudet 3y ago
> I'm a fan of either using a full-blown programming language or ini files How do you persist complex multi-object state? Think nested lists of objects with references to one another. If your answer is still "ini files", I'm sure it can be done, but only with a lot of custom-rolled code...xml/json(even yaml) for all their issues provided a code-free way of persisting this all - either through use of marshalling (xml) or json/yaml.load().
- PH95VuimJjqBqy 3y ago
  you cut off the part of my statement that answers your question > if you can get away with not needing a full-blown turing complete language then convention based ini files are vastly easier on the human than yaml or json. My claim isn't that ini files solve for every use case, it's that if your needs are simple enough ini files are superior to json/yaml, but that full-blown turing complete languages are superior to everything else. Also, if you're saving complex object state you don't have a configuration format but a serialization format and definitely ini isn't good for that.
  - smaudet 3y ago
    > you don't have a configuration format but a serialization format While I better appreciate what you are saying now (you don't have a solution), the only appreciable difference between "config" and "serialization" is that of write frequency - config is seldom updated, serialization is often updated. Otherwise, they are the same problem with the same solution - you might provision resources differently based upon "dynamic" vs "static" data, but that's an operational perspective. From the perspective of the application maintainer, there is no difference.
    - PH95VuimJjqBqy 3y ago
      I'm going to submit that if you think configuration and serialization are the same problem it's time to step back and re-evaluate what you're doing, which is really the authors point. As Joel Spoelsky said years ago, if you abstract far enough up everything starts to look the same but that doesn't make it so https://www.joelonsoftware.com/2008/05/01/architecture-astronauts-take-over/ https://www.joelonsoftware.com/2008/05/01/architecture-astro... At the end of the day you could claim that all data exchange is exactly the same, and indeed Claude Shannon showed all information is just data, but that misses the point entirely. All humans are exactly the same and yet sex between them can look vastly different based upon such details as genitals.
      - smaudet 3y ago
        > if you think configuration and serialization are the same problem Except that's precisely not the point...rather the formats they are written in are the same, they are indistinguishable. Reductio-ad-absurdum, if all data exchange is the same then there is no benefit to any format, just write binary strings with null-terminal characters. Except for the many downsides to that approach, so it turns out that they are not the same... And never-the-less, if all configuration were not serialization, there would be not be any need to be generating config via a different language per the OPs' post... So we find the similarities between configuration and serialization to be more pertinent than their dissimilarities wrt to format. INI is absurd for any complex configuration, "just use a turing complete language" is as good an answer as deciding to write binary data randomly...

smaudet 3y ago

> I'm a fan of either using a full-blown programming language or ini files How do you persist complex multi-object state? Think nested lists of objects with references to one another. If your answer is still "ini files", I'm sure it can be done, but only with a lot of custom-rolled code...xml/json(even yaml) for all their issues provided a code-free way of persisting this all - either through use of marshalling (xml) or json/yaml.load().

PH95VuimJjqBqy 3y ago
you cut off the part of my statement that answers your question > if you can get away with not needing a full-blown turing complete language then convention based ini files are vastly easier on the human than yaml or json. My claim isn't that ini files solve for every use case, it's that if your needs are simple enough ini files are superior to json/yaml, but that full-blown turing complete languages are superior to everything else. Also, if you're saving complex object state you don't have a configuration format but a serialization format and definitely ini isn't good for that.
- smaudet 3y ago
  > you don't have a configuration format but a serialization format While I better appreciate what you are saying now (you don't have a solution), the only appreciable difference between "config" and "serialization" is that of write frequency - config is seldom updated, serialization is often updated. Otherwise, they are the same problem with the same solution - you might provision resources differently based upon "dynamic" vs "static" data, but that's an operational perspective. From the perspective of the application maintainer, there is no difference.
  - PH95VuimJjqBqy 3y ago
    I'm going to submit that if you think configuration and serialization are the same problem it's time to step back and re-evaluate what you're doing, which is really the authors point. As Joel Spoelsky said years ago, if you abstract far enough up everything starts to look the same but that doesn't make it so https://www.joelonsoftware.com/2008/05/01/architecture-astronauts-take-over/ https://www.joelonsoftware.com/2008/05/01/architecture-astro... At the end of the day you could claim that all data exchange is exactly the same, and indeed Claude Shannon showed all information is just data, but that misses the point entirely. All humans are exactly the same and yet sex between them can look vastly different based upon such details as genitals.
    - smaudet 3y ago
      > if you think configuration and serialization are the same problem Except that's precisely not the point...rather the formats they are written in are the same, they are indistinguishable. Reductio-ad-absurdum, if all data exchange is the same then there is no benefit to any format, just write binary strings with null-terminal characters. Except for the many downsides to that approach, so it turns out that they are not the same... And never-the-less, if all configuration were not serialization, there would be not be any need to be generating config via a different language per the OPs' post... So we find the similarities between configuration and serialization to be more pertinent than their dissimilarities wrt to format. INI is absurd for any complex configuration, "just use a turing complete language" is as good an answer as deciding to write binary data randomly...