4 ms·

This guy was a professional C++ programmer for a couple of decades so he probably came across generics. I think it's possible you didn't catch the parts where

This guy was a professional C++ programmer for a couple of decades so he probably came across generics. I think it's possible you didn't catch the parts where he talks about what he wants from his data structures. There were 2 key pieces: + that he can transport them between environments, possibly remotely, possibly written in different programming languages + that parts of the system only need to know about parts of the data structure. More, that as the data structure is passed around the system, only the producer and consumer of changes to the structure are affected by the change. I'm not aware of any static type system, with generics or otherwise, that would meet these goals. At least not post-facto and highly artificially. Whether or not you agree with the priority he gives to these goals is, of course, a different matter.

wtetzner 9y ago
> that he can transport them between environments, possibly remotely, possibly written in different programming languages This is pretty easily solved in static languages with "serializable" interfaces, which can usually be automatically derived. E.g., in Rust, you can use #[derive(Serializable,Deserializable)], in OCaml, you can use [@@deriving sexp]. This also allows you to know at compile time which types can safely be serialized. In Clojure, if you have a type that contains an InputStream of some sort, it's not reasonable to serialize it. But you won't find out until runtime, when you happen to have an instance of that map with the InputStream.
Tehnix 9y ago
I'm fairly certain the comment you are replying to isn't talking about "generics" but "Generics" with a capital _G_. This bit, > while a sum type implementing functor with a record data constructor that contains a Maybe SSN is not indicates Hickey was talking about Haskell's type system, where you in fact can derive a Functor for you data type by using Generics. > + that he can transport them between environments, possibly remotely, possibly written in different programming languages There exist tools to generate types between languages. > only the producer and consumer of changes to the structure are affected by the change. If your function doesn't alter the data type, it needs no info on the structure of it. Perhaps you can expand on what you meant here? EDIT: Ehrm, why the downvotes? If you disagree with the above, explain what.
- carljv 9y ago
  Generics can make serialization easier in Haskell, but that's not exactly the point. The point is, once your Haskell program is done with that data, it's getting tossed into a message queue or database, or whatever, that doesn't really care or have any concept of what typeclasses it implements, whether one of its constructors is an Either, etc. In open systems you don't really get to decide who consumes your data or how--your program can't communicate anything other than data to them--and so you often don't have a way of enforcing your types on eventual consumers. Haskell has strong opinions about how it thinks data should be represented and aggregated. But in large open systems, as the saying goes, "opinions are like aholes; everybody has one." When I think about the popular tools for moving data around large open system: the message queues, key-val stores, pub-subs, etc. --- it seems to me that the idea moving and communicating about types and objects over wires has largely been a dud. Thinking RMI, OODBs, etc. It's just hard to get other people (tools, services) to care about how you've decided to organize the entities in your program. It's a lot of work, and the benefits over throwing mostly "plain" data may not be compelling enough. Again, I keep coming back to his term "parochialism" and why he's focused on it. I think it's an under-appreciated point amongst all the language wars.
  - Tehnix 9y ago
    I feel like this thread[0] in the discussion sorta delves into that. It's certainly an area with differing opinions and I can see why some might prefer having it simply be strings the whole way down, but at some point you are going to need to interact with the values you have, and at that point you need to know what type you are dealing with, so I really feel the serialisation argument is a bit weird. In databases you also have types on everything, albeit often less powerful. If not caring about types is really what you want, nothing stops you from treating everything as a String in Haskell. Heck, you can even do dynamic programming in Haskell with Data.Dynamic and Data.Typeable if you wanted to, but that sorta defeats the whole point of a nice and powerful type system. I think it's kinda ironic for you to bring up "parochialism" or narrow-mindedness when that is exactly what I was thinking throughout Hickeys talk. [0] https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_the_static_typing_world_haskell_in/doypbd3/ https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_...

wtetzner 9y ago

> that he can transport them between environments, possibly remotely, possibly written in different programming languages This is pretty easily solved in static languages with "serializable" interfaces, which can usually be automatically derived. E.g., in Rust, you can use #[derive(Serializable,Deserializable)], in OCaml, you can use [@@deriving sexp]. This also allows you to know at compile time which types can safely be serialized. In Clojure, if you have a type that contains an InputStream of some sort, it's not reasonable to serialize it. But you won't find out until runtime, when you happen to have an instance of that map with the InputStream.

Tehnix 9y ago

I'm fairly certain the comment you are replying to isn't talking about "generics" but "Generics" with a capital _G_. This bit, > while a sum type implementing functor with a record data constructor that contains a Maybe SSN is not indicates Hickey was talking about Haskell's type system, where you in fact can derive a Functor for you data type by using Generics. > + that he can transport them between environments, possibly remotely, possibly written in different programming languages There exist tools to generate types between languages. > only the producer and consumer of changes to the structure are affected by the change. If your function doesn't alter the data type, it needs no info on the structure of it. Perhaps you can expand on what you meant here? EDIT: Ehrm, why the downvotes? If you disagree with the above, explain what.

carljv 9y ago
Generics can make serialization easier in Haskell, but that's not exactly the point. The point is, once your Haskell program is done with that data, it's getting tossed into a message queue or database, or whatever, that doesn't really care or have any concept of what typeclasses it implements, whether one of its constructors is an Either, etc. In open systems you don't really get to decide who consumes your data or how--your program can't communicate anything other than data to them--and so you often don't have a way of enforcing your types on eventual consumers. Haskell has strong opinions about how it thinks data should be represented and aggregated. But in large open systems, as the saying goes, "opinions are like aholes; everybody has one." When I think about the popular tools for moving data around large open system: the message queues, key-val stores, pub-subs, etc. --- it seems to me that the idea moving and communicating about types and objects over wires has largely been a dud. Thinking RMI, OODBs, etc. It's just hard to get other people (tools, services) to care about how you've decided to organize the entities in your program. It's a lot of work, and the benefits over throwing mostly "plain" data may not be compelling enough. Again, I keep coming back to his term "parochialism" and why he's focused on it. I think it's an under-appreciated point amongst all the language wars.
- Tehnix 9y ago
  I feel like this thread[0] in the discussion sorta delves into that. It's certainly an area with differing opinions and I can see why some might prefer having it simply be strings the whole way down, but at some point you are going to need to interact with the values you have, and at that point you need to know what type you are dealing with, so I really feel the serialisation argument is a bit weird. In databases you also have types on everything, albeit often less powerful. If not caring about types is really what you want, nothing stops you from treating everything as a String in Haskell. Heck, you can even do dynamic programming in Haskell with Data.Dynamic and Data.Typeable if you wanted to, but that sorta defeats the whole point of a nice and powerful type system. I think it's kinda ironic for you to bring up "parochialism" or narrow-mindedness when that is exactly what I was thinking throughout Hickeys talk. [0] https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_the_static_typing_world_haskell_in/doypbd3/ https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_...