5 ms·
I found the discussion on /r/haskell to be much pleasant and a good take on the points Hickey make https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_t
by Tehnix 9y ago
I found the discussion on /r/haskell to be much pleasant and a good take on the points Hickey make https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_the_static_typing_world_haskell_in/ https://www.reddit.com/r/haskell/comments/792nl4/clojure_vs_... (it's actually a discussion on a piece discussing his talk).
I honestly don't find Hickeys arguments to be very valid, and his take on type systems honestly make him sound like he never touched something like Haskell (maybe OCaml) with much more powerful type systems and type inference. He does not sound like someone that invented a language, and more sounds like a blind evangelist for dynamic typing.
> static type systems yield much more heavily coupled systems. And that a big part of that time aspect of the final diagram of what problem we're trying to solve, is dominated by coupling when you're trying to do maintenance, right? Flowing type information is a major source of coupling in programs. Having a de-, you know, pattern matching of a structural representation in a hundred places in your program is coupling, right?
His arguments about coupling seems silly to me, especially since in FP you usually like generalisations and abstractions that allow you to delay specialising to a specific type until quite late. Take all the different typeclasses that exist in Haskell and things like Monads, Applicatives etc that allow such general abstraction.
> Names dominate semantics, a to a, list of a to list of a [talking about `foobar :: [a] -> [a]`], it means nothing, it tells you nothing
It tells so much! It tells us that it takes in a list of any element and the only operations it can perform are something that alters the structure of the list (replicate elements, drop elements etc) and no operations on the elements themselves!
> How many people like UML? How many people have ever used a UML diagramming tool? Right? It's not fun, right? It's like, "no, you can't connect that to that", "oh no, you have to use that kind of arrow", "no, you can't do this", "no, you can't...", it's terrible. OmniGraffle is much better, draw whatever you want. What are you thinking about? Draw that. What's important? Write that down. That's how it should work, right?
I chuckled a bit here, since Hickey just talked about Simon Peyton Jones in the previous slide, I'm assuming he at least Haskell in mind somewhat. If Hickey is seriously comparing Haskell's type system with UML, he needs to go back and take another serious look at Haskell.
> Yes, IntelliSense is much helped by static types and performance optimization, which he didn't list, but I think is one of the biggest benefits. We loved that in C++. And maintenance, I think it's not true. I think that they've created problems that they now use types to solve. Oh, I pattern-matched this thing 500 places and I want to add another thing in the middle. Well thank goodness I have types to find those 500 places. But the fact was that thing I added, nobody should have cared about except the new code that consumed it and if I did that a different way I wouldn't have had to change anything except the producer and the consumer, not everybody else who couldn't possibly know about it, right? It's new.
Honestly this just comes off incredibly stupid and Hickey quite clearly shows he's never programmed in a language with a type system more powerful than C++ or the likes. One of THE BIGGEST advantages of a powerful system is exactly maintenance. He makes the straw man that you have to pattern match every place you lead a type through in your code base, and that you can't "not care" about certain parts of the constructor, but that is just so incorrect. He was half onto the point of, with the compiler telling you all the places you'd have to refactor thought. And that IntelliSense is the only thing he seems to come up with as valid arguments for types...I think that says more about his understanding of types than anything.
I'm gonna leave the rest of the comments up to the discussion I posted in the top, else I would just be rehashing it.
- rtpg 9y agoThe one point about coupling in type systems is the names. While some languages (Typescript comes to mind) has structural typing, languages like Haskell tend to have nominal typing. So even if your data _looks like_ {'amount': 100, 'currency': 'USD'}, becuase you've wrapped it in a "Money" ADT, now its treated as a different object. Now sometimes this is valuable! There's a reason we have "newtypes" in a lot of these languages. But other times you end up having to do a lot of wrapping/unwrapping for little reason beyond the type system. There's a lot of compiler-related reasons for this stuff as well, but if you work a lot in duck-typed languages you can end up getting used to writing stuff that works across data types without any fuss.
- Tehnix 9y agoI can certainly see how that would bring frustrations, especially if you come from a dynamically-typed language (heck, even if you start out in Haskell it'll annoy you). It's worth noting though, that row polymorphism/structural typing also exist in Elm and PureScript, and there are some libraries in Haskell[0] that attempt to solve it using various approaches (admittedly not as nice as first-class support). I guess my larger problem is that he uses it as an argument static types, whereas it's a solved problem in several existing type systems that has implemented row polymorphism. [0] https://www.reddit.com/r/haskell/comments/5p307s/row_polymorphism_or_something_similar/ https://www.reddit.com/r/haskell/comments/5p307s/row_polymor...
- rtpg 9y agoI've worked with Purescript and agree it helps solve it, though I am willing to cut some slack to Hickley to not being super aware of row polymorphism. It's been an academic thing for a while, but only fairly recently has it been a thing in even very small languages with use like Elm. I also feel like a lot of these tools still have some difficulties. There's some conflicts where you can't declare typeclasses on pure Object records in purescript (instead having to go through a wrapper class). Still agree that forward progress is happening and interesting
- carljv 9y ago