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.