5 ms·

The Clojure code is shorter, but that's almost entirely because it's dynamically typed. And that's not necessarily a benefit, either. Cheshire just takes JSON a

The Clojure code is shorter, but that's almost entirely because it's dynamically typed. And that's not necessarily a benefit, either. Cheshire just takes JSON and turns it into plain old Clojure data (maps, vectors, strings or keywords, etc.) whereas Aeson requires the programmer to manually unroll the whole structure from top to bottom into user-defined types. But by doing so it guarantees that if something is missing or unexpected, the code fails early and fails fast. Plus the static typing enables compile-time checking of all your code which uses it, rather than how Clojure accesses JSON which is so often stringly-typed because that's easiest/shortest/fastest.

fbreduc 10y ago
hmm still unsure what the types win me then
- pseudonom- 10y ago
  It's pretty handy to only have to be vigilant at the boundary layer. With the untyped approach, all consumers of the deserialized map have to guard against data which doesn't conform to expectations. With the typed approach, all subsequent functions only have to work with data conforming to the specification as laid out by types.
- alexbanks 10y ago
  If your only benchmark is less code, dynamic typing is fine. This example also doesn't really exemplify the value of static typing, in that the example is a "sandboxed"(it does not have to work with external APIs, other developers, etc) "non-maintained"(once it's written it won't change over a few years requiring support) code block. An example of "Lets take 6 devs and have them build something" would probably create a more obvious use for Haskell over Clojure, as the biggest problem (to me) with Dynamic Typing is its scalability under development. As in, alone I (and most devs) could write dynamically typed code with little issue, as all decisions are made internally and guard cases can be written correctly based on those internal decisions. But throwing a second dev (or n devs) into the mix makes those internal decisions much more difficult, making the guard clauses much more difficult to write correctly. Static typing takes a lot of the guard-clause-writing out of the picture, as the compiler creates them for you.
- sgk284 10y ago
  It completely eliminates a class of runtime errors from your code, while also allowing all code that consumes the data to make assumptions about the data. In the untyped code you must validate everywhere you access the data or trust that someone above you already validated it (which can break silently with any future modification).
platz 10y ago
Aeson/Haskell doesn't require decoding json into user-defined data types. It supports the scenario of turning the data into a plain Map (clojure style) as well. The plain Map style is simply a less preferred paradigm in haskell, but its very easy to support this. Getting a map out from your json is a one liner.
riboflava 10y ago
http://clojure.org/about/spec http://clojure.org/about/spec
Royalaid 10y ago
While it isn’t a static guarantee, clojure’s new spec lib (https://clojure.org/about/spec https://clojure.org/about/spec), get you out of just being stringly typed

fbreduc 10y ago

hmm still unsure what the types win me then

pseudonom- 10y ago
It's pretty handy to only have to be vigilant at the boundary layer. With the untyped approach, all consumers of the deserialized map have to guard against data which doesn't conform to expectations. With the typed approach, all subsequent functions only have to work with data conforming to the specification as laid out by types.
alexbanks 10y ago
If your only benchmark is less code, dynamic typing is fine. This example also doesn't really exemplify the value of static typing, in that the example is a "sandboxed"(it does not have to work with external APIs, other developers, etc) "non-maintained"(once it's written it won't change over a few years requiring support) code block. An example of "Lets take 6 devs and have them build something" would probably create a more obvious use for Haskell over Clojure, as the biggest problem (to me) with Dynamic Typing is its scalability under development. As in, alone I (and most devs) could write dynamically typed code with little issue, as all decisions are made internally and guard cases can be written correctly based on those internal decisions. But throwing a second dev (or n devs) into the mix makes those internal decisions much more difficult, making the guard clauses much more difficult to write correctly. Static typing takes a lot of the guard-clause-writing out of the picture, as the compiler creates them for you.
sgk284 10y ago
It completely eliminates a class of runtime errors from your code, while also allowing all code that consumes the data to make assumptions about the data. In the untyped code you must validate everywhere you access the data or trust that someone above you already validated it (which can break silently with any future modification).

platz 10y ago

Aeson/Haskell doesn't require decoding json into user-defined data types. It supports the scenario of turning the data into a plain Map (clojure style) as well. The plain Map style is simply a less preferred paradigm in haskell, but its very easy to support this. Getting a map out from your json is a one liner.

riboflava 10y ago

http://clojure.org/about/spec http://clojure.org/about/spec

Royalaid 10y ago

While it isn’t a static guarantee, clojure’s new spec lib (https://clojure.org/about/spec https://clojure.org/about/spec), get you out of just being stringly typed