4 ms·

Are you even serious? Of course there would be different formats for every goddamn thing under the Sun. What really happens there is called Impedance Mismatch

by xaduha 11y ago

Are you even serious? Of course there would be different formats for every goddamn thing under the Sun. What really happens there is called Impedance Mismatch Similar to this, but with XML https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch https://en.wikipedia.org/wiki/Object-relational_impedance_mi... Remember how Scala had XML as a first class citizen in the language? It didn't work out that well. There are different programming paradigms and I would (entirely serious here) say that XSLT, XQuery, XProc and related XML technologies belong to a separate category. It's mostly declarative and pure, but there are some imperative elements here and there. It's just a different way of doing things, which has XML and XPath at the very center. JSON doesn't have that Impedance Mismatch with Javascript and languages that support JSON well, that's why it's there.

scotty79 11y ago
I'm serious. We had AJAX not AJAJ. JSON mostly replaced XML in its only popular application. There would be no point of having JSON (as a thing not just JS notation for object literals) if XML wasn't that horrible to look at. > Remember how Scala had XML as a first class citizen in the language? It didn't work out that well. Funny how well having (sort-of) xml as first class citizen works in React ecosystem (in HTML too, to some degree). Easily composable bite sized chunks without over-engineered namespaces, doctypes and such. If only xml designers thought of their creation as pieces of flexible, composable hierarchical data not as documents. > It's mostly declarative and pure, but there are some imperative elements here and there. Yes. And despite all that it gets almost no love. My point is that this is mainly because of syntax (a thing that is considered by many, superficial and unimportant). > JSON doesn't have that Impedance Mismatch with Javascript and languages that support JSON well, that's why it's there. I believe you are overthinking this. JSON is just xml subset with slightly different syntax. If there is no mismatch between JSON and Javascript on any level beyond the syntax then there was no mismatch between subset of XML that was used for same purpose before JSON became popular.
- xaduha 11y ago
  With JSON you're not working with it as a tree, you're working with it as a set of objects. But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. There are wrappers around DOM, like jQuery, but even that leads to some spaghetti code. JSON is a first class citizen in JS, XML isn't and never was. E4X never was properly supported by browsers. Namespaces and doctypes are not mandatory. Merits of a language and/or framework has little to do with it's popularity. There are much better languages/frameworks than Go or Angular, for example, but that doesn't make them popular. I'm not overthinking it, it's not my idea in the first place. > If only xml designers thought of their creation as pieces of flexible, composable hierarchical data not as documents. That's just plain nonsense, what are you talking about? Nothing was stopping you from using XML the way it used in React. In fact these recent 'discoveries' in Javascript-land (React, Flux, Redux) are totally not new ideas.
  - scotty79 11y ago
    > With JSON you're not working with it as a tree, you're working with it as a set of objects. I can't agree with that. Each JSON payload is a tree with three kinds of nodes. Lists, associative arrays and values (of few flexible types). I'm not sure what you mean by set of objects because JSON doesn't have set type. You can have something like set if you use an array but disregard order or use associative array but disregard types. Also the objects can contain objects. That's what makes it actually a tree. > But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. Yes but you don't have to. You could map XML (at least the subset commonly used with AJAX) directly to tree of plain old JavaScript objects (you'd need some conventions though because in xml you can invent various ways of representing lists and associative arrays). > Namespaces and doctypes are not mandatory. Probably just my personal experience but some implementations of xml interoperability didn't allow me to specify default namespace for my xml tags which made me add bogus namespace identifier and prefix all my tags with that. Namespaces are optional but that optionality is not stated clearly enough in the spec and some apis don't allow you to forget about namespaces. > Nothing was stopping you from using XML the way it used in React. Just lack of good syntax/api. > I'm not overthinking it, it's not my idea in the first place. I was referring to your argument (as I understood it) that there are some deep mismatches between JSON and XML akin to object relational impedance mismatch. It's not that JSON is objects and XML is data. Both are just trees of values. My point is that the difference is just syntax but I'd like to backpedal from that now. JSON vs XML is not just syntax and lack of XML oddities. It's also a good deal of "less is more". Now I think JSON is XML but with one obvious way to express sequence and one obvious way to label the data for access. Anyways. I think we can agree to disagree and finish at that.

by xaduha 11y ago

scotty79 11y ago

I'm serious. We had AJAX not AJAJ. JSON mostly replaced XML in its only popular application. There would be no point of having JSON (as a thing not just JS notation for object literals) if XML wasn't that horrible to look at. > Remember how Scala had XML as a first class citizen in the language? It didn't work out that well. Funny how well having (sort-of) xml as first class citizen works in React ecosystem (in HTML too, to some degree). Easily composable bite sized chunks without over-engineered namespaces, doctypes and such. If only xml designers thought of their creation as pieces of flexible, composable hierarchical data not as documents. > It's mostly declarative and pure, but there are some imperative elements here and there. Yes. And despite all that it gets almost no love. My point is that this is mainly because of syntax (a thing that is considered by many, superficial and unimportant). > JSON doesn't have that Impedance Mismatch with Javascript and languages that support JSON well, that's why it's there. I believe you are overthinking this. JSON is just xml subset with slightly different syntax. If there is no mismatch between JSON and Javascript on any level beyond the syntax then there was no mismatch between subset of XML that was used for same purpose before JSON became popular.

xaduha 11y ago
With JSON you're not working with it as a tree, you're working with it as a set of objects. But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. There are wrappers around DOM, like jQuery, but even that leads to some spaghetti code. JSON is a first class citizen in JS, XML isn't and never was. E4X never was properly supported by browsers. Namespaces and doctypes are not mandatory. Merits of a language and/or framework has little to do with it's popularity. There are much better languages/frameworks than Go or Angular, for example, but that doesn't make them popular. I'm not overthinking it, it's not my idea in the first place. > If only xml designers thought of their creation as pieces of flexible, composable hierarchical data not as documents. That's just plain nonsense, what are you talking about? Nothing was stopping you from using XML the way it used in React. In fact these recent 'discoveries' in Javascript-land (React, Flux, Redux) are totally not new ideas.
- scotty79 11y ago
  > With JSON you're not working with it as a tree, you're working with it as a set of objects. I can't agree with that. Each JSON payload is a tree with three kinds of nodes. Lists, associative arrays and values (of few flexible types). I'm not sure what you mean by set of objects because JSON doesn't have set type. You can have something like set if you use an array but disregard order or use associative array but disregard types. Also the objects can contain objects. That's what makes it actually a tree. > But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. Yes but you don't have to. You could map XML (at least the subset commonly used with AJAX) directly to tree of plain old JavaScript objects (you'd need some conventions though because in xml you can invent various ways of representing lists and associative arrays). > Namespaces and doctypes are not mandatory. Probably just my personal experience but some implementations of xml interoperability didn't allow me to specify default namespace for my xml tags which made me add bogus namespace identifier and prefix all my tags with that. Namespaces are optional but that optionality is not stated clearly enough in the spec and some apis don't allow you to forget about namespaces. > Nothing was stopping you from using XML the way it used in React. Just lack of good syntax/api. > I'm not overthinking it, it's not my idea in the first place. I was referring to your argument (as I understood it) that there are some deep mismatches between JSON and XML akin to object relational impedance mismatch. It's not that JSON is objects and XML is data. Both are just trees of values. My point is that the difference is just syntax but I'd like to backpedal from that now. JSON vs XML is not just syntax and lack of XML oddities. It's also a good deal of "less is more". Now I think JSON is XML but with one obvious way to express sequence and one obvious way to label the data for access. Anyways. I think we can agree to disagree and finish at that.