"It is much easier to quickly prototype or experiment in a dynamic language."
I disagree. I can say what I mean with types, and if I didn't mean what I said, refactoring is a breeze.
"You don't have to stop and figure out your types for every function and then go back and change them every time you figure out there is a better way to represent the data."
You don't have to do this in languages like Haskell either. Type inference will help you most of the time when figuring out a function's type, and you don't have to use the type system as it was intended at first. You can have a prototype with Strings and Lists, the compiler won't be able to help you much though.
While Haskel has quite a few tools to help assuage issues like this, I can't help but think that niche tools do not define the genre. When I hear "statically typed", I don't think of Haskel, I think of C, C++, Go, Java, and Rust.
All of these languages offer tools to handle similar duck typing via interfaces or traits or polymorphism, but they are far from simple to use.
When Haskel gains a mindshare outside of its current niche, or the type inference becomes more broadly implemented in languages used across our industry, then let's talk about how it makes statically typed languages better and easier to use than "unityped" languages.
This is one of those things that is perhaps true in theory, but often falls short in practice. Static type systems tend to require (more or less frequent) additional incantations, but may not be sufficiently-express, even with those incantations, to express the desired intent.
(Or, the required complexity of the incantations may be a greater cognitive workload than actually writing the functional code.)
You don't have to do this in languages like Haskell either.
Most static languages -- particularly, the ones with the strongest standard libraries and ecosystems that are likely to support whatever it is you are doing -- aren't like Haskell.
Comments
"It is much easier to quickly prototype or experiment in a dynamic language."
I disagree. I can say what I mean with types, and if I didn't mean what I said, refactoring is a breeze.
"You don't have to stop and figure out your types for every function and then go back and change them every time you figure out there is a better way to represent the data."
You don't have to do this in languages like Haskell either. Type inference will help you most of the time when figuring out a function's type, and you don't have to use the type system as it was intended at first. You can have a prototype with Strings and Lists, the compiler won't be able to help you much though.
While Haskel has quite a few tools to help assuage issues like this, I can't help but think that niche tools do not define the genre. When I hear "statically typed", I don't think of Haskel, I think of C, C++, Go, Java, and Rust.
All of these languages offer tools to handle similar duck typing via interfaces or traits or polymorphism, but they are far from simple to use.
When Haskel gains a mindshare outside of its current niche, or the type inference becomes more broadly implemented in languages used across our industry, then let's talk about how it makes statically typed languages better and easier to use than "unityped" languages.
This is one of those things that is perhaps true in theory, but often falls short in practice. Static type systems tend to require (more or less frequent) additional incantations, but may not be sufficiently-express, even with those incantations, to express the desired intent.
(Or, the required complexity of the incantations may be a greater cognitive workload than actually writing the functional code.)
Most static languages -- particularly, the ones with the strongest standard libraries and ecosystems that are likely to support whatever it is you are doing -- aren't like Haskell.