I used to think this too, but realised that it is not quantitatively different to me whether I spend the time getting something to compile, or spend the time getting it to execute correctly.
I tend to prefer dynamic typing these days as a lot of what I do feels easier to achieve when I can throw something together to test ideas without thinking about types, and then refine the idea based on actually using a cobbled together prototype, and I feel static typing often got in the way of that.
Especially coupled with Smalltalk style runtime inspection / modification on error (e.g. for Ruby I use "pry" which lets me drop into a shell anywhere in the program and modify or inspect state and then continue execution).
I think it's a genuine weakness of static types that they inhibit prototyping when you first begin. HM type systems tend to be liberal and powerful enough that once you learn them well they're easier to prototype in—but that comes with time.
In particular, type-driven-development is wonderful. You can write light, compiler-checked specifications of code you haven't bothered to write yet and see if your logic all typechecks even without implementation. I can run through lots of ideas that way very quickly since the only thing I have to produce is the high-level type skeleton of my program.
Then I just go through and implement it all.
It's a lot like test driven development except that your executable tests are much more lightweight and carry a strong sense of the logic of your program. If your tests don't hang together, you'll find out eventually. If your types don't hang together, your compiler tells you immediately.
> I used to think this too, but realised that it is not quantitatively different to me whether I spend the time getting something to compile, or spend the time getting it to execute correctly.
When do you determine you've gotten it to execute correctly? Achievement Unlocked: You Can Stop Testing Now?
How is that any different from Haskell? You think that merely lining up types and having it compile determines that it also "executes correctly"? There are also algorithmic and other mistakes.
With haskell, the compiler verified tons of possible errors to guarantee against them. With smalltalk, you verified those tons of possible errors yourself. People make mistakes.
People make logic mistakes that'll fly straight past a type checking compiler too.
In my experience, most of the type related errors I make in Ruby "fall out" when testing functionality anyway, so that the amounts of tests that actually need to care explicitly about typing tends to be tiny.
You'd be amazed how few do. I'm frequently amazed. Furthermore, when you start getting into advanced types it's amazing how many errors become simply impossible since your types encode the logic your program is intended to represent.
For an example, here's a blog article linked elsewhere on this page which talks about encoding various "dimensions" of infinitesimals in an automatic differentiation program that thus eliminate a whole class of value errors.
In my experience the most problematic bugs are the bugs in peoples thinking about the problem. Those bugs are easy to translate into "working code", because they carry through all the way from the top.
Then I much rather want a program that is easily malleable, than one where the flawed logic is encoded in the types.
If the problem space is known in detail upfront, then sure. But then writing test cases to cover them is just as simple.
Not least because if you really want to, writing test cases and type checks to enforce typing is trivial to do in dynamic languages too. In fact there are quite a few examples on how to do advanced type checks on Ruby code. With the level of introspection Ruby does, you can e.g. easily "wrap" every method with detailed enforcement of type invariants.
You need to run some functional tests to exercise the code paths to trigger said type checks, but you need functional tests anyway.
People don't tend to use those methods because in practice they turn out to rarely capture many interesting errors once you write functional tests anyway.
>Those bugs are easy to translate into "working code", because they carry through all the way from the top.
Actually, they aren't. Try haskell or ocaml or clean or SML sometime. You have to have a clear and consistent model of what you are doing in order for your code to type check. I can't count the number of times I've had my incorrect thinking about a problem be forced out of me during the initial development by the compiler.
>Not least because if you really want to, writing test cases and type checks to enforce typing is trivial to do in dynamic languages too
No, it is actually a huge pain, you need to write a type checker. Writing a "is this an int?" test does not give you the assurance of type checking. That only finds out if the value happened to be an int under that particular execution of the application. A type checker completely guarantees that there is no way for it to be the wrong type ever. Even if the only thing static typing got you was the complete elimination of NULL/nil exceptions, it would be worth it. But it gets you way more than that.
>People make logic mistakes that'll fly straight past a type checking compiler too
Which is why I want to be able to focus my mental power on those mistakes, rather than all the other mistakes the compiler will handle for me. There's only so much brain power available, I don't like wasting it.
>In my experience, most of the type related errors I make in Ruby "fall out" when testing functionality anyway
My experience is quite the opposite. So much so that I believe the only way people can actually come to that conclusion is by not realizing how many errors are actually type errors, because they have never used a type system that is expressive enough to be helpful.
I tend to prefer dynamic typing these days as a lot of what I do feels easier to achieve when I can throw something together to test ideas without thinking about types, and then refine the idea based on actually using a cobbled together prototype, and I feel static typing often got in the way of that.
Especially coupled with Smalltalk style runtime inspection / modification on error (e.g. for Ruby I use "pry" which lets me drop into a shell anywhere in the program and modify or inspect state and then continue execution).