The author deals well with explaining the other side (to me) of this divisive topic. I spent many years preferring dynamic types before moving to static, yet I still don’t feel like I could have gone into the psychology this well; having done it doesn’t mean having understood my motivations.
I think the “where’s the fire” bit is probably the most important one for scientific computing.
The “speculative programming” part contains a bit on how Scala appears to have “two systems”. I find this to be one of the most wonderful parts of typed programming, tbh. These systems always exist—I’d call them perhaps the system of operation and the system of design—and types help you to isolate and focus on the behavior of each.
Finally, I have to comment on the “big class hierarchy” problem (mentioned in “less rope”). I really think that’s not so much a feature of type systems but instead particular type systems or even particular styles within particular type systems. This is just bad design, I feel, creating class hierarchy towers into the sky, but it’s almost required in languages without “generics” where subtype polymorphism was all you had.
This is a great post and explains a lot of what I love about Python. The author’s logic also could explain why Go is so easy to write and may account for its astounding rate of adoption. It’s so much easier to master both the running Go language and its type system compared to other statically typed languages, in my view.
This answer also puts last year’s popular posts, “Why Go Is Not Good” and “Go’s Type System Is An Embarrassment”, in perspective. The authors of those posts don’t appreciate how many people have trouble understanding complex type systems. A lack of understanding prevents programmers from using such languages effectively, which reduces overall adoption.
The Go approach just seems like the worst of both worlds. You pay all the costs of using Scala - indeed you pay a higher cost because you can’t use generics, so you end up creating more classes - but reap few of the benefits.
indeed you pay a higher cost because you can’t use generics, so you end up creating more classes
Go doesn’t have classes.