Confession of a Haskell Hacker

This post is a representative of everything that I both love and hate about Haskell:<p>1) It is certainly true, and I've had the experience many times, that "if it compiles, it's correct" applies frequently to Haskell. Even better, I've frequently written code for the first time, hit the compile button, and had it work first time - something that almost never happens to me with Java or C. 2) The huge, HUGE caveat to that is that it's only true for pure and sufficiently polymorphic code. If you're writing anything in the IO monad, or if you're using specific data types (e.g. Int, []) rather than writing polymorphic code, then all bets are off.<p>There's only one way (ignoring ⊥) to write the forward pipe operator (|&#62;) :: a -&#62; (a -&#62; b) -&#62; b in Haskell. If your code compiles, it's guaranteed to be correct.<p>There are many, many ways to write the isPrime :: Integer -&#62; Bool function, which differ widely in correctness, understandability and efficiency. Once you move from type variables to concrete types, you open yourself up to many more potential errors.<p>There are even more ways to write the function deleteFile :: FilePath -&#62; IO (), including but not limited to (i) deleting the file and doing nothing else, (ii) deleting the file and its containing folder, and (iii) wiping your entire filesystem. All of these would type check. Sure, you probably wouldn't make these mistakes, but the point is that <i>the type system won't help you here any more than it would in &#60;insert untyped language here&#62;</i>.<p>I think Haskell is an incredible language. It's certainly the language I have the most fun with, and I find its approach to parallelism, concurrency, I/O and state to be natural and appealing. But there's a real danger of overstating what Haskell is capable of, and turning off newcomers to the language in the process.

I find this happens a lot with Haskell. I can write hundreds of lines of code and have them work perfectly as soon as I get a error-free and warning-free compilation.<p>The type system is definitely a big part of this, but almost as important are algebraic data types and compiler checks for exhaustivity when scrutinising values of such types.

This is supported by the parametricity theorem. That is a big word, but it boils down to this: let's say you wrote an identity function of type "a -&#62; a", and it passed the type checker. Then it is correct: you simply can't do much with a value of type "a", because you don't know anything about it.<p>If an identity function is too simple, consider "compose :: (a -&#62; b) -&#62; (c -&#62; a) -&#62; (c -&#62; b)". I think it can be proven that if you write an implementation that passes the type checker for this signature, the implementation is necessarily correct.

From the article: "The types are so polymorphic that I conjecture that there is only one way to write functions matching the required types such that all parameters are used non-trivially and recursion is not used."<p>He is not arguing "it works if it compiles" in general. He is arguing "it works if it compiles", because types are so polymorphic. Polymorphic part is actually important. If you don't get that part, you are missing the point.

Ah, a Haskell circle-jerk waiting to happen and a confession that's really a way to act superior about Haskell's type system. Listen, it's a great language and I've spent a few years deep in it, but I find this post arrogant and not even accurate.<p>The libraries he is talking about are for data types, something that the type system (almost by definition) is perfectly adequate for testing. So yes, he's tested it by compiling it. But for any real world Haskell program the type system alone is not enough.

What are functional lenses?<p><a href="http://www.haskellforall.com/2012/01/haskell-for-mainstream-programmers_28.html" rel="nofollow">http://www.haskellforall.com/2012/01/haskell-for-mainstream-...</a> <a href="http://stackoverflow.com/questions/8307370/functional-lenses" rel="nofollow">http://stackoverflow.com/questions/8307370/functional-lenses</a>

I think the interesting point here is that Haskell provides such a high static assurance out of the box that what you write is correct that this can happen. You'd never hear of a ruby programmer releasing a gem without trying it.

I have some open source projects that I've released on multiple occasions without having tested them. I think people make the assumption that things that have adequate documentation and comments/support tickets, etc. that indicate use, that they are tested before release. That is simply untrue. You get what you get. That is true in the world of both paid and unpaid open-source and closed-source software and well as life in-general.<p>Something that helps in this regard is travis-ci. It's a free CI server and if you have at least some level of testing, you have some level of confidence.

Why did you write it if you have never run it? Was it just for people who read your article and might want to run the code?

That's not very surprising; Haskell's type system is really that ridiculously powerful. But I suspect many hackers working with other languages would be able to state the equivalent: "I released a library which I only unit-tested, without writing any helper project that actually uses it".

And that's something he's proud of?<p>If I never ran my code, it wouldn't have any bugs either, no matter what language I was using.<p>I guess it does help explain all the half-assed packages on Hackage.

Hindley-Milner is powerful, but there are usually multiple ways to construct a value of the correct type. Only one of those ways is the correct way, and I'd want to test my functional code to make sure that this was the way that I chose.

nothacker, you are "dead"/"ghosted". I am reposting his comment here:<p>nothacker 42 minutes ago | link [dead]<p>I have some open source projects that I've released on multiple occasions without having tested them. I think people make the assumption that things that have adequate documentation and comments/support tickets, etc. that indicate use, that they are tested before release. That is simply untrue. You get what you get. That is true in the world of both paid and unpaid open-source and closed-source software and well as life in-general.<p>Something that helps in this regard is travis-ci. It's a free CI server and if you have at least some level of testing, you have some level of confidence.

Minor aside, is "I conjecture" valid English?<p>I'm not criticising, just curious and in the pub.

As someone who is interesting in writing more Haskell, I've heard all the "if I get it to compile it works perfectly the first time", and I wonder if people are missing out on what proper TDD can bring them.<p>At first TDD becomes a way to assert your code does what you expect. After a few years you begin to use it as a design technique, and the correctness argument becomes less and less of a reason for using it. It's more of an (albeit nice) side effect at that point. I can write code that I test after the fact and still get the same correctness benefits, but the feedback I get from testing my design is gone.<p>Maybe I'm missing something, but I don't know if just having an excellent type checker is enough to provide the same quality feedback loop as well executed TDD does.

This is why Hackage is full of junk and Haskell is unapproachable for real-world projects. Everyone's throwaway toy file is published as a package, and the useful well-documented packages get lost in the mix.

As somebody who knows Haskell only superficially, this line of code and the author's statement makes me wonder if people can read their own or somebody else's code after some time.