4 ms·

To add to this, dynamic typing is proper tool to use for API, because the input payload is just formatted text, without / with very few type definition. My expe

To add to this, dynamic typing is proper tool to use for API, because the input payload is just formatted text, without / with very few type definition. My experience said that it's hard to play with JSON on static typing, without adding a strict data validation / conversion at the start. Serialization comes with a set of strict rules that need to follow and state beforehand too. The contrary, on dynamic typing language nested object as well as array can easily be parsed natively and be used immediately.

yakshaving_jgt 7y ago
This is absolutely false. Not a single word you have written in this comment is true. This is a pervasive myth that you are perpetuating. If you had read the article, you would know that what you have said is demonstrably false. There is nothing stopping you from operating on arbitrary JSON in Haskell. Literally nothing.
- dboreham 7y ago
  I suspect the parent wants to convert between JSON and typed records without needing the JSON to conform to the type.
  - yakshaving_jgt 7y ago
    Ok, but this works just fine in Haskell. If you have a well-formed JSON string and you want to parse it as a generic value, you can parse it into the Value type. If you have a typed record (something less general than a Value) and a JSON string that has enough of the structure to be parsed into that typed record, you can parse it into that typed record. If the JSON string has extra structure/data/fields your parser didn't expect, it's fine. Your JSON parser in Haskell can ignore those extra things. Just like any dynamic language. All of this was demonstrated in the article.
sethammons 7y ago
We switched out some API code from Perl and Python to Go. JSON has been a pain at times for sure. Arbitrary nesting, values that are sometimes strings or sometimes integers (3 vs "3"), dynamic keys, and null vs zero value. These JSON structures were much easier to deal with before because we could be sloppy. Having to have a typed schema was a pain at first, but we love it after. And better yet, we can be confident of the values that we emit and our customers (internal and external) can be now use something statically typed if they like as we did all the heavy lifting.
aliceryhl 7y ago
It sounds like you think adding a conversion at the start is difficult and cumbersome, but it isn't if you use a good serialization library. E.g. with the Rust library serde, you just define the shape you expect your JSON data to have and plop a #[derive(Deserialize)] on it. Boom, fully failsafe JSON deserialization into the type.

yakshaving_jgt 7y ago

This is absolutely false. Not a single word you have written in this comment is true. This is a pervasive myth that you are perpetuating. If you had read the article, you would know that what you have said is demonstrably false. There is nothing stopping you from operating on arbitrary JSON in Haskell. Literally nothing.

dboreham 7y ago
I suspect the parent wants to convert between JSON and typed records without needing the JSON to conform to the type.
- yakshaving_jgt 7y ago
  Ok, but this works just fine in Haskell. If you have a well-formed JSON string and you want to parse it as a generic value, you can parse it into the Value type. If you have a typed record (something less general than a Value) and a JSON string that has enough of the structure to be parsed into that typed record, you can parse it into that typed record. If the JSON string has extra structure/data/fields your parser didn't expect, it's fine. Your JSON parser in Haskell can ignore those extra things. Just like any dynamic language. All of this was demonstrated in the article.

sethammons 7y ago

We switched out some API code from Perl and Python to Go. JSON has been a pain at times for sure. Arbitrary nesting, values that are sometimes strings or sometimes integers (3 vs "3"), dynamic keys, and null vs zero value. These JSON structures were much easier to deal with before because we could be sloppy. Having to have a typed schema was a pain at first, but we love it after. And better yet, we can be confident of the values that we emit and our customers (internal and external) can be now use something statically typed if they like as we did all the heavy lifting.

aliceryhl 7y ago

It sounds like you think adding a conversion at the start is difficult and cumbersome, but it isn't if you use a good serialization library. E.g. with the Rust library serde, you just define the shape you expect your JSON data to have and plop a #[derive(Deserialize)] on it. Boom, fully failsafe JSON deserialization into the type.