Static Typing is not enough

Yes, static typing is not enough. Which is why a good statically typed language like Haskell also has great testing facilities. So you don't just write well typed code, but you also write unit tests (HUnit) and property-based tests (QuickCheck). The really neat bit is that static typing actually makes writing tests easier--QuickCheck is much easier to use in Haskell than it would be in some dynamically typed language.

Doesn't anyone view static typing as done in a language like Haskell as a form of documentation? I am not saying ALL Haskell code can be deciphered by its types - hell no. But a useful technique is to express the semantics of the program into the type system (as much as possible anyways) to communicate intent. This is a huge benefit over dynamic languages imho. So there is more too it than just verification, even if that is extremely nice.

This is as much a usability problem as it is a "getting it right" one. We could eventually "get it right" by plugging in raw machine code through switches or punchcards if that's really what it took, but what we're arguing over is the _price_ of getting it right.<p>Static types are implemented and available for use at the language level, which isn't true of all of those features in most environments.

Neither static typing (nor any of the other stuff mentioned) is enough to ensure correctness. Never has been, never will be.<p>However, static typing <i>is</i> enough for some sweet, sweet hit-dot-wtf-can-i-do-completion-refactoring-like-a-boss tooling goodness.

Kind of a strawman argument, as no developer would argue that <i>only</i> unit tests and static typing are needed to guarantee quality.

Yep, there is no silver bullet.<p>But that doesn't mean all bullets are created equal.

Yet another attempt to diminish the value of statically typed languages and the benefits that go along with them.

In a conference 15 years ago I heard a guy say The problem with software is we don't know what it is. He meant that: we know what is a car or a bridge, we know why and how they do their purpose, not so much with software, which is a strange beast our minds are not ready to grab yet.

You need formal machine-checked verification (Coq, Isabelle).<p>Unfortunately, this is not enough. You need a consistent and complete specification, too.

I'm really curious what Love Driven Development would look like. Is it kind of like TDD in that before you write a single line of code you write a sonnet about it?

Doesn't matter because, what really matters is Think-before-you-code, all that static typing will save noone from bugs.<p>Also: &#60;3 Love Driven Development &#60;3

Sometimes, I wish I could downvote stories...<p>Accidentially, almost everything that the author suggests, except luck and user testing, can be provided by static type systems - e.g. Haskell's type system is Turing-complete, so you can make up any kind of contracts/tests and embed them into the type system...

Big take away: Love Driven Development Rules Them All.

LDD ftw.