5 ms·

> XML, however, was universally rejected in favour of things like JSON, Yaml, HCL, Toml - all free of structure, with zero indication whether a computer would f

by l0b0 6y ago

> XML, however, was universally rejected in favour of things like JSON, Yaml, HCL, Toml - all free of structure, with zero indication whether a computer would find your prose gibberish or the next Shakespeare play until you actually pushed your code to some test cluster. There are a few fundamental differences between these languages, but it's just plain wrong to say that any of them are not "structured." Did OP mean "schema-less" instead? Because the only fundamental difference at that level is that XML has a built-in mechanism for metadata referring to a file's own schema, while in JSON (and I believe the others, even though I've used them less) the schema is not linked from within the file itself. You can still verify the schema of these languages, though, just as you could with XML. And once you've verified the schema, local code can do stricter validation to make sure things hang together properly, that values are within limits, and so on. After that, I expect modern tools like Terraform and CDK to check with the target platform that the scheduled change can be applied before trying to change anything. That said, OP has several valid points: - Many projects try to make a microservices architecture long before it's needed, even in projects where it might never be needed. I suspect some people think microservices are actually easier to maintain, since they are smaller pieces, but only extremely trivial or shoddy microservices will be easier to maintain than a corresponding monolith, because many things which are well-understood in a local setting are much harder to do in a highly distributed setting, simply because the infrastructure is now a bazillion separately managed pieces. - The feedback loop can be abysmal. Without any easy alternatives to do "local cloud" deployments, having to wait for several minutes for feedback about a tiny change is frustrating in the extreme.

desert_boi 6y ago
By that logic, is https://json-schema.org/ https://json-schema.org/ is the reimposition of a schema within JSON?
chubot 6y ago
I'd say that JSON is "structured", and probably HCL as far as I know, but the others have problems. I haven't worked with an API that uses XML in a long time, but does it express the difference between "0123" and 123 well? I think that it either doesn't, or you add some really awkward schema language with XML namespaces ... I just translated my .travis.yml to JSON, and I learned that deploy: on: branch: master gets translated to {"deploy": {"true": {"branch": "master"}}} because "on" is a synonym for true. I'd call that unstructured. It also has problems with keys that start with -, etc. Also, all of the languages are often used with say Go templates, which makes them more unstructured. They're no longer statically parsable, which is "table stakes" for doing anything else (validation or static analysis). I took some pains to make shell statically parsable [2], and I think it's now a better foundation than these config languages, per my other comment here: https://news.ycombinator.com/item?id=25483270 https://news.ycombinator.com/item?id=25483270 I think HCL is probably a lot better, but it also seems to be the least used! It's structured, and has its own mechanism for expressing duplication that's not the equivalent of a 70's-style #include. [1] https://github.com/oilshell/oil/blob/master/.travis.yml https://github.com/oilshell/oil/blob/master/.travis.yml [2] http://www.oilshell.org/blog/2019/02/07.html http://www.oilshell.org/blog/2019/02/07.html
- dehrmann 6y ago
  > "on" is a synonym for true And "no" is a synonym for false, hence "the Norway problem." https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/
- tannhaeuser 6y ago
  > I haven't worked with an API that uses XML in a long time, but does it express the difference between "0123" and 123 well? I think that it either doesn't, or you add some really awkward schema language with XML namespaces ... Is as easy as declaring <!ATTLIST data field NUMBER #IMPLIED> vs <!ATTLIST data field CDATA #IMPLIED> with DTDs.
wwweston 6y ago
> There are a few fundamental differences between these languages, but it's just plain wrong to say that any of them are not "structured." Did OP mean "schema-less" instead? I read him as referencing what people would have called "structured programming" in the 1980s, and pointing out that we have these settings/metadata/control files in languages that have no capacity for "structure" in the sense that, say, Pascal or C would have over BASIC or assembly, that is, thin-to-no factoring or abstraction capacity. Hence the contrast with "Configuration as Code." Now, depending on your personality and experience, you might find the idea of using a complete language as config an opportunity for someone to do something non-obvious or horrifying, and the closer to the "settings" end of the setting/metadata/control spectrum you're on the more plausible that position is. When you get to a level of complexity that's the other end I'm not so sure and horizontally scaling systems might well be arriving there.
tannhaeuser 6y ago
> the only fundamental difference at that level is that XML has a built-in mechanism for metadata referring to a file's own schema, while in JSON (and I believe the others, even though I've used them less) the schema is not linked from within the file itself As long as you're using plain DTDs for your schema, yes. Like early XML-based config languages such as idk JSPs/web-app and Jakarta (née J2EE) deployment descriptors used and still use. But later XML configs use XML Schema and namespaces, which are similarly detached from an instance document as eg JSON Schema and the others you mention [1]. [1]: http://cmsmcq.com/2005/xml2005-166.html http://cmsmcq.com/2005/xml2005-166.html "How schema-validity is different from being married"

by l0b0 6y ago

desert_boi 6y ago

By that logic, is https://json-schema.org/ https://json-schema.org/ is the reimposition of a schema within JSON?

chubot 6y ago

I'd say that JSON is "structured", and probably HCL as far as I know, but the others have problems. I haven't worked with an API that uses XML in a long time, but does it express the difference between "0123" and 123 well? I think that it either doesn't, or you add some really awkward schema language with XML namespaces ... I just translated my .travis.yml to JSON, and I learned that deploy: on: branch: master gets translated to {"deploy": {"true": {"branch": "master"}}} because "on" is a synonym for true. I'd call that unstructured. It also has problems with keys that start with -, etc. Also, all of the languages are often used with say Go templates, which makes them more unstructured. They're no longer statically parsable, which is "table stakes" for doing anything else (validation or static analysis). I took some pains to make shell statically parsable [2], and I think it's now a better foundation than these config languages, per my other comment here: https://news.ycombinator.com/item?id=25483270 https://news.ycombinator.com/item?id=25483270 I think HCL is probably a lot better, but it also seems to be the least used! It's structured, and has its own mechanism for expressing duplication that's not the equivalent of a 70's-style #include. [1] https://github.com/oilshell/oil/blob/master/.travis.yml https://github.com/oilshell/oil/blob/master/.travis.yml [2] http://www.oilshell.org/blog/2019/02/07.html http://www.oilshell.org/blog/2019/02/07.html

dehrmann 6y ago
> "on" is a synonym for true And "no" is a synonym for false, hence "the Norway problem." https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/
tannhaeuser 6y ago
> I haven't worked with an API that uses XML in a long time, but does it express the difference between "0123" and 123 well? I think that it either doesn't, or you add some really awkward schema language with XML namespaces ... Is as easy as declaring <!ATTLIST data field NUMBER #IMPLIED> vs <!ATTLIST data field CDATA #IMPLIED> with DTDs.

wwweston 6y ago

> There are a few fundamental differences between these languages, but it's just plain wrong to say that any of them are not "structured." Did OP mean "schema-less" instead? I read him as referencing what people would have called "structured programming" in the 1980s, and pointing out that we have these settings/metadata/control files in languages that have no capacity for "structure" in the sense that, say, Pascal or C would have over BASIC or assembly, that is, thin-to-no factoring or abstraction capacity. Hence the contrast with "Configuration as Code." Now, depending on your personality and experience, you might find the idea of using a complete language as config an opportunity for someone to do something non-obvious or horrifying, and the closer to the "settings" end of the setting/metadata/control spectrum you're on the more plausible that position is. When you get to a level of complexity that's the other end I'm not so sure and horizontally scaling systems might well be arriving there.

tannhaeuser 6y ago

> the only fundamental difference at that level is that XML has a built-in mechanism for metadata referring to a file's own schema, while in JSON (and I believe the others, even though I've used them less) the schema is not linked from within the file itself As long as you're using plain DTDs for your schema, yes. Like early XML-based config languages such as idk JSPs/web-app and Jakarta (née J2EE) deployment descriptors used and still use. But later XML configs use XML Schema and namespaces, which are similarly detached from an instance document as eg JSON Schema and the others you mention [1]. [1]: http://cmsmcq.com/2005/xml2005-166.html http://cmsmcq.com/2005/xml2005-166.html "How schema-validity is different from being married"