6 ms·

It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them, doesn't matter i

• diggan 1y ago
  > It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them Generally speaking I feel like this is true for a lot of stuff in programming circles, XML included. New technology appears, some people play around with it. Others come up with using it for something else. Give it some time, and eventually people start putting it everywhere. Soon "X is not for Y" blogposts appear, and usage finally starts to decrease as people rediscover "use the right tool for the right problem". Wait yet some more time, and a new technology appears, and the same cycle begins again. Seen it with so many things by now that I think "we'll" (the software community) forever be stuck in this cycle and the only way to win is to explicitly jump out of the cycle and watch it from afar, pick up the pieces that actually make sense to continue using and ignore the rest.
  • colonwqbang 1y ago
    There have been many such cycles, but the XML hysteria of the 00s is the worst I can think of. It lasted a long time and the square peg XML was shoved into so many round holes.
    • 0x445442 1y ago
      IDK, the XML hysteria is similar by comparison to the dynamic and functional languages hysterias. And it pales in comparison to the micro services, SPA and the current AI hysterias.
      • xorcist 1y ago
        Agreed. Also, Docker.
      • homebrewer 1y ago
        IMHO it's pretty comparable, the difference is only in the magnitude of insanity. After all, the industry did crap out these hardware XML accelerators that were supposed to improve performance of doing massive amounts of XML transformations — is it not the GPU/TPU craze of today? https://en.wikipedia.org/wiki/XML_appliance https://en.wikipedia.org/wiki/XML_appliance E.g. https://www.serverwatch.com/hardware/power-up-xml-data-processing-with-the-datapower-xa35-xml-accelerator/ https://www.serverwatch.com/hardware/power-up-xml-data-proce...
        • soulofmischief 1y ago
          At least arrays of numbers are naturally much closer to the hardware, we've definitely come a long way in that regard.
        • bogeholm 1y ago
          From your first link > An XML appliance is a special-purpose network device used to secure, manage and mediate XML traffic. Holy moly
      • vjvjvjvjghv 1y ago
        Exactly. Compared to microservices XML is a pretty minor problem.
  • colejohnson66 1y ago
    A controversial opinion, but JSON is that too. Not as bad as XML was (̶t̶h̶e̶r̶e̶'̶s̶ ̶n̶o̶ ̶"̶J̶S̶L̶T̶"̶)̶, but wasting cycles to manifest structured data in an unstructured textual format has massive overhead on the source and destination sides. It only took off because "JavaScript everywhere" was taking off — performance be damned. Protobufs and other binary formats already existed, but JSON was appealing because it's easily inspectable (it's plaintext) and easy to use — `JSON.stringify` and `JSON.parse` were already there. We eventually said, "what if we made databases based on JSON" and then came MongoDB. Worse performance than a relational database, but who cares! It's JSON! People have mostly moved away from document databases, but that's because they realized it was a bad idea for the majority of usecases.
    • ako 1y ago
      There is JSLT: https://github.com/schibsted/jslt https://github.com/schibsted/jslt and it can be useful if you need to transform a json document into another json structure.
      • deleted 1y ago
        [deleted]
      • nolok 1y ago
        The people who made that are either very funny in a sarcastic, way or in severe lack of a history lesson of the area they're working in.
        • ako 1y ago
          What is a better alternative if you just need to transform JSON from one structure to another JSON structure?
          • asa400 1y ago
            Load it into a full programming language runtime and use the great collections libraries available in almost all languages to transform it and then serialize it into your target format. I want to use maps and vectors and real integers and functions and date libraries and spec libraries. String to string processing is hell.
• chriswarbo 1y ago
  > part of the problem with the entire "XML as a savior" mindset of that earlier era I think part of the problem is focusing on the wrong aspect. In the case of XSLT, I'd argue its most important properties are being pure, declarative, and extensible. Those can have knock-on effects, like enabling parallel processing, untrusted input, static analysis, etc. The fact it's written in XML is less important. Its biggest competitor is JS, which might have nicer syntax but it loses those core features of being pure and declarative (we can implement pure/declarative things inside JS if we like, but requiring a JS interpreter at all is bad news for parallelism, security, static analysis, etc.). When fashions change (e.g. XML giving way to JS, and JSON), we can end up throwing out good ideas (like a standard way to declare pure data transformations). (Of course, there's another layer to this, since XML itself was a more fashionable alternative to S-expressions; and XSLT is sort of like Lisp macros. Everything old is new again...)
• em-bee 1y ago
  Those were defined as machine language meant for machine talking to machine i don't believe this is true. machine language doesn't need the kind of verbosity that xml provides. sgml/html/xml were designed to allow humans to produce machine readable data. so they were meant for humans to talk to machines and vice versa.
  • soulofmischief 1y ago
    Yes, I think the main difference is having imperative vs declarative computation. With declarative computation, the performance of your code is dependent on the performance and expressiveness of the declarative layer, such as XML/XSLT. XSLT lacks the expressiveness to get around its own performance limitations.
• jimbokun 1y ago
  It was very odd that a simple markup language was somehow seen as the savior for all computing problems. Markup languages are a fine and useful and powerful way for modeling documents, as in narrative documents with structure meant for human consumption. XML never had much to recommend it as the general purpose format for modeling all structured data, including data meant primarily for machines to produce and consume.
• vjvjvjvjghv 1y ago
  Now we have "JSON as savior". I see it way too often where new people come into a project and the first thing they want to do is to replace all XML with JSON, just because. Never mind that this solves basically nothing and often introduces its own set of problems. I am not a big fan of XML but to me it's pretty low in the hierarchy of design problems.
  • SoftTalker 1y ago
    The only problem with XML is the verbosity of the markup. Otherwise it's a nice way to structure data without the bizarre idiosyncracies of YAML or JSON.
    • int_19h 1y ago
      I mean, XML has its own bizarre idiosyncrasies like the whole attribute vs child element distinction (which maps nicely to text markup but less so for object graphs). I would say that the main benefit of XML is that it has a very mature ecosystem around it that JSON is still very much catching up with.
    • vjvjvjvjghv 1y ago
      XML has its own set of idiosyncrasies like everything being a string. Or no explicit markup of arrays. The whole confusion around attributes vs values. And many others. JSON has its own set of problems like lack of comments and for some reason no date type. But in the end they are just data file formats. We have bigger things to worry about.
• deleted 1y ago
  [deleted]