[Koshkin]

Let's say, "there is high probability that my code will work correctly right away". (This is especially true for Haskell.)

[Edit] To be fair, this is not only, and even perhaps not so much, due to the static typing per se but also due to the mental discipline the particular programming language may require from the programmer even to write code that can be successfully compiled.

[xapata]

> there is high probability that my code will work correctly right away

I'll bet my Python code has a similar probability of working correctly on the first run, conditioned on the complexity of the task.

[zzalpha]

Actually, based on my experience, what I found most remarkable about writing code in Haskell (which I admit I haven't done much of) is that I'd spend an enormous out of time wrestling with the compiler, but once I finally got all the type errors to clear out, the odds were surprisingly high that the code would "just work", which is not an experience I had with even other compiled languages (Java, C#, etc).

'course, it probably wouldn't work fast, and it was 50/50 whether I'd introduced space leaks, but...

[tome]

> I'll bet my Python code has a similar probability of working correctly on the first run, conditioned on the complexity of the task.

Having developed professionally in both Python and Haskell, the probability for me was significantly higher in Haskell.

[Koshkin]

> conditioned on the complexity

Indeed, difference in complexity is the key here.

[xapata]

I'm confused. Are you agreeing with me?

[jdmichal]

It's a back-handed agreement. Static typing increases value with project complexity and head count. So yes, if you only ever do small tasks with low or singular head count, then dynamic typing probably works OK for you.

[xapata]

As complexity increases, the probability approaches zero that any code works exactly as desired on first execution. I'd still take that bet. Of course, I'd have to be able to use the REPL about as often as a someone uses a compiler.