6 ms·

> I then built a UI system that works with the XML and generates cofig docs with ease. I lost you there. Not that I'm criticizing you since I've gone the same

> I then built a UI system that works with the XML and generates cofig docs with ease. I lost you there. Not that I'm criticizing you since I've gone the same route and built a complex UI tool to manage said config (complete with XSD schema validation and config schema migration using XSLT for version upgrades). But now I realize that modern developers don't want a GUI to manage their config. We want to store it git, review changes and perhaps even write our own automation and templating around it. YAML is certainly a flawed format for most of these purposes, but so is XML. It is unnecessarily verbose and it carries a lot of complexity which was designed for a highly-extensible generic document format, but not for configuration files. XSD, Namespaces, Entities, Embedded DTD, CDATA blocks... You can't just ignore all of these, and there are very few parsers out there which work on a well-defined subset of XML. And even there, the whole attribute-vs-child-element choice is a giant distraction and constant source for unnecessary bikeshedding. YAML has serious ambiguity issues, but there are better alternatives that have great library support like TOML. We don't have to go back to the excesses of the early 2000s and use XML as a configuration format.

CableNinja 3y ago
I recently started a new project, and just outright didnt want to use yaml to do it. Sadly, im not everyone, and if i plan to release this project, i need to account for that. Whats a guy to do? Ill tell ya hwhat... I made some simple functions; one to load any yaml/toml/json from file, by just looking at the extension (and providing an override for not normal file extensions). Another to output any data as yaml/toml/json. I defaulted to using toml for my project, but have provided ways for everyone to be happy, with zero mucking around. Aaaaaand for the not so subtle promotion, https://pypi.org/project/atckit https://pypi.org/project/atckit Located in the UtilFuncs class.
- elzbardico 3y ago
  What is the point of substituting yaml for something even worse?
  - CableNinja 3y ago
    Worse is subjective. In any case, the library i linked has the functionality to load any of the three configuration types, so while i prefer toml, if you grabbed my (under development) project, and hate toml, you can use yaml or json, if you wish.
mumblemumble 3y ago
In XML's defense, the attribute-vs-child-element choice is always obvious and straightforward when you're using it as a markup language. It's only when you use it as object notation that it becomes wonky, because there the choice simply doesn't map to any straightforward characteristic of the problem domain. I'm not sure I want to hold XML responsible for not being good at being something it isn't. And, on that note, I think that if I could pick as single thing that irritates me the most about YAML, it's that it isn't actually a ML.
- unscaled 3y ago
  I'm not criticizing having attributes-vs-child-elements. The problem with XML is not that it exists or that it is a particularly badly designed markup language. The problem is that XML is ill-suited for configuration files.
  - baq 3y ago
    Yeah JSX and especially TSX would be quite nice. YAML though can’t die soon enough.
    - moritzwarhier 3y ago
      You think that JSX would be suited for configuration files? Why? I don't understand your comment.
      - baq 3y ago
        Because people reinvent half of it, different half every time in each project, and call it 'configuration' which somehow gives them licencia poetica for whatever crazy dung they come up with. Compare ansible vs helm vs github actions vs literally anything with nontrivial config. Note that if you asked me for real, I'd be a dhall proponent, but most normal people look at me funny the first time they hear it and then the second time they see the syntax.
        3y ago
kumarvvr 3y ago
I built it to make it so that average users can make their own config. The main system works off on only XML files.
wsc981 3y ago
I think I’d prefer JSON over both XML and YAML when dealing with config files. XML is just to verbose, making it harder to parse in my brain. YAML is whitespace sensitive which I hate in general.
- yjftsjthsd-h 3y ago
  I'm fine with JSON except it doesn't officially do comments, but that's a big deal IMO
  - sixothree 3y ago
    Which is especially problematic for config files where you want helpful hints or a place to store the “old value” while you do something else with the app. I have an app where I change a specific config almost every time I use it. I usually just copy the entire darn node and rename it to something that doesn’t get deserialized. Closest I can get to holding the value in a comment.
  - Koffiepoeder 3y ago
    Might be interesting to check out json5. https://json5.org/ https://json5.org/
    - FlyingSnake 3y ago
      This is a great example why we should avoid writing custom DSLs and just use a proper programming language.
      - eitland 3y ago
        Then again, Gradle has come to show why that is a terrible idea. I think at some point 24 out of 28 Gradle projects I had access to at a certain customer had variations in either kotlin/Groovy style or the way they did or didn't use variables, how they did or didn't do loops or maps and what not. With Maven you (or someone who know Maven) can immediately look at a rather small, very standardized file and start making educated guesses and so can an IDE. With Gradle you sometimes have to run it to actually know what it will do.
bryanrasmussen 3y ago
>But now I realize that modern developers don't want a GUI to manage their config. We want to store it git, review changes and perhaps even write our own automation and templating around it. not all configurations are maintained by developers, or at least theoretically they shouldn't be.
blincoln 3y ago
> But now I realize that modern developers don't want a GUI to manage their config. I think, like almost all software, it depends on personality and other factors like how frequently someone has worked with a language/tool/etc. If someone has the traditional Unix "read all the man pages in their entirety" kind of brain, they'll probably never use a GUI. If someone has more of a "learn by example, then refer to the docs to cover cases the examples didn't handle" brain, a GUI can be a much easier way to clearly expose all the potential functionality of a tool. It's much easier to understand (IMO) than e.g. a template configuration file with every possible option present but commented out.
HelloNurse 3y ago
> a well-defined subset of XML No. You need to define what configuration files are valid or not, but a subset of XML on the basis of syntactic and structural alternatives is lame and nonstandard. Get a library that parses actual XML, allow anything reasonable as input (for example, no external entities, DTDs, PSVI etc. to keep the file self contained) and "flatten" CDATA sections, entities, namespace prefixes, idrefs etc.

CableNinja 3y ago

I recently started a new project, and just outright didnt want to use yaml to do it. Sadly, im not everyone, and if i plan to release this project, i need to account for that. Whats a guy to do? Ill tell ya hwhat... I made some simple functions; one to load any yaml/toml/json from file, by just looking at the extension (and providing an override for not normal file extensions). Another to output any data as yaml/toml/json. I defaulted to using toml for my project, but have provided ways for everyone to be happy, with zero mucking around. Aaaaaand for the not so subtle promotion, https://pypi.org/project/atckit https://pypi.org/project/atckit Located in the UtilFuncs class.

elzbardico 3y ago
What is the point of substituting yaml for something even worse?
- CableNinja 3y ago
  Worse is subjective. In any case, the library i linked has the functionality to load any of the three configuration types, so while i prefer toml, if you grabbed my (under development) project, and hate toml, you can use yaml or json, if you wish.

mumblemumble 3y ago

In XML's defense, the attribute-vs-child-element choice is always obvious and straightforward when you're using it as a markup language. It's only when you use it as object notation that it becomes wonky, because there the choice simply doesn't map to any straightforward characteristic of the problem domain. I'm not sure I want to hold XML responsible for not being good at being something it isn't. And, on that note, I think that if I could pick as single thing that irritates me the most about YAML, it's that it isn't actually a ML.

unscaled 3y ago
I'm not criticizing having attributes-vs-child-elements. The problem with XML is not that it exists or that it is a particularly badly designed markup language. The problem is that XML is ill-suited for configuration files.
- baq 3y ago
  Yeah JSX and especially TSX would be quite nice. YAML though can’t die soon enough.
  - moritzwarhier 3y ago
    You think that JSX would be suited for configuration files? Why? I don't understand your comment.
    - baq 3y ago
      Because people reinvent half of it, different half every time in each project, and call it 'configuration' which somehow gives them licencia poetica for whatever crazy dung they come up with. Compare ansible vs helm vs github actions vs literally anything with nontrivial config. Note that if you asked me for real, I'd be a dhall proponent, but most normal people look at me funny the first time they hear it and then the second time they see the syntax.
      - 3y ago

kumarvvr 3y ago

I built it to make it so that average users can make their own config. The main system works off on only XML files.

wsc981 3y ago

I think I’d prefer JSON over both XML and YAML when dealing with config files. XML is just to verbose, making it harder to parse in my brain. YAML is whitespace sensitive which I hate in general.

yjftsjthsd-h 3y ago
I'm fine with JSON except it doesn't officially do comments, but that's a big deal IMO
- sixothree 3y ago
  Which is especially problematic for config files where you want helpful hints or a place to store the “old value” while you do something else with the app. I have an app where I change a specific config almost every time I use it. I usually just copy the entire darn node and rename it to something that doesn’t get deserialized. Closest I can get to holding the value in a comment.
- Koffiepoeder 3y ago
  Might be interesting to check out json5. https://json5.org/ https://json5.org/
  - FlyingSnake 3y ago
    This is a great example why we should avoid writing custom DSLs and just use a proper programming language.
    - eitland 3y ago
      Then again, Gradle has come to show why that is a terrible idea. I think at some point 24 out of 28 Gradle projects I had access to at a certain customer had variations in either kotlin/Groovy style or the way they did or didn't use variables, how they did or didn't do loops or maps and what not. With Maven you (or someone who know Maven) can immediately look at a rather small, very standardized file and start making educated guesses and so can an IDE. With Gradle you sometimes have to run it to actually know what it will do.

bryanrasmussen 3y ago

>But now I realize that modern developers don't want a GUI to manage their config. We want to store it git, review changes and perhaps even write our own automation and templating around it. not all configurations are maintained by developers, or at least theoretically they shouldn't be.

blincoln 3y ago

> But now I realize that modern developers don't want a GUI to manage their config. I think, like almost all software, it depends on personality and other factors like how frequently someone has worked with a language/tool/etc. If someone has the traditional Unix "read all the man pages in their entirety" kind of brain, they'll probably never use a GUI. If someone has more of a "learn by example, then refer to the docs to cover cases the examples didn't handle" brain, a GUI can be a much easier way to clearly expose all the potential functionality of a tool. It's much easier to understand (IMO) than e.g. a template configuration file with every possible option present but commented out.

HelloNurse 3y ago

> a well-defined subset of XML No. You need to define what configuration files are valid or not, but a subset of XML on the basis of syntactic and structural alternatives is lame and nonstandard. Get a library that parses actual XML, allow anything reasonable as input (for example, no external entities, DTDs, PSVI etc. to keep the file self contained) and "flatten" CDATA sections, entities, namespace prefixes, idrefs etc.