On 18/04/07, R Hayes
One of the truly powerful things about Haskell is the short distance between theory and practicality. The problem is how to demonstrate this convincingly. The ability to prove a program's correctness is regularly trotted out for show in this arena (or at least the lighter-weight claim that programs that compile usually work). I don't think that most developers (and certainly not the OSCON crowd) are ready to drink that kool-aid. They *enjoy* debugging and are tired of the "static" vs. "dynamic" debate. But the ability to reason about programs has borne fruit that I *do* think they will appreciate. Because many of them care about performance.
I completely agree with you there. Someone earlier in the thread mentioned that QuickCheck almost in passing, but I think it should be emphasised: *QuickCheck is a really powerful way to work.* The real pain in the butt with unit tests is having to write the damn things. Especially for corner cases - if they were easy to reason about they wouldn't really be corner cases, would they? QC allows you to sidestep that neatly by generating a set of unit tests from a specification. And often generating cases you *wouldn't* have thought of yourself. Genius! It does rely on a functional mindset, however. No state-fiddling going on behind our backs. But maybe if you sell the idea first - create hundreds of unit tests on demand without lifting a finger - then people will make the leap of their own accord. Because let's face it, selling referential transparency is a pretty dead loss ;-) Salesmanship is about pointing out problems people have [1]. The problem R Hayes identifies here is that theory is great in theory, but in practise it's *too much work*. And short of creating a system where even your QC properties are auto-generated (I live in eternal hope...), this is a really important advances which people should learn more about. [1]: http://weblog.raganwald.com/2007/01/what-ive-learned-from-sales-part-i.html Cheers, Dougal.