4 ms·

I write a lot of smaller service agents, connecting legacy systems or feeding them with data in the public sector of Denmark. Most of those are done with XML an

I write a lot of smaller service agents, connecting legacy systems or feeding them with data in the public sector of Denmark. Most of those are done with XML and it’s often quite terrible. We write a lot of C# but one of our tools is an old adobe lifecycle server, and .Net XML isn’t the same as Adobe XML. I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break when they aren’t. So in order to make the two techs talk with each other through SOAP, we had to write a custom library to translate the .Net xml before we send it. And that’s just one in a long line of similar stories. Hell, SOAP calls en general take longer time to get running than any JSON rest service call I’ve ever set up. Even when the XML interprets the same on both ends, though I’m not sure why that is exactly. So it’s fair to say that I love JSON. The article outlines it as being easier to read, and there is certainly that, but for me it’s the efficiency. Working with JSON never takes longer than it should.

humbleMouse 8y ago
> Working with JSON never takes longer than it should. This is the key point right here. JSON is a big reason I love groovy so much. No matter what json you have in groovy, you are a couple lines of code and a couple closures away from doing anything. I always use json string payloads on HTTP aswell. It vastly simplifies rest service development. Another thing I love about json is using it with cassandra. So easy to store big maps that hold the state of different things. Dont even get me started on avro/kafka/etc....
- taeric 8y ago
  You would have loved s-expressions in a typical lisp setup, then. :) And you have also obviously never fallen victim to slightly off spec JSON parsers and folks that took advantage of them. Trailing commas? Definitely useful. Until they break a system. (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...)
  - TuringTest 8y ago
    That may be because you don't need to keep track of how many commas are there, you can just throw them in wherever you need one. Yet parentheses must always come in pairs, you need a pair for every term in the program (brackets are only needed for full statements), and they tend to pile down at the end of complex functions and data structures.
    - taeric 8y ago
      I have seen more than my fair share of build failures from missing or extra commas. Worse, they have odd behavior in some languages. That said, I cede that they are different. I just don't get the hate of parens.
      - sli 8y ago
        My frontend builds fail because of trailing commas in the code (by design, so technically a non-issue). At the same time, my editors can balance parens but they can't really do anything but complain about trailing commas. It can't assume it's an issue and "fix" it because I just might not be done writing, yet. My editor can make more and safer assumptions about paren balancing, however, and so it does. I really have no horse in this race, neither of these things bother me. I just can't help but notice that the paren problem in particular can be easily rectified.
        TuringTest 8y ago
        Yeah, I concur. I mean, instances have a "global stream" where all posts from all users are sent? What's the use for that? It would be like Facebook or Twitter having a "front page" showing all posts from all their users. I don't want to read what something posted merely because they're subscribed to the same physical server. There should be some classification of affinity by common interests.
  - jcelerier 8y ago
    > (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...) I just checked an a comma is a grand total of three filled pixels on my coding font in my screen while a parenthese is 12 pixels. Parentheses are freakin visual bloat. Just look at this : https://i.imgur.com/UTGjbI5.png https://i.imgur.com/UTGjbI5.png
- gaius 8y ago
  Ah, Groovy. All the brevity of Java and all the type safety of JavaScript. I had no idea anyone still used it, let alone loved it!
  - zmmmmm 8y ago
    Pretty much wrong on all counts - doesn't sound like you know very much about groovy at all?
    - gaius 8y ago
      Have unfortunately had to use it as it was the scripting language embedded in an application we used. Now I avoid it whenever possible. Even BeanShell was better!
  - rhencke 8y ago
    That's an unfortunate stance on Groovy. Groovy code is often far more brief than Java's, and it has some beautifully expressive capability for making DSLs, both through its world-view on closures and its ability for the developer to walk and modify the AST at compile time (see, for example, the @Canonical attribute for how this can be useful) While I, too, wish it built on a statically typed base, Groovy offers amenities such as @CompileStatic that go a long way towards alleviating this. I personally find Kotlin strikes a wonderful spot with the brevity and expressiveness of Groovy, while managing to be more type-safe than Java (reified generics, null safety in the type system). But there is no denying Groovy's heavy influence on Kotlin, either. Groovy may not be perfect but I don't think the picture you paint is accurate, either.
    - vorg 8y ago
      If you need to use the JVM ... > walk and modify the AST at compile time Clojure is best for this. A macro only a few lines long in Clojure will do the same as what a few hundred lines in Apache Groovy are required for. It's possible to walk the AST in Groovy but it's verbose and messy. > CompileStatic that go a long way Both Kotlin and Scala are both statically typed from the ground up, instead of having a @CompileStatic annotation tacked on later. > the brevity and expressiveness of Groovy Groovy started off in 2003 as a functionally similar clone of Beanshell, which had already existed since 1999, but with closures added. Someone then translated all the standard functional methods from Ruby into Groovy's codebase. Of course, Jython, a JVM version of Python, has been around since 1997. So Groovy is a relative late comer to the JVM in this regard. Groovy tried to be a bit of everything for everyone on the JVM, but has ended up being used only for 20-line build scripts in Gradle.
bouke 8y ago
You’re comparing SOAP, a message protocol, with JSON, a data format. SOAP is so much more, it specifies how objects are defined, how they should be serialized and delivered to a server (WSDL). Note that JSON doesn’t have anything like this that has seriously taken off. There’s a few attempts, but they aren’t in great use or have tooling support. So as a result everyone working with JSON implements their own de-/serializer, resulting in all sorts of errors. SOAP on the other hand takes care of this and even has a formalized date type and various number types. Your complaint is about two vendors creating incompatible inplementations/extensions. I’ve run into this as well and causes a lot of issues with compliant implementations that cannot work together. I think this has been a big reason why eventually SOAP will die.
- donmatito 8y ago
  I think parent's point was that with JSON you are, in most langages, a JSON.parse(payload) away from a message protocol. I am interfacing our startup's services with legacy (insurers) systems. We don't use the same programming langage. The docs are missing. Yet, we somehow manage to set up a functional API with minimal pain using JSON. When I compare that, to the amount of documentation a SOAP service requires (for another partner), I find JSON much more usable
- sametmax 8y ago
  Yeah but most projects I worked on used soap as a data format. I had to interface with a french administration that parsed the xml manually (poeple printed and read it) and an american administration that used regex to read the xml. Just having devs reading the dom correctly, including namespaces, is a rare occurence. It's sad, but we are living in a time were too many software is written, and not enough competent devs are available. So simplicity, again, wins.
- sidstling 8y ago
  I did specifically say it wasn’t technically the languages fault, but you certainly have a point. I don’t think it’s completely unreasonable to bring in SOAP even though you’re talking about the language, because I’ve almost never worked with XML without also working with SOAP. But in not completely comparing it to JSON either, I mean, I love JSON for the efficiency of transferring it between systems, so I’m not completely comparing XML/SOAP to JSON the language either. As far as lifecycle goes, it’s not actually the SOAP call but the way the two tech stacks parse the XML that’s the problem. You can also do rest calls with livecycle, and you’ll run into the same problems trying to pass XML created by any of the standard .net libraries to it. I agree SOAP is terrible, but part of my point is that SOAP taints XML, because it’s a really common way to transfer XML. I do use XML in other ways of course. We get quite a few datadumps in XML, that I turn to SQL through Microsoft SSIS, and even here it’s annoying. Not so much the language, but the way it breaks your SSIS service if it’s not delivered exactly as specified in its schema. Obviously that shouldn’t happen, but it does. Sometimes a supplier delivers half a file, and everything because SSIS didn’t get the XML specified in the schematic. (The fact that this breaks this is another wonderful story, where multiple datasets gets delivered within the same XML file.) JSON and XML are languages, as you say, but their main usage (at least for me) is transferring data between systems and techs, and that is almost always easier, simpler and safer with JSON. Maybe it’s unfair to call JSON the better language because of that, but it’s certainly more useful to me.
collyw 8y ago
It does. Its not that much different from Python dictionaries, but those are so much more pleasant to work with. Trailing commas, comments (in large multiline dictionaries) and proper integers are some features I can think of. Small things like those can make a big difference in ease of use for many practical cases.
Zardoz84 8y ago
> I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break when they aren’t. So in order to make the two techs talk with each other through SOAP, we had to write a custom library to translate the .Net xml before we send it. And that’s just one in a long line of similar stories. Something similar happens me with Java. Our product have some legacy ancient code that serialize/deserialize XML to beans using a library (JOX) that works with pure reflection (pre Java annotations). I try to replace it for something more modern like Jackson or JAXB, but I hit a wall when I found that the XML that reads/writes these library are very different from what Jackson or JAXB expect to find. So, or we translate all XMLs to the new format or I write some translator to transform the old XMLs to something more standard.

humbleMouse 8y ago

> Working with JSON never takes longer than it should. This is the key point right here. JSON is a big reason I love groovy so much. No matter what json you have in groovy, you are a couple lines of code and a couple closures away from doing anything. I always use json string payloads on HTTP aswell. It vastly simplifies rest service development. Another thing I love about json is using it with cassandra. So easy to store big maps that hold the state of different things. Dont even get me started on avro/kafka/etc....

taeric 8y ago
You would have loved s-expressions in a typical lisp setup, then. :) And you have also obviously never fallen victim to slightly off spec JSON parsers and folks that took advantage of them. Trailing commas? Definitely useful. Until they break a system. (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...)
- TuringTest 8y ago
  That may be because you don't need to keep track of how many commas are there, you can just throw them in wherever you need one. Yet parentheses must always come in pairs, you need a pair for every term in the program (brackets are only needed for full statements), and they tend to pile down at the end of complex functions and data structures.
  - taeric 8y ago
    I have seen more than my fair share of build failures from missing or extra commas. Worse, they have odd behavior in some languages. That said, I cede that they are different. I just don't get the hate of parens.
    - sli 8y ago
      My frontend builds fail because of trailing commas in the code (by design, so technically a non-issue). At the same time, my editors can balance parens but they can't really do anything but complain about trailing commas. It can't assume it's an issue and "fix" it because I just might not be done writing, yet. My editor can make more and safer assumptions about paren balancing, however, and so it does. I really have no horse in this race, neither of these things bother me. I just can't help but notice that the paren problem in particular can be easily rectified.
      - TuringTest 8y ago
        Yeah, I concur. I mean, instances have a "global stream" where all posts from all users are sent? What's the use for that? It would be like Facebook or Twitter having a "front page" showing all posts from all their users. I don't want to read what something posted merely because they're subscribed to the same physical server. There should be some classification of affinity by common interests.
- jcelerier 8y ago
  > (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...) I just checked an a comma is a grand total of three filled pixels on my coding font in my screen while a parenthese is 12 pixels. Parentheses are freakin visual bloat. Just look at this : https://i.imgur.com/UTGjbI5.png https://i.imgur.com/UTGjbI5.png
gaius 8y ago
Ah, Groovy. All the brevity of Java and all the type safety of JavaScript. I had no idea anyone still used it, let alone loved it!
- zmmmmm 8y ago
  Pretty much wrong on all counts - doesn't sound like you know very much about groovy at all?
  - gaius 8y ago
    Have unfortunately had to use it as it was the scripting language embedded in an application we used. Now I avoid it whenever possible. Even BeanShell was better!
- rhencke 8y ago
  That's an unfortunate stance on Groovy. Groovy code is often far more brief than Java's, and it has some beautifully expressive capability for making DSLs, both through its world-view on closures and its ability for the developer to walk and modify the AST at compile time (see, for example, the @Canonical attribute for how this can be useful) While I, too, wish it built on a statically typed base, Groovy offers amenities such as @CompileStatic that go a long way towards alleviating this. I personally find Kotlin strikes a wonderful spot with the brevity and expressiveness of Groovy, while managing to be more type-safe than Java (reified generics, null safety in the type system). But there is no denying Groovy's heavy influence on Kotlin, either. Groovy may not be perfect but I don't think the picture you paint is accurate, either.
  - vorg 8y ago
    If you need to use the JVM ... > walk and modify the AST at compile time Clojure is best for this. A macro only a few lines long in Clojure will do the same as what a few hundred lines in Apache Groovy are required for. It's possible to walk the AST in Groovy but it's verbose and messy. > CompileStatic that go a long way Both Kotlin and Scala are both statically typed from the ground up, instead of having a @CompileStatic annotation tacked on later. > the brevity and expressiveness of Groovy Groovy started off in 2003 as a functionally similar clone of Beanshell, which had already existed since 1999, but with closures added. Someone then translated all the standard functional methods from Ruby into Groovy's codebase. Of course, Jython, a JVM version of Python, has been around since 1997. So Groovy is a relative late comer to the JVM in this regard. Groovy tried to be a bit of everything for everyone on the JVM, but has ended up being used only for 20-line build scripts in Gradle.

bouke 8y ago

You’re comparing SOAP, a message protocol, with JSON, a data format. SOAP is so much more, it specifies how objects are defined, how they should be serialized and delivered to a server (WSDL). Note that JSON doesn’t have anything like this that has seriously taken off. There’s a few attempts, but they aren’t in great use or have tooling support. So as a result everyone working with JSON implements their own de-/serializer, resulting in all sorts of errors. SOAP on the other hand takes care of this and even has a formalized date type and various number types. Your complaint is about two vendors creating incompatible inplementations/extensions. I’ve run into this as well and causes a lot of issues with compliant implementations that cannot work together. I think this has been a big reason why eventually SOAP will die.

donmatito 8y ago
I think parent's point was that with JSON you are, in most langages, a JSON.parse(payload) away from a message protocol. I am interfacing our startup's services with legacy (insurers) systems. We don't use the same programming langage. The docs are missing. Yet, we somehow manage to set up a functional API with minimal pain using JSON. When I compare that, to the amount of documentation a SOAP service requires (for another partner), I find JSON much more usable
sametmax 8y ago
Yeah but most projects I worked on used soap as a data format. I had to interface with a french administration that parsed the xml manually (poeple printed and read it) and an american administration that used regex to read the xml. Just having devs reading the dom correctly, including namespaces, is a rare occurence. It's sad, but we are living in a time were too many software is written, and not enough competent devs are available. So simplicity, again, wins.
sidstling 8y ago
I did specifically say it wasn’t technically the languages fault, but you certainly have a point. I don’t think it’s completely unreasonable to bring in SOAP even though you’re talking about the language, because I’ve almost never worked with XML without also working with SOAP. But in not completely comparing it to JSON either, I mean, I love JSON for the efficiency of transferring it between systems, so I’m not completely comparing XML/SOAP to JSON the language either. As far as lifecycle goes, it’s not actually the SOAP call but the way the two tech stacks parse the XML that’s the problem. You can also do rest calls with livecycle, and you’ll run into the same problems trying to pass XML created by any of the standard .net libraries to it. I agree SOAP is terrible, but part of my point is that SOAP taints XML, because it’s a really common way to transfer XML. I do use XML in other ways of course. We get quite a few datadumps in XML, that I turn to SQL through Microsoft SSIS, and even here it’s annoying. Not so much the language, but the way it breaks your SSIS service if it’s not delivered exactly as specified in its schema. Obviously that shouldn’t happen, but it does. Sometimes a supplier delivers half a file, and everything because SSIS didn’t get the XML specified in the schematic. (The fact that this breaks this is another wonderful story, where multiple datasets gets delivered within the same XML file.) JSON and XML are languages, as you say, but their main usage (at least for me) is transferring data between systems and techs, and that is almost always easier, simpler and safer with JSON. Maybe it’s unfair to call JSON the better language because of that, but it’s certainly more useful to me.

collyw 8y ago

It does. Its not that much different from Python dictionaries, but those are so much more pleasant to work with. Trailing commas, comments (in large multiline dictionaries) and proper integers are some features I can think of. Small things like those can make a big difference in ease of use for many practical cases.

Zardoz84 8y ago

> I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break when they aren’t. So in order to make the two techs talk with each other through SOAP, we had to write a custom library to translate the .Net xml before we send it. And that’s just one in a long line of similar stories. Something similar happens me with Java. Our product have some legacy ancient code that serialize/deserialize XML to beans using a library (JOX) that works with pure reflection (pre Java annotations). I try to replace it for something more modern like Jackson or JAXB, but I hit a wall when I found that the XML that reads/writes these library are very different from what Jackson or JAXB expect to find. So, or we translate all XMLs to the new format or I write some translator to transform the old XMLs to something more standard.