3 ms·

> Strong static typing, where most of your data is going across the wire as JSON, is a battle that is largely fought in incoherent ways. Is it really? Map<Stri

> Strong static typing, where most of your data is going across the wire as JSON, is a battle that is largely fought in incoherent ways. Is it really? Map<String,String> is a totally reasonable type to use in certain cases.

taeric 3y ago
Not to most of the debates you will see online. For one, they will be quick to throw that json is closer to Map<String, JsonAtom>, where JsonAtom can be JsonNumber, JsonArray, String, or Map<String, JsonAtom>. Then the clojure/lisp crowd will start to ask why can't they use a myriad of long standing tools that work on lists with this data. (And for more fun, the lisp crowd will point out that json is closer to an A-LIST, not a Map, since they allow duplicate keys... At this point, most of the crowd will rightfully tell us to shut it. :D) Though, to be clear, I think I largely agree with you. I don't necessarily think typing is a curse. I just don't think most of the typing debates we see online are really telling us much. I'm reminded of a while back when everyone was writing what a TODO app would look like with their favorite abstractions. When, realistically, all applications get dirty after you throw enough users and existing data at them.
- galdosdi 3y ago
  Yeah we are on the same page, lol. Practical usage isn't as sexy as diehard ideological arguments. That said, what JSON corresponds to doesn't matter -- you're parsing it into a data structure that makes sense for your use case. You do not need to represent arbitrary JSON, and should not -- only valid values. So maybe that means something like struct Person { String name; int age; enum Country birthplace; Map<String,String> other attributes; } I am baffled by the purists who act like this is somehow not allowed. Or if you genuinely are just building a generic JSON parsing library, that's easy enough as you described. The pseudo BNF definition of JSON is simply mapped directly to sum and product types. I have worked on (very lightly) a popular java Json library (Jackson) and it was no problem... Another problem is lately there are novice people whose only exposure to type systems is, of all things, typescript (or pep484 python) which is a horrible example of a practical type system because (much like pep484) it's been bolted on poorly onto an existing typeless language.

taeric 3y ago

Not to most of the debates you will see online. For one, they will be quick to throw that json is closer to Map<String, JsonAtom>, where JsonAtom can be JsonNumber, JsonArray, String, or Map<String, JsonAtom>. Then the clojure/lisp crowd will start to ask why can't they use a myriad of long standing tools that work on lists with this data. (And for more fun, the lisp crowd will point out that json is closer to an A-LIST, not a Map, since they allow duplicate keys... At this point, most of the crowd will rightfully tell us to shut it. :D) Though, to be clear, I think I largely agree with you. I don't necessarily think typing is a curse. I just don't think most of the typing debates we see online are really telling us much. I'm reminded of a while back when everyone was writing what a TODO app would look like with their favorite abstractions. When, realistically, all applications get dirty after you throw enough users and existing data at them.

galdosdi 3y ago
Yeah we are on the same page, lol. Practical usage isn't as sexy as diehard ideological arguments. That said, what JSON corresponds to doesn't matter -- you're parsing it into a data structure that makes sense for your use case. You do not need to represent arbitrary JSON, and should not -- only valid values. So maybe that means something like struct Person { String name; int age; enum Country birthplace; Map<String,String> other attributes; } I am baffled by the purists who act like this is somehow not allowed. Or if you genuinely are just building a generic JSON parsing library, that's easy enough as you described. The pseudo BNF definition of JSON is simply mapped directly to sum and product types. I have worked on (very lightly) a popular java Json library (Jackson) and it was no problem... Another problem is lately there are novice people whose only exposure to type systems is, of all things, typescript (or pep484 python) which is a horrible example of a practical type system because (much like pep484) it's been bolted on poorly onto an existing typeless language.