6 ms·

>>> What's wrong with XML? It's more human-writable than json wait, what?

by _ZeD_ 10y ago

mgamache 10y ago
XML is more readable to people that learned XML first (like me). The younger crowd reads JSON better then XML. Just a matter of perspective. The only argument for XML is that you see the closing tags to know where the element ends. However, I avoid using XML for anything these days.
- geggam 10y ago
  comments... json needs comments
- jeremiep 10y ago
  They're not the same. Both YAML and JSON map to data structures in your program; scalars, sequences and mappings. XML on the other hand maps to.. a DOM! You've still got to normalize that into what your program expects. SAX is not any better. Everytime I land in a project using XML I know I'll spend orders of magnitude more time dealing with data than if the project had used YAML or JSON.
  - zeveb 10y ago
    > Both YAML and JSON map to data structures in your program; scalars, sequences and mappings. > XML on the other hand maps to.. a DOM! You've still got to normalize that into what your program expects. SAX is not any better. Of course, your program probably operates on more than just scalars, sequences & maps, which means you still need to convert your JSON structures into application data structures — validating along the way, too.
    - jeremiep 10y ago
      My application data structures ARE the JSON structures (or the YAML ones, they both map to generic data types in any language). That's the beauty of it. If you have distinct application structures that means you're reinventing ad-hoc scalars, sequences and mappings for the sake of encapsulation. You gain absolutely nothing yet you now have mountains of rigid code to maintain and you can't use generic data functions anymore - more ad-hoc stuff to write! Even working in statically typed languages you can get away with HashMap<String, Object> or IDictionary<string, object> and call it a day. Very few things require the performance of custom types and its a complete myth that types makes you safer - you have so much more code that bugs are more likely to crawl in.
      - zeveb 10y ago
        > If you have distinct application structures that means you're reinventing ad-hoc scalars, sequences and mappings for the sake of encapsulation. You gain absolutely nothing yet you now have mountains of rigid code to maintain and you can't use generic data functions anymore - more ad-hoc stuff to write! No, it means that one has types. What does '{"length": 3}' mean? 3 items? 3 inches? 3 kilometres? For that matter, is '{"length": "abc"}' incorrect? > Very few things require the performance of custom types and its a complete myth that types makes you safer - you have so much more code that bugs are more likely to crawl in. Having caught many, many bugs from strong types, I feel comfortable saying that you're incorrect here. Yes, there are even more sources of bugs than just type errors. There are also more bugs than memory-management errors. But just as manual management of memory very rarely makes sense, manual management of types very rarely makes sense. If you don't have a solid sanitisation/marshalling/untainting/whatever-you-call-it layer, you're going to have security and other correctness errors.
        jeremiep 10y ago
        > No, it means that one has types. {length: 3} has a very specific type. Shoving that into a struct Foo { double length; } doesn't make it any safer. A simple validator and properly naming fields to mention units makes you safer than types. > For that matter, is '{"length": "abc"}' incorrect? That's a non-issue with even the simplest of validators. > Having caught many, many bugs from strong types, I feel comfortable saying that you're incorrect here. Yet you still need a test suite to handle the huge holes left by the type-system. These tests will catch all bugs the strong types would along the way. Unless you're having a Hindley-Milner type system, chances are you're working in C++, Java or C# and bugs caught by these type-systems are very superficial. > If you don't have a solid sanitisation/marshalling/untainting/whatever-you-call-it layer, you're going to have security and other correctness errors. Totally agree, but you don't need types or XML for that. Having worked as much with statically typed languages and dynamic ones, I'll chose the later any day unless I have very strict performance/memory requirements which is not happening for 99.9% of projects. Types might catch the easy and superficial bugs, but my ability to reason prevents the hard ones. Having orders of magnitude less code to think about is exactly what I want to achieve it.
  - Mikhail_Edoshin 10y ago
    What if you need DOM-like data, like formatted text? And "formatted" may mean something relatively simple, like a a basic math formula or even a subscript?
    - jeremiep 10y ago
      Store it as a plain string. Most GUI libraries I know of will accept that type only for their rich text controls anyways. If I need to work on the data I'll parse it into a data structure. Then I get something like ["Hello " [:b "World!"]] where I can leverage the existing functions operating on data in order to manipulate it.
- ungzd 10y ago
  Younger crowd still uses HTML and it's very similar to XML.
ungzd 10y ago
No syntax for comments, mandatory quotes everywhere, no trailing comma requirement, deeper nesting due to lower expressivity, lack of context (XML elements has name, json nodes usually has implicit context, for example in "Open API Specification" aka Swagger often it's hard to tell what current object expresses).

>>> What's wrong with XML? It's more human-writable than json wait, what?

by _ZeD_ 10y ago

>>> What's wrong with XML? It's more human-writable than json wait, what?

XML is more readable to people that learned XML first (like me). The younger crowd reads JSON better then XML. Just a matter of perspective. The only argument for XML is that you see the closing tags to know where the element ends. However, I avoid using XML for anything these days.

geggam 10y ago
comments... json needs comments
jeremiep 10y ago
They're not the same. Both YAML and JSON map to data structures in your program; scalars, sequences and mappings. XML on the other hand maps to.. a DOM! You've still got to normalize that into what your program expects. SAX is not any better. Everytime I land in a project using XML I know I'll spend orders of magnitude more time dealing with data than if the project had used YAML or JSON.
- zeveb 10y ago
  > Both YAML and JSON map to data structures in your program; scalars, sequences and mappings. > XML on the other hand maps to.. a DOM! You've still got to normalize that into what your program expects. SAX is not any better. Of course, your program probably operates on more than just scalars, sequences & maps, which means you still need to convert your JSON structures into application data structures — validating along the way, too.
  - jeremiep 10y ago
    My application data structures ARE the JSON structures (or the YAML ones, they both map to generic data types in any language). That's the beauty of it. If you have distinct application structures that means you're reinventing ad-hoc scalars, sequences and mappings for the sake of encapsulation. You gain absolutely nothing yet you now have mountains of rigid code to maintain and you can't use generic data functions anymore - more ad-hoc stuff to write! Even working in statically typed languages you can get away with HashMap<String, Object> or IDictionary<string, object> and call it a day. Very few things require the performance of custom types and its a complete myth that types makes you safer - you have so much more code that bugs are more likely to crawl in.
    - zeveb 10y ago
      > If you have distinct application structures that means you're reinventing ad-hoc scalars, sequences and mappings for the sake of encapsulation. You gain absolutely nothing yet you now have mountains of rigid code to maintain and you can't use generic data functions anymore - more ad-hoc stuff to write! No, it means that one has types. What does '{"length": 3}' mean? 3 items? 3 inches? 3 kilometres? For that matter, is '{"length": "abc"}' incorrect? > Very few things require the performance of custom types and its a complete myth that types makes you safer - you have so much more code that bugs are more likely to crawl in. Having caught many, many bugs from strong types, I feel comfortable saying that you're incorrect here. Yes, there are even more sources of bugs than just type errors. There are also more bugs than memory-management errors. But just as manual management of memory very rarely makes sense, manual management of types very rarely makes sense. If you don't have a solid sanitisation/marshalling/untainting/whatever-you-call-it layer, you're going to have security and other correctness errors.
      - jeremiep 10y ago
        > No, it means that one has types. {length: 3} has a very specific type. Shoving that into a struct Foo { double length; } doesn't make it any safer. A simple validator and properly naming fields to mention units makes you safer than types. > For that matter, is '{"length": "abc"}' incorrect? That's a non-issue with even the simplest of validators. > Having caught many, many bugs from strong types, I feel comfortable saying that you're incorrect here. Yet you still need a test suite to handle the huge holes left by the type-system. These tests will catch all bugs the strong types would along the way. Unless you're having a Hindley-Milner type system, chances are you're working in C++, Java or C# and bugs caught by these type-systems are very superficial. > If you don't have a solid sanitisation/marshalling/untainting/whatever-you-call-it layer, you're going to have security and other correctness errors. Totally agree, but you don't need types or XML for that. Having worked as much with statically typed languages and dynamic ones, I'll chose the later any day unless I have very strict performance/memory requirements which is not happening for 99.9% of projects. Types might catch the easy and superficial bugs, but my ability to reason prevents the hard ones. Having orders of magnitude less code to think about is exactly what I want to achieve it.
- Mikhail_Edoshin 10y ago
  What if you need DOM-like data, like formatted text? And "formatted" may mean something relatively simple, like a a basic math formula or even a subscript?
  - jeremiep 10y ago
    Store it as a plain string. Most GUI libraries I know of will accept that type only for their rich text controls anyways. If I need to work on the data I'll parse it into a data structure. Then I get something like ["Hello " [:b "World!"]] where I can leverage the existing functions operating on data in order to manipulate it.
ungzd 10y ago
Younger crowd still uses HTML and it's very similar to XML.

ungzd 10y ago

No syntax for comments, mandatory quotes everywhere, no trailing comma requirement, deeper nesting due to lower expressivity, lack of context (XML elements has name, json nodes usually has implicit context, for example in "Open API Specification" aka Swagger often it's hard to tell what current object expresses).