[hyperpallium]

Requirements Uncertainty: Fast iteration has many benefits - especially when you (or your client) don't actually know what's required ("agile"); and when what is required changes quickly, because of changes in competitors, customers, technology, regulation etc.

But you're right, as projects get larger, a priori design and static types quickly become essential. And at that point, requirements are usually known and frozen.

I predicted that the natural resolution would be languages with both (i.e. optional static types, especially at important interfaces) - but while this feature exists, it hasn't taken off.

Instead it seems that performance is the main attraction of static types in the mainstream (java, c#, objective-c, c, c++); and ML-family and Haskell are popular where provable correctness is wanted.

[tel]

To be honest, I think Haskell is the best language I know of for fast iteration as well. You can successfully create and manage far worse, yet working code when you've got a good type-driven guardrail. A common pithy quote, which I agree with wholeheartedly, is that "`IO` is the best imperative language out there today".

There's definitely a lot of missing documentation about this folk practice of "fast, loose, shitty Haskell" due to the strong culture of pretty code that's also enabled by Haskell. I remember seeing a video presented at CUFP that went into the merits here, though.

Essentially, this is a "tricky" concept because you want to design your types to be exactly as restrictive as you can afford without having to think too much. It probably requires a good grasp of the Haskell type system applied in full glory in order to bastardize it just right.

So, tl;dr?

I think types are the ultimate fast iteration tool, but this is not a well-documented practice.

[avmich]

"Civilization advances by extending the number of important operations which we can perform without thinking about them." A. N. Whitehead.

It's often said that a Lisp advantage is to be able to write sloppy - without fully understanding what's needed. I guess you can model that degree of "less constraints" in Haskell as well? Otherwise constant forcing "understand what you're doing" can sometimes be a burden.

[munro]

> ML-family and Haskell are popular where provable correctness is wanted.

Haskell doesn't have a theorem prover, you may want to check out Idris [1]. Haskell gives you more safety that you aren't going to get run time errors than say Java, but not completely. You'll still need automated testing for correctness, that you're not getting garbage in, garbage out.

[1] http://dafoster.net/articles/2015/02/27/proof-terms-in-idris...