3 ms·

There are basically two ways for a programming language to deal with JSON: (1) Expect it to conform to a contract. Marshal and unmarshal it to and from a back

There are basically two ways for a programming language to deal with JSON: (1) Expect it to conform to a contract. Marshal and unmarshal it to and from a backing data structure that represents that contract. Perhaps with some tolerance for missing or unexpected values. (2) Have no expectations of a contract. Parse the JSON string into a blob-tree of your programming language's "any" type. Just kinda yolo-wing-it with tree traversal, and hope that your language syntax is very null-tolerant. Try to overlook the fact that ultimately you DO have an expectation of contract after all (!)... it's just scattered through your tree-traversal logic, rather than consolidated in a data structure. I think pretty much all modern widely-used languages do a decent enough job with approach #1. While approach #2 is pretty much equally awful with all languages.

nitrogen 9y ago
Ruby does fine with #2. Fans of static type systems love to overstate perceived drawbacks of dynamic languages, but the simplicity of reading Ruby code built around JSON.parse vs. Scala or Kotlin with Jackson more than makes up for any type safety from the compiler. Also, there's a sort of intermediate step, a dynamic language with schema validation, for which I wrote a modestly well-used (within the overall schema validation gem market) gem a while ago. Then you can validate at the point of translation, without being beholden to a concrete data type (POJO, data class, case class, etc.) that has to be updated whenever the wire format changes.
- sidlls 9y ago
  "but the simplicity of reading Ruby code built around JSON.parse vs. Scala or Kotlin with Jackson more than makes up for any type safety from the compiler." "Readability" and "simplicity" are except for trivial or outlandish cases subjective. For example, I rather enjoy reading code using Rust's serde crate: the code is quite readable and comes with all the benefits of Rust's static type system and safety.
- yellowapple 9y ago
  Ruby also does a decent-enough job with #1, albeit with a bit of elbow grease required to massage arbitrary JSON data into Ruby class instances. Not as elegant as a static type system, sure, but still workable.
fiedzia 9y ago
> approach #2 is pretty much equally awful with all languages Some are far more awful than others. Python for example has no issue here at all, json types map nicely into its basic data types, while most statically typed languages make json handling terribly verbose and make it feel like it doesn't belong there. And while there usually is some contract, there are many api providers that don't provide schema, make frequent changes or explicitely expect you to deal with "some random json here" part of the data.

nitrogen 9y ago

Ruby does fine with #2. Fans of static type systems love to overstate perceived drawbacks of dynamic languages, but the simplicity of reading Ruby code built around JSON.parse vs. Scala or Kotlin with Jackson more than makes up for any type safety from the compiler. Also, there's a sort of intermediate step, a dynamic language with schema validation, for which I wrote a modestly well-used (within the overall schema validation gem market) gem a while ago. Then you can validate at the point of translation, without being beholden to a concrete data type (POJO, data class, case class, etc.) that has to be updated whenever the wire format changes.

sidlls 9y ago
"but the simplicity of reading Ruby code built around JSON.parse vs. Scala or Kotlin with Jackson more than makes up for any type safety from the compiler." "Readability" and "simplicity" are except for trivial or outlandish cases subjective. For example, I rather enjoy reading code using Rust's serde crate: the code is quite readable and comes with all the benefits of Rust's static type system and safety.
yellowapple 9y ago
Ruby also does a decent-enough job with #1, albeit with a bit of elbow grease required to massage arbitrary JSON data into Ruby class instances. Not as elegant as a static type system, sure, but still workable.

fiedzia 9y ago

> approach #2 is pretty much equally awful with all languages Some are far more awful than others. Python for example has no issue here at all, json types map nicely into its basic data types, while most statically typed languages make json handling terribly verbose and make it feel like it doesn't belong there. And while there usually is some contract, there are many api providers that don't provide schema, make frequent changes or explicitely expect you to deal with "some random json here" part of the data.