Why Not Haskell?

I've only written two notable haskell programs.<p>One (git-annex) is a large-ish, serious work, and I have been very pleased with how haskell has made it better, even though there was a learning curve (took me two weeks to write the first prototype, which I could have probably dashed off in perl in two days), and even though I have occasionally been blocked by the type system or something and had to do more work. One concrete thing I've noticed is that this is the only program where I have listed every single bug I fixed in the changelog -- because there have been so few, it's really a notable change to fix one!<p>My other haskell program was essentially a one-off peice of code, which converted ten years of usenet posts from the 80's into "modern" usenet posts. At that point I was over the learning curve, so I wrote it as fast, or possibly faster than I would have written the equivilant in perl, banging out a 800 lines of code in 12 hours or so. And the code is clean, pure, and even has reusable modules, which would never have happened with any other language I've used. And it all worked the first time. Converting the entire known corpus of A news articles to B news, and from there to C news, with success on the first try is an amazing feeling.<p>I'm going to be sticking with haskell. I do worry that some of my haskell code may need fiddling to keep working for 5 or 10 years though.

Once you manged to grok the basic stuff about Typeclasses, Functors, Applicative, Monads, Monad Transformers, different notions of recursion, a minimal understanding of how lazyness can be quite tricky, the multitude of different ways of how errors and exceptions are handled in various libraries, and perhaps basic STM, Haskell has a tendency to become even more complex. If you want to do efficient IO and prevent space leaks, you have to learn about Iteratees, Enumerators and Enumeratees. If you wish to create GUIs in a bearable manner, its imperative that you learn about FRP and Arrows eventually. Then there's the innumerable amount of language extensions to Haskell of the GHC flavor, each of which comes with only scarce documentation and examples, but with a lot of theory (Fundeps, Type families, Existential types, GADTs ...). But there's more: Comonads, Kleisli Arrows and probably things I haven't even heard about. The whole point being: If you want to be able to handle 'real world stuff' in Haskell, its not enough to stay 'mostly pure' and use StateT, unfortunately. I like Haskell - I shudder when I think of C, C++ and Java - but at this point in time I find it overwhelming.

There was recently a survey on the State of Haskell in 2011 [1]. As many people here seem to be echoing, OCaml was the main possible "replacement language". Also included in the survey are ratings of various aspects of Hackage and also Haskell libraries in general.<p>It was a really interesting read. I made a follow-up post [2] that analyzed the free-form responses to the last question, "What do you think is Haskell's most glaring weakness / blind spot / problem?".<p>Number one by far was libraries (spread across: quality + quantity, library documentation, Hackage, cabal). There are a lot of people working on this though, and progress is being made.<p>The runners up were 'Tools', and 'Barrier To Entry'.<p>I think Haskell, at the very least, is a fantastic way to learn some different ways of thinking and good habits. The (little so far) coding in it I've done has been very enjoyable for me, but I don't expect everyone to feel the same way.<p>It has a very warm community, and a fair bit of momentum. As time goes on I predict (and hope) it will become more viable for a greater number of people to use.<p>[1] - <a href="http://blog.johantibell.com/2011/08/results-from-state-of-haskell-2011.html" rel="nofollow">http://blog.johantibell.com/2011/08/results-from-state-of-ha...</a><p>[2] - <a href="http://nickknowlson.com/blog/2011/09/12/haskell-survey-categorized-weaknesses/" rel="nofollow">http://nickknowlson.com/blog/2011/09/12/haskell-survey-categ...</a>

I wished I lived in the authors world. A world where you don't have to maintain the code you wrote- or worse yet, someone else wrote. Where you could declare a program "done" and walk away and never have to revisit it. A world where "mostly works" is good enough- secure in the knowledge that you're not going to be rousted out bed at 2 in the morning on a weekend because some server in outer Mongolia hit that corner case you never thought to test. A world where all programs are small enough to fit into my head, completely, in all details. So I could simply know, if I change this, that will break.<p>That is not, unfortunately, the world I live in. If it is the world you live in, more power to you. Count your blessing and live happily. But the rest of us need all the help we can get.

Haskell is the first language I was ever fluent in. These days I mostly work in python and erlang with a smattering of ocaml but learning haskell had a huge influence on the way I think about software.<p>I find it hard to articulate the ideas that I came away with. Something like 'code should be built out of small, composable abstractions that obey simple algebraic laws'. It's incredible how powerful this is in combination with pure code (which enables easier composition and algebraic reasoning), typeclasses (which make it easy to express the interface to an abstraction) and quickcheck/smallcheck (which make it easy to express and test the laws which the abstraction should obey).<p>Others have written about this more clearly than I ever could. In particular, Conol Elliot's writing on denotational semantics [1] and Chris Okasaki's Purely Functional Datastructures [2].<p>The haskell community tends to be dominated by academic research so it's easy to dismiss the typical examples as impractical. Right now I'm trying to apply the same ideas to Kademlia routing in erl-telehash [3]. Hopefully I will eventually be able to demonstrate what I struggle to articulate.<p>[1] <a href="http://conal.net/papers/type-class-morphisms/" rel="nofollow">http://conal.net/papers/type-class-morphisms/</a><p>[2] <a href="http://books.google.com/books/about/Purely_functional_data_structures.html?id=SxPzSTcTalAC" rel="nofollow">http://books.google.com/books/about/Purely_functional_data_s...</a><p>[3] <a href="http://github.com/jamii/erl-telehash" rel="nofollow">http://github.com/jamii/erl-telehash</a>

My company (ThoughtLeadr) is using Haskell to analyze big data (social networks) to great effect. Although, I will admit finding great Haskell programmers in the wild is rather challenging.<p>Network effect with programming languages is a difficult nut to crack. That's the reason most new languages build on the syntax and features of existing "successful" languages.<p>The toolchain aspect has been less of an issue for us since we're using it for pure data analysis rather than shoehorning it into building webapps etc.

I wrote a post that was picked up by HN a while ago about why I left Haskell, so I won't rehash my arguments, but ...<p>On reflection, I love(d) Haskell, but the tradeoff that created the IO monad was too much for me. After 5 years using Haskell and a couple of years away from it, I've become convinced that the way Haskell isolates IO and state is not the correct solution. I'm not smart enough to know the correct solution, but creating monads, monad transformers and arrows and then providing sugar to get everything to look imperative again feels wrong. Uniqueness Types feel a bit healthier.<p>Now that I've said that, let me say that I'm most certainly impressed with the work around IO and state in Haskell because it was an amazing bit of intellectual horsepower and is an incredible step. But it doesn't feel like the final step/answer. Unfortunately, I had to get work done for clients and had to step away from Haskell, but I'm excited to see what the community brings forth. It's the most beautiful language on earth.

I've been doing a whole lot of scientific Python lately, and every time I let my program run for like an hour only to crash on an array of the wrong dimensions, or pass in a scalar where an array is expected or vice versa, I swear and wish I was using a strongly typed language like Haskell. If only it had the same tools as SciPy I'd be all over doing my scientific work in Haskell. (Not to mention it would have faster run times.)<p>(There are a few array libraries, but I'm pretty sure nothing as complete as NumPy+SciPy+matplotlib exists for Haskell..)

With the trend of SOA and webservers like Mongrel2, perhaps its a good time to start putting the more esoteric languages in production in the form of small services (w/ ZeroMQ for example).

I agree with the author, but for different reasons. I think Haskell suffers from a "network effects" problem. It's not made for real world use cases because nobody is using it for the real world. And guess what? To get it adopted in the real world, it needs to support real world use cases.<p>I think that Haskell is doomed to a life of being a research toy language for the simple reason that that's what people are using it for, not because functional programming is necessarily much harder (because I don't think it is).

If the question is, should we use Haskell to solve this problem, or should we use JavaScript, I can't imagine that the answer is often Haskell. (Maybe if the question is, should we use OCaml or should we use Haskell...)<p>That said, what really came out of left field was the OP saying that he and his friends are more and more using Go.<p>Is Go adoption happening? I'd love to have a systems programming language that isn't C or C++, but I'd always assumed that Go was dead-on-arrival specifically because it wasn't C or C++.

"If you've written a Haskell program that runs, it's highly likely to be a correct solution."<p>having done a bit of work with haskell myself, i'd say it's even better for this for haskell programmers. <i>if you're using type signatures and you've written a haskell program that passes type-checking, it's highly likely to be a correct solution</i>

First, the title annoys me: "Why not X?" is almost always the wrong question to ask, because it implies that X is so great that don't even need a reason to use it. If you want me on board, the relevant question is "Why X?".<p>Second, <i>A resulting correct Haskell program is likely more reliable, maintainable, and perhaps faster</i> seems fallacious to me. It might as well be that because Haskell is hard, only people with a deep understanding and appreciation of computer science ever venture into it. So, in other words, Haskell programs are good because they're written by very bright people thinking very hard about what they are doing. The same reason old mainframe code works well and average PHP doesn't.

I'm learning Haskell right now. It's the most recent language I've decided to pick up since R back in 2006. Despite dabbling in Lisp about a decade ago, and the functional flavoring of R, it's been a pretty difficult ride. However, it's definitely teaching me to think about writing programs in a very different way.<p>I can attest to the painfulness of the IO monad. I still haven't gotten it fully. The error messages are also fairly cryptic. The first program I wrote was about 15 lines and it took me about 4 hours of time. But it worked flawlessly and efficiently. The difficulties notwithstanding, this is probably the most fun I've had learning a language ever.

For those interested in learning Haskell, I can recommend the lesser known "Haskell Road to Logic, Maths, and Programming":<p><a href="http://www.amazon.com/Haskell-Logic-Maths-Programming-Computing/dp/0954300696" rel="nofollow">http://www.amazon.com/Haskell-Logic-Maths-Programming-Comput...</a><p>It's great to go over old and new math concepts and do so while exploring Haskell.

I've been spending time learning Haskell lately, as part of an investigation into tools which are amenable to static analysis at work.<p>To learn about the situation, I've put together similar programs in Lisp, OCaml, and Haskell, as well as installed compilers for Haskell &#38; Ocaml on the PPC.<p>Well -<p>I've coded for over a decade, and I've never encountered such a difficult to use language and jargony community &#38; documentation (including AWK &#38; SED). The only reasons I have been able to do anything are Real World Haskell, Learn You A Haskell, and Stack Overflow.<p>I'm not going to say Haskell is useless, or has no libraries, etc. Those aren't true. It's also not a bad language because it's weirder than my Blub (Common Lisp). It's a really sweet language, and I think in the hands of an expert, Haskell can <i>dance</i>.<p>But, I'm going to say Haskell is nearly impossible for an experienced procedural programmer to pick up and go with on the fly. There are a few reasons for my opinion:<p>* Special operators out the wazzoo. &#62;&#62;= ` ++ :: etc. The wrong 'dialect' of Haskell leads you to believe it's Perl and APL's love child. It's just not clear what something does until you find a reference book. Google doesn't help here - I don't even know the verbal names for some of them. :)<p>* Monads &#38; in particular, the IO Monad. The number of tutorials and explanations (and the number of new ones) suggest that this is not the most obvious concept in the land. It seems to be very simple if you know what you're doing (and what operators to use), though.<p>* The REPL is not identical to the compiler. This means that you can't <i>trust</i> the REPL. Coming from Python and Lisp, that is a pain.<p>* Type messages that are quite unclear, and probably require referring to the Haskell98 report to fully understand.<p><i>Regardless</i>, the above are surmountable problems and reasonable when moving to a new paradigm (very frustrating, though).<p>However, there are two key issues that are close to deal-breakers, with a third more minor one.<p>* Time to put a small program together. Easily 3x-10x my time working on Ocaml, a language which I am less experienced in (in both languages, I am amazingly inexperienced).<p>* Building the compiler on PPC (business reasons why I would need to do this). Ocaml builds with the traditional ./configure &#38;&#38; make. Very straightforward. GHC requires a cross compile with some funky source tweaks, or <i>possibly</i> a binary package (but the bin package dependency tree required replacing libc++, at which point I stopped). This is a dealbreaker unless I can straightforwardly guarantee my boss a good ROI with Haskell vs. (OCaml or other statically typed language).<p>* Human costs for my code. It's not professional to have a codebase only I can use in a team. Yes, the team could learn Haskell, but would it be a good ROI? If OCaml gets us there faster...<p>So Haskell is probably not going to work for me at work. :-( We'll see though.

I agree with the author, but still it reminds me of "Beating the average" &#62; This is the same argument you tend to hear for learning Latin.

Agreed that Haskell might not be to perfect fit for most of the enterprise projects out there, BUT nevertheless it is worth learning and mastering. The perceived difficulty comes from decades of teaching of imperative programming. I'm myself the product of C/C++/Java and it's amazing how I've manage to deal with so many peculiarities of theses languages. After having learned Haskell, I realize that it's much more coherent than the vast majority of other programming languages (including the functional languages). I'm learning Scala today and frankly, Haskell is much simpler. It is just amazing what you can achieve with good abstractions (parallelism, performance, modularity).<p>You might be tempted to use it yet but I'd suggest you keep on eye on this language. The potential is great and Haskell is evolving quite fast.

Haskell demonstrates the difference between theory and practice.<p>What does it matter if an arbitrary language X is beautiful in theory if nobody uses it in practice because they don't comprehend it?<p>Consider all those theoretically beautiful languages: APL, Ada, Lisp, Haskell, OCaml, ... How many developers use them? I think less than 1 percent in summary. Why?<p>Because syntax really matters. For this reason imperative languages like C++, Java, Python, Perl, Javascript, even PHP are so successfull.<p>As a long experienced programmer I discovered that (at least for me) the best technique is not to be fixed on one language but to use metaprogramming. That means, use your current favorite language (or create your own DSL) and compile it to the platforms/languages of choice.<p>My current recommendation: shenlanguage.org

In the end the author seems to be using Go for a lot more development. Are people here finding it to be a good solution? It seems like it might be the language that could bridge the iOS and Android systems for app development.

I like the shout out to go at the end. If you haven't tried that language yet I highly recommend it.

My problem seems to be that despite desperately wanting to use Haskell for some decent sized project, it never seems to work out as my best option. Right now I'm interested in writing a metro styled app for win8, and even for the server side portions I feel like I'm better off just using CouchDB instead of any Haskell solution that I've seen so far. Before that it was yet-another-web-based-UI-library so my choices were pretty much coffeescript or javascript. Perhaps it's because I like to have fun with UI, but so far anything I'd like to actually spend time on -- Haskell just doesn't seem like the right tool for. My best use of it so far was solving project euler problems, and considering how much I liked it, it feels like a shame that I have nothing better to use it on.

I've been using Haskell on and off for a few years and have written a few (small) projects in it. Every time I end up turned off of it, though.<p>First, I don't like how it makes side effects such a PITA. Fact of the matter is, computing is only useful for the side effects. A computation is useless if the result isn't printed to the screen, saved to a file, sent over the network, or used in some other way. So why make side effects so difficult?<p>Second, the community, or at least a vocal minority, come off as very condescending. If I have to ask a question on IRC I probably already feel dumb, I don't need somebody treating me like a child because I don't understand something.

Haskell is a hard language because (a) laziness is not intuitive, especially when space-performance matters (sadly, it does) and (b) pure functional programming is just not practical for most people. Like the OP said, it's awesome for brain-stretching, but not the easiest language to use.<p>I started writing a game in Haskell and found that the scaffolding necessary to do randomness in the "right" way was just too painful. It could be that I hadn't learned the idioms well-enough to see a better way of doing things; but if I had trouble, I think it's fair to say that most people would. Don't get me wrong: I'm a huge fan of functional programming. I just think <i>pure</i> functional programming is impractical. Mutable state is like radioactivity: it's necessary, powerful, and sometimes very useful, but must be handled with extreme care, not promiscuously thrown about.<p>My favored computation model is one in which the waterline between lambda and pi calculus is clear: message-passing between agents who should ideally be referentially transparent, unless referential non-transparency is part of their design. The upshot of this is that if an agent needs to be optimized using mutable state, none of the others care. That is, it's what OOP <i>should have</i> been.

Why haskell is a more appropriate question.

The intro read like it would be a much longer article.<p>tl;dr - Haskell isn't easy enough to use / is lacking good toolchains for author's use cases