10 ms·

Why Not Haskell?

200 points by yaaang 15y ago

jmuk 15y ago
I agree with the author, but still it reminds me of "Beating the average" > This is the same argument you tend to hear for learning Latin.
michaelochurch 15y ago
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. 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 pure 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. 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 should have been.
- lurker17 15y ago
  Hmm, as long as you do randomness in the IO monad, it's not any harder to do random numbers than it is to print to the screen. http://hackage.haskell.org/packages/archive/random/1.0.0.2/doc/html/System-Random.html http://hackage.haskell.org/packages/archive/random/1.0.0.2/d... getStdRandom :: (StdGen -> (a, StdGen)) -> IO aSource Uses the supplied function to get a value from the current global random generator, and updates the global generator with the new generator returned by the function. For example, rollDice gets a random integer between 1 and 6: rollDice :: IO Int rollDice = getStdRandom (randomR (1,6)) Of course, printing to the screen can be a pain in the neck. The cultural aversion to IO is Haskell's largest psychological problem. Newbies learn to avoid IO at all costs, and then never back off from the precipice and realize that sometimes IO is with the price you pay. But yeah, it's harder to do IO in Haskell than non-pure languages, and you have to bend your brain to a different model. In the worst case, though, you can just run your entire program in the IO monad, and then factor out your pure code bit by bit. None(?) of the Haskell tutorials will tell you do this, but it is the gentlest way to get real work done as a new-to-intermediate Haskeller.
  - michaelochurch 15y ago
    This is a fair point, but I'd generally prefer not to use the IO monad to generate random numbers because it feels "wrong", just like using IORef for mutable data when there are more "right" types feels wrong. Strictly speaking, pseudo-randomness isn't doing IO unless the source of randomness is considered something to which one is I/Oing.
    - seabee 15y ago
      Right, but pseudo-randomness is still monadic because you are mutating the state of the random number generator. That it is in IO is an implementation detail of where that generator's state lives. It's been a little while since I worked with Haskell but I'll surprised if nobody ported e.g. Mersenne Twister to it, complete with its own Random monad. If not, maybe that could be a new project...
    - jerf 15y ago
      You have to get the randomness out of IO, because referential transparency and randomness of any kind (psuedo or otherwise) are fundamentally in opposition, but once you have the random source in hand, you can use it any way you like in otherwise pure code. The Random support in Haskell is set up to permit and to some extent support this usage, with the ability to "split" a random generator into something you use now and something you pass along. After that it's your responsibility to properly split & use, but I haven't yet found it to be a big problem in practice.
- waqf 15y ago
  > 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. This. My current opinion as to what would constitute a perfect language is: something built on top of Haskell which would, in some as-yet-unconceived-of way, make it easy to thread mutable state exactly where it needed to go in your code. Like monads were supposed to do, except readable. Frankly, the code contains all the information you need to do this already, so perhaps we just need a source-code übereditor that marks it up so that you can see the dataflow.
  - michaelochurch 15y ago
    Monads are not unreadable. When you finally get do-notation and realize that you can use the same idioms for (a) list comprehensions, (b) imperative-style programming, and (c) error-handling and option-chaining, there's a "Wow" moment. However, we can give up on selling monads to the masses. The name alone... The concept of the monad is beautiful and awesome, but it's too different to succeed with the masses.
    - deleted 15y ago
      [deleted]
    - SkyMarshal 15y ago
      >However, we can give up on selling monads to the masses. The name alone... A monad is just a monoid in the category of endofunctors, what's the problem? (for anyone not familiar with the in-joke: http://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-problem http://stackoverflow.com/questions/3870088/a-monad-is-just-a...)
  - Periodic 15y ago
    Can you explain a little more what you mean about the dataflow? When I was writing some game simulations I ended up creating a few different monads for different execution contexts. I would have my main world monad which contained configuration data, world state, information about all the actors, the random number seed. Then I would have other contexts like AI which is where the AI would figure out what to do, having handy stuff like all the current actor's data easily accessible, and which would return actions on the World. Then there would be the monad for Actions themselves, which would have a source and a maybe a target. In short, I found using a few monads to clearly segment how different things interacted with each other actually made the program fairly clear. The Monads were all just stacks of State, Reader, Writer, and Maybe monads. It seemed like a very natural way to write something where the primary goal is to iterate on a function of type "World -> World", i.e. "Game ()".
- jberryman 15y ago
  > laziness is not intuitive That's just, like, your opinion, man. In the context of a declarative programming language, laziness is so intuitive it hardly needs a name.
- abi 15y ago
  With regards to generating random numbers, the Foreign Function Interface is also really useful. Here's a one-line wrapper around random(3). foreign import ccall "stdlib.h random" c_rand :: CDouble -> CLong
  - monopede 15y ago
    That will most likely bite you since you're giving a pure type to a non-referentially transparent function. There is a reason why random functions are in a state monad or IO.
    - JoshTriplett 15y ago
      In particular, while you don't really care what order the compiler makes the underlying calls to the C function, you do care that it actually makes all the calls rather than CSEing them away. As a pure function, the compiler has every right to optimize away multiple calls to your FFI-bound random function, in favor of a single call and multiple references to the value.
- yason 15y ago
  By the way, what concrete benefits do you think lazy evaluation offers in contrast to lazy data structures? I've noticed that with Clojure I can enjoy most laziness just the way I want to enjoy it by using lazy sequences and data structures. There's no lazy evaluation but I haven't really bumped into any problems with eager evaluation in Clojure. But Haskell goes deeper and has lazy evaluation as well. What additional, further good does it bring? (Besides nearly impossible debug prints...)
dlss 15y ago
The intro read like it would be a much longer article. tl;dr - Haskell isn't easy enough to use / is lacking good toolchains for author's use cases
nxn 15y ago
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.
- qx24b 15y ago
  That seems to be exactly what haskell is suited for solving, math problems. Which is great and wonderful when you are doing math related problems or things that are heavy in math but when you try and go outside those bounds that is when haskell becomes much much harder to write and work with. But alas that is both what makes haskell nice and hard to work with.
swah 15y ago
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).
- boothead 15y ago
  Agreed, zmq and some form of cross language serialization library (we're using protocol buffers) is a seriously powerful tool to have in your box. There are some patterns that seem perfectly suited to a small piece of haskell at the end of a zmq socket.
  - gaius 15y ago
    I am using AQ to help get OCaml into "real" use: http://gaiustech.wordpress.com/2011/05/26/ociml-new-feature-aq/ http://gaiustech.wordpress.com/2011/05/26/ociml-new-feature-...
Adaptive 15y ago
For those interested in learning Haskell, I can recommend the lesser known "Haskell Road to Logic, Maths, and Programming": http://www.amazon.com/Haskell-Logic-Maths-Programming-Computing/dp/0954300696 http://www.amazon.com/Haskell-Logic-Maths-Programming-Comput... It's great to go over old and new math concepts and do so while exploring Haskell.
- darklajid 15y ago
  I don't know. For me this sounds like a very bad idea. What is putting me off (tried building small things in Haskell a couple of times) is the already heavily buzzword compliant community, throwing not only a new language with new concept at me, but adding words that at first seem to be made up on the spot. Additionally, as others have said here, I'm having most troubles interacting with the world (IO!). Pure functions (Math!) are ~easy~ to represent. You suggest starting with that language and learning 'new math concepts' on the go? (I'm sure this works for some people and hats off to you guys, but for me this increases the mental complexity immensely)
  - Adaptive 15y ago
    I think you raise a good point and I wouldn't want to put others off if this isn't commensurate with their learning style. I suspect the overlap between math geeks and haskell learners is pretty big, but one should, as you are, evaluate one's own preferred learning style against this approach. I find human languages are the same for me. I have always liked to approach them from a bottom up linguistic direction, but this means largely self-structured study.
- twfarland 15y ago
  I'm going through this now. I've no math/logic background but wish to learn, so is perfect for where I'm at. Interactivity is a great learning tool. The book's focus isn't on real world software engineering though, so anyone expecting that should look elsewhere.
- gtirloni 15y ago
  I've read numerous Haskell docs online and they are pretty good. However I felt the need for a more in-depth book and I chose "Haskell: The Craft of Functional Programming" (3rd edition) and I'm LOVING it. It's excellent and I recomment it for anyone starting on Haskell. ps.: I'm not a professional coder and my experience has been on using Python/Shell Script for sysadmin stuff only. However, I constantly read C code to figure out issues and how the book tries to make a parallel between FP and Imperative is quite nice for me.
jxcole 15y ago
I like the shout out to go at the end. If you haven't tried that language yet I highly recommend it.
- gaius 15y ago
  He kinda has to, being a Googler.
  - uriel 15y ago
    Nope. There is nothing that forces Googlers to either use or promote Go.
    - gaius 15y ago
      Well they ain't gonna use or promote C# are they?
      - ConstantineXVI 15y ago
        If it's the best tool for the job, why not? They keep using and promoting Java despite Oracle suing their pants off over it.
      - uriel 15y ago
        Google is a very big and diverse organization, I'm sure there are some that do promote pretty much every language you ever heard of (and many you didn't). Actually, I remember some years ago reading about some Googlers that used C#, no clue what for, and it was a while ago, but it is not unrealistic.
        nathanwdavis 15y ago
        John Skeet?
socratic 15y ago
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...) That said, what really came out of left field was the OP saying that he and his friends are more and more using Go. 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++.
- jlao 15y ago
  This presentation has a few examples of real world uses: http://golang.org/doc/talks/io2011/Real_World_Go.pdf http://golang.org/doc/talks/io2011/Real_World_Go.pdf Heroku and Atlassian being the notable names. Also interesting to note, the 15-440 Distributed Systems class at CMU is being taught in Go this semester...
- js2 15y ago
  OP works for Google.
- uriel 15y ago
  > Is Go adoption happening? Slowly (not surprisingly giving the youth of the language), but it is happening, see: http://go-lang.cat-v.org/organizations-using-go http://go-lang.cat-v.org/organizations-using-go
- Sniffnoy 15y ago
  What I want to know is, is Go still undergoing major revisions? I don't seem to have been able to find an answer to this, and it's annoying. I remember there being some fairly big changes some time ago -- not so recently now, but after it was already public -- and I want to know whether that's going to still be happening before I bother learning it.
  - edsrzf 15y ago
    Go version 1, the first stable version of the language and implementation, is due out early next year. That sounds like a good time to start learning.
kamechan 15y ago
"If you've written a Haskell program that runs, it's highly likely to be a correct solution." having done a bit of work with haskell myself, i'd say it's even better for this for haskell programmers. 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
- pjscott 15y ago
  But just in case it isn't, remember that QuickCheck is a remarkably easy and powerful way to test weird edge cases: http://book.realworldhaskell.org/read/testing-and-quality-assurance.html http://book.realworldhaskell.org/read/testing-and-quality-as...
j_baker 15y ago
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. 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).
- m0th87 15y ago
  Haskell has some notoriety in the financial industry. Obviously the language isn't used as extensively as, say C++ in commercial applications, but to go to such extremes as saying "nobody" uses it is plain wrong.
  - deleted 15y ago
    [deleted]
  - Agathos 15y ago
    A couple of years ago, the only ads I would ever see on gmail in my haskell-cafe folder were for Jane Street Capital. But they don't use Haskell. The ad basically asked if they could talk me down to OCaml. It came up for discussion on the list, and as I recall they preferred OCaml so they could write speedy code without getting hung up on lazy evaluation and its sometimes-difficult-to-predict execution time. I still haven't looked at OCaml, although I had some exposure to SML in college. I'm looking at Scala these days (The type inference isn't even Hindley-Milner! Scandal!).
- Miky 15y ago
  Have you seen all the libraries up on Hackage? Haskell probably has way more real-world stuff than you think.
  - j_baker 15y ago
    Indeed I have. And most of those libraries are unfinished, poorly documented, or both. In short, it's great that people are putting the effort in. But Haskell has a long way to go still before it can compete with languages like python or ruby. Don't get me wrong. I love Haskell, and am willing to put up with things I wouldn't put up with in other languages. But it makes it difficult for me to sell the language to others who will also have to work with it.
bhurt 15y ago
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. 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.
- devs1010 15y ago
  agreed, maybe I haven't expanded my mind enough but once I started using a widely used language to program in (not saying which) where I can write relatively easily, scalable maintainable code, find plenty of work and pay the bills, my desire to experiment with other, more obscure languages has kind of fallen off, there has to be a reason why some languages are widely used and others aren't. No language is ever going to please everyone but thats how life is, you can't always change the world to suit your preferences
pnathan 15y ago
I've been spending time learning Haskell lately, as part of an investigation into tools which are amenable to static analysis at work. To learn about the situation, I've put together similar programs in Lisp, OCaml, and Haskell, as well as installed compilers for Haskell & Ocaml on the PPC. Well - I've coded for over a decade, and I've never encountered such a difficult to use language and jargony community & documentation (including AWK & SED). The only reasons I have been able to do anything are Real World Haskell, Learn You A Haskell, and Stack Overflow. 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 dance. 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: * Special operators out the wazzoo. >>= ` ++ :: 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. :) * Monads & 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. * The REPL is not identical to the compiler. This means that you can't trust the REPL. Coming from Python and Lisp, that is a pain. * Type messages that are quite unclear, and probably require referring to the Haskell98 report to fully understand. Regardless, the above are surmountable problems and reasonable when moving to a new paradigm (very frustrating, though). However, there are two key issues that are close to deal-breakers, with a third more minor one. * 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). * Building the compiler on PPC (business reasons why I would need to do this). Ocaml builds with the traditional ./configure && make. Very straightforward. GHC requires a cross compile with some funky source tweaks, or possibly 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). * 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... So Haskell is probably not going to work for me at work. :-( We'll see though.
Shakakai 15y ago
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. 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. 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.
melling 15y ago
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.
- uriel 15y ago
  For me Go has made programming enjoyable again.
- bonch 15y ago
  The author is using Go because they work at Google.
- SkyMarshal 15y ago
  >could bridge the iOS and Android systems for app development. How would it do that? Can it compile to Dalvik and iOS or something? Not very familiar with Go yet...
  - melling 15y ago
    Compile to native code. Android has the NDK; they support C/C++.
joeyh 15y ago
I've only written two notable haskell programs. 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! 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. 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.
- Adaptive 15y ago
  I was very excited when I first discovered git-annex. When I saw it was written in haskell that sealed the deal for me. The haskell code I run is all very robust and I was very happy you'd selected it for g-a. Have you posted anything else about how specifically Haskell has made it better? I'd enjoy reading more about that.
  - joeyh 15y ago
    I've been meaning to blog about that sometime soon. (Edit: I did write this post earlier http://kitenet.net/~joey/blog/entry/happy_haskell_hacker/ http://kitenet.net/~joey/blog/entry/happy_haskell_hacker/) Also been meaning to do a screencast showing what I think of as type driven refactoring, since while I've heard haskell programmers discuss it I've not seen it actually demonstrated
    - 15y ago
radarsat1 15y ago
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.) (There are a few array libraries, but I'm pretty sure nothing as complete as NumPy+SciPy+matplotlib exists for Haskell..)
- aaronblohowiak 15y ago
  save more intermediate values to disk so resuming upon failure is easier.
  - TheEzEzz 15y ago
    It's painful even when it only takes a single time step to reach the error (sometimes upwards of a minute or more). It's as if I've gone from an interpreted language with no compile time to a compiled language with horrendous compile times.
- nightski 15y ago
  I agree, and this is something I am investigating also. Data Parallel Haskell is an awesome base for something like this, but it is hard to tell if anyone is actually still working on it - and even harder to tell how one would contribute. Especially since there are so many spin off projects like Repa which have some of the functionality but just don't quite make the cut (lack primitives, hard to implement new parallel operations, etc...). The potential is there, it just needs to be exploited.
- eeperson 15y ago
  It's not Haskell but its closer than Python. Have you seen Scalala for Scala: https://github.com/scalala/Scalala https://github.com/scalala/Scalala
- kisielk 15y ago
  Sounds to me like you're doing it wrong. I write scientific Python code every single day for work and I (nor anyone else who works with me) never run in to those kinds of problems. Why are you running simulations that take an hour before you even know your code work? Where are your unit and integration tests? Every piece of our software stack has (or should have...) tests that verify all the bits fit together correctly in a matter of seconds or perhaps minutes tops. Strong typing would be nice to have sometimes, but in practice I think it limits the amount of ad-hoc data analysis and exploration you can do while trying to piece together a piece of software. I think the scientists in our company would murder the software engineering team if they had to deal with strong typing to get things done.
kd1220 15y ago
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. 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.
- tikhonj 15y ago
  I've found that the error messages quickly start making more sense (most of the time anyway...); in fact, now I parse the Haskell type error messages faster and more accurately than similar messages in Java or the like. I'm sufficiently spoiled now that error messages in languages like Python just throw me off completely...
nickknw 15y ago
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. 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?". 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. The runners up were 'Tools', and 'Barrier To Entry'. 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. 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. [1] - http://blog.johantibell.com/2011/08/results-from-state-of-haskell-2011.html http://blog.johantibell.com/2011/08/results-from-state-of-ha... [2] - http://nickknowlson.com/blog/2011/09/12/haskell-survey-categorized-weaknesses/ http://nickknowlson.com/blog/2011/09/12/haskell-survey-categ...
whackberry 15y ago
Why haskell is a more appropriate question.
gawi 15y ago
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). 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.
- SkyMarshal 15y ago
  Yes, I actually started learning Haskell recently b/c I thought it would help me better grok Scala, which seems to borrow mostly from the ML family. Scala is definitely a better Java imho, and you get to keep the JVM and all its libraries, and the Lift web framework is superb, and you can even build Android apps with Scala. But ironically I've found myself falling in love with Haskell and not wanting to use anything else. For the first time ever I know what a real type system is and what it's for, and Haskell basically pulls a Steve Jobs in completely rethinking how to do parallelism (strictly control global state and side effects by eliminating them by default, enabled only via monad). Mind expanding indeed.
PPGualtieri 15y ago
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.
- joevandyk 15y ago
  Are most of those names for simple concepts / design patterns / types? I'm finding more and more that the hardest part of haskell is understanding the syntax and the terminology.
  - Uchikoma 15y ago
    A lot of stuff is quite easy, after reading http://learnyouahaskell.com/ http://learnyouahaskell.com/ - but there is a tendency in the Haskell community, perhaps not in the core but at the fringes to look more elite, and with a lot of hand waving to make simple things (Monads come to mind) something complex sounding. Take the IO Monad. Everyone who wrote some web/servlet code, that needs to output stuff to the web over several classes (might not be the best design in the beginning) uses a Writer (or other class) to aggregate output. He therefore, as global vars are bad (and thread local are worse ;-) adds a Writer to every method. public T doSomeStuff(T input, Writer io) This is nasty and ugly, and the IO monad is in essence just another way to write this in a neat form, make it composable and control the IO environment. public IO<T> doSomeStuff(IO<T> input) But you would not get this insight from any of the monad tutorials written by Haskell people (except the link above). Simple monad insight comes form other people outside the Haskell community, e.g. James Iry http://james-iry.blogspot.com/2007/09/monads-are-elephants-part-1.html http://james-iry.blogspot.com/2007/09/monads-are-elephants-p...
CoffeeDregs 15y ago
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 ... 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. 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.
jlarocco 15y ago
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. 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? 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.
- SkyMarshal 15y ago
  I don't know if this was the intent or a side effect, but one reason for strictly controlling side effects is that it improves parallelization of the code. Global state, mutable vars, other side effects are some of the biggest obstacles to code parallelization, and that's one of Haskell's solutions to it. Haskell and Erlang seem to be the only two languages that seem designed from the ground up for massive concurrency and parallelism.
- gtirloni 15y ago
  One of the reasons I'd suggest Haskell to someone is exactly the community. I cannot see a question going unanswered on #haskell or at least 2-3 trying to help (doesn't matter if it's beginner-level or advanced). My experience has been the opposite.
jamii 15y ago
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. 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). 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]. 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. [1] http://conal.net/papers/type-class-morphisms/ http://conal.net/papers/type-class-morphisms/ [2] http://books.google.com/books/about/Purely_functional_data_structures.html?id=SxPzSTcTalAC http://books.google.com/books/about/Purely_functional_data_s... [3] http://github.com/jamii/erl-telehash http://github.com/jamii/erl-telehash
mseebach 15y ago
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?". Second, A resulting correct Haskell program is likely more reliable, maintainable, and perhaps faster 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.
- neilk 15y ago
  I am guessing that you have never worked with Haskell? Your hypothesis -- that difficult languages result in more bug-free code, due to selection bias -- is, to say the least, somewhat of a minority opinion. But even if we accept this, Haskell is different. The difficulties of Haskell are not arbitrary. Nor are they related to the difficulty of understanding the machine at a low level. In fact, Haskell insulates you from all that; it's easily the highest level language in common use. It's that Haskell insists on program correctness. You have to consider the entire range of values that any function could ever process. And due to its purity, Haskell applies a razor to your thought process, cutting out all unjustified or implicit assumptions. Luckily it also gives you tools of unparalleled flexibility when it comes to creating abstractions. Creating a new abstraction (like the composition of two functions) isn't just as easy as function application, that's how you do function application in Haskell. Typically with less syntactical fuss than it takes Java to initialize a variable.
  - mseebach 15y ago
    No, I have not worked with Haskell. I agree that a good type system eliminates an entire class of bugs (being strongly typed is what makes Java bearable), but I rarely see bugs in well-written software caused by not having considered the full range of inputs to your function.
    - 15y ago
bitcracker 15y ago
Haskell demonstrates the difference between theory and practice. 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? 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? Because syntax really matters. For this reason imperative languages like C++, Java, Python, Perl, Javascript, even PHP are so successfull. 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. My current recommendation: shenlanguage.org

200 points by yaaang 15y ago

jmuk 15y ago

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

michaelochurch 15y ago

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. 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 pure 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. 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 should have been.

lurker17 15y ago
Hmm, as long as you do randomness in the IO monad, it's not any harder to do random numbers than it is to print to the screen. http://hackage.haskell.org/packages/archive/random/1.0.0.2/doc/html/System-Random.html http://hackage.haskell.org/packages/archive/random/1.0.0.2/d... getStdRandom :: (StdGen -> (a, StdGen)) -> IO aSource Uses the supplied function to get a value from the current global random generator, and updates the global generator with the new generator returned by the function. For example, rollDice gets a random integer between 1 and 6: rollDice :: IO Int rollDice = getStdRandom (randomR (1,6)) Of course, printing to the screen can be a pain in the neck. The cultural aversion to IO is Haskell's largest psychological problem. Newbies learn to avoid IO at all costs, and then never back off from the precipice and realize that sometimes IO is with the price you pay. But yeah, it's harder to do IO in Haskell than non-pure languages, and you have to bend your brain to a different model. In the worst case, though, you can just run your entire program in the IO monad, and then factor out your pure code bit by bit. None(?) of the Haskell tutorials will tell you do this, but it is the gentlest way to get real work done as a new-to-intermediate Haskeller.
- michaelochurch 15y ago
  This is a fair point, but I'd generally prefer not to use the IO monad to generate random numbers because it feels "wrong", just like using IORef for mutable data when there are more "right" types feels wrong. Strictly speaking, pseudo-randomness isn't doing IO unless the source of randomness is considered something to which one is I/Oing.
  - seabee 15y ago
    Right, but pseudo-randomness is still monadic because you are mutating the state of the random number generator. That it is in IO is an implementation detail of where that generator's state lives. It's been a little while since I worked with Haskell but I'll surprised if nobody ported e.g. Mersenne Twister to it, complete with its own Random monad. If not, maybe that could be a new project...
  - jerf 15y ago
    You have to get the randomness out of IO, because referential transparency and randomness of any kind (psuedo or otherwise) are fundamentally in opposition, but once you have the random source in hand, you can use it any way you like in otherwise pure code. The Random support in Haskell is set up to permit and to some extent support this usage, with the ability to "split" a random generator into something you use now and something you pass along. After that it's your responsibility to properly split & use, but I haven't yet found it to be a big problem in practice.
waqf 15y ago
> 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. This. My current opinion as to what would constitute a perfect language is: something built on top of Haskell which would, in some as-yet-unconceived-of way, make it easy to thread mutable state exactly where it needed to go in your code. Like monads were supposed to do, except readable. Frankly, the code contains all the information you need to do this already, so perhaps we just need a source-code übereditor that marks it up so that you can see the dataflow.
- michaelochurch 15y ago
  Monads are not unreadable. When you finally get do-notation and realize that you can use the same idioms for (a) list comprehensions, (b) imperative-style programming, and (c) error-handling and option-chaining, there's a "Wow" moment. However, we can give up on selling monads to the masses. The name alone... The concept of the monad is beautiful and awesome, but it's too different to succeed with the masses.
  - deleted 15y ago
    [deleted]
  - SkyMarshal 15y ago
    >However, we can give up on selling monads to the masses. The name alone... A monad is just a monoid in the category of endofunctors, what's the problem? (for anyone not familiar with the in-joke: http://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-problem http://stackoverflow.com/questions/3870088/a-monad-is-just-a...)
- Periodic 15y ago
  Can you explain a little more what you mean about the dataflow? When I was writing some game simulations I ended up creating a few different monads for different execution contexts. I would have my main world monad which contained configuration data, world state, information about all the actors, the random number seed. Then I would have other contexts like AI which is where the AI would figure out what to do, having handy stuff like all the current actor's data easily accessible, and which would return actions on the World. Then there would be the monad for Actions themselves, which would have a source and a maybe a target. In short, I found using a few monads to clearly segment how different things interacted with each other actually made the program fairly clear. The Monads were all just stacks of State, Reader, Writer, and Maybe monads. It seemed like a very natural way to write something where the primary goal is to iterate on a function of type "World -> World", i.e. "Game ()".
jberryman 15y ago
> laziness is not intuitive That's just, like, your opinion, man. In the context of a declarative programming language, laziness is so intuitive it hardly needs a name.
abi 15y ago
With regards to generating random numbers, the Foreign Function Interface is also really useful. Here's a one-line wrapper around random(3). foreign import ccall "stdlib.h random" c_rand :: CDouble -> CLong
- monopede 15y ago
  That will most likely bite you since you're giving a pure type to a non-referentially transparent function. There is a reason why random functions are in a state monad or IO.
  - JoshTriplett 15y ago
    In particular, while you don't really care what order the compiler makes the underlying calls to the C function, you do care that it actually makes all the calls rather than CSEing them away. As a pure function, the compiler has every right to optimize away multiple calls to your FFI-bound random function, in favor of a single call and multiple references to the value.
yason 15y ago
By the way, what concrete benefits do you think lazy evaluation offers in contrast to lazy data structures? I've noticed that with Clojure I can enjoy most laziness just the way I want to enjoy it by using lazy sequences and data structures. There's no lazy evaluation but I haven't really bumped into any problems with eager evaluation in Clojure. But Haskell goes deeper and has lazy evaluation as well. What additional, further good does it bring? (Besides nearly impossible debug prints...)

dlss 15y ago

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

nxn 15y ago

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.

qx24b 15y ago
That seems to be exactly what haskell is suited for solving, math problems. Which is great and wonderful when you are doing math related problems or things that are heavy in math but when you try and go outside those bounds that is when haskell becomes much much harder to write and work with. But alas that is both what makes haskell nice and hard to work with.

swah 15y ago

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).

boothead 15y ago
Agreed, zmq and some form of cross language serialization library (we're using protocol buffers) is a seriously powerful tool to have in your box. There are some patterns that seem perfectly suited to a small piece of haskell at the end of a zmq socket.
- gaius 15y ago
  I am using AQ to help get OCaml into "real" use: http://gaiustech.wordpress.com/2011/05/26/ociml-new-feature-aq/ http://gaiustech.wordpress.com/2011/05/26/ociml-new-feature-...

Adaptive 15y ago

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

darklajid 15y ago
I don't know. For me this sounds like a very bad idea. What is putting me off (tried building small things in Haskell a couple of times) is the already heavily buzzword compliant community, throwing not only a new language with new concept at me, but adding words that at first seem to be made up on the spot. Additionally, as others have said here, I'm having most troubles interacting with the world (IO!). Pure functions (Math!) are ~easy~ to represent. You suggest starting with that language and learning 'new math concepts' on the go? (I'm sure this works for some people and hats off to you guys, but for me this increases the mental complexity immensely)
- Adaptive 15y ago
  I think you raise a good point and I wouldn't want to put others off if this isn't commensurate with their learning style. I suspect the overlap between math geeks and haskell learners is pretty big, but one should, as you are, evaluate one's own preferred learning style against this approach. I find human languages are the same for me. I have always liked to approach them from a bottom up linguistic direction, but this means largely self-structured study.
twfarland 15y ago
I'm going through this now. I've no math/logic background but wish to learn, so is perfect for where I'm at. Interactivity is a great learning tool. The book's focus isn't on real world software engineering though, so anyone expecting that should look elsewhere.
gtirloni 15y ago
I've read numerous Haskell docs online and they are pretty good. However I felt the need for a more in-depth book and I chose "Haskell: The Craft of Functional Programming" (3rd edition) and I'm LOVING it. It's excellent and I recomment it for anyone starting on Haskell. ps.: I'm not a professional coder and my experience has been on using Python/Shell Script for sysadmin stuff only. However, I constantly read C code to figure out issues and how the book tries to make a parallel between FP and Imperative is quite nice for me.

jxcole 15y ago

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

gaius 15y ago
He kinda has to, being a Googler.
- uriel 15y ago
  Nope. There is nothing that forces Googlers to either use or promote Go.
  - gaius 15y ago
    Well they ain't gonna use or promote C# are they?
    - ConstantineXVI 15y ago
      If it's the best tool for the job, why not? They keep using and promoting Java despite Oracle suing their pants off over it.
    - uriel 15y ago
      Google is a very big and diverse organization, I'm sure there are some that do promote pretty much every language you ever heard of (and many you didn't). Actually, I remember some years ago reading about some Googlers that used C#, no clue what for, and it was a while ago, but it is not unrealistic.
      - nathanwdavis 15y ago
        John Skeet?

socratic 15y ago

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...) That said, what really came out of left field was the OP saying that he and his friends are more and more using Go. 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++.

jlao 15y ago
This presentation has a few examples of real world uses: http://golang.org/doc/talks/io2011/Real_World_Go.pdf http://golang.org/doc/talks/io2011/Real_World_Go.pdf Heroku and Atlassian being the notable names. Also interesting to note, the 15-440 Distributed Systems class at CMU is being taught in Go this semester...
js2 15y ago
OP works for Google.
uriel 15y ago
> Is Go adoption happening? Slowly (not surprisingly giving the youth of the language), but it is happening, see: http://go-lang.cat-v.org/organizations-using-go http://go-lang.cat-v.org/organizations-using-go
Sniffnoy 15y ago
What I want to know is, is Go still undergoing major revisions? I don't seem to have been able to find an answer to this, and it's annoying. I remember there being some fairly big changes some time ago -- not so recently now, but after it was already public -- and I want to know whether that's going to still be happening before I bother learning it.
- edsrzf 15y ago
  Go version 1, the first stable version of the language and implementation, is due out early next year. That sounds like a good time to start learning.

kamechan 15y ago

"If you've written a Haskell program that runs, it's highly likely to be a correct solution." having done a bit of work with haskell myself, i'd say it's even better for this for haskell programmers. 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

pjscott 15y ago
But just in case it isn't, remember that QuickCheck is a remarkably easy and powerful way to test weird edge cases: http://book.realworldhaskell.org/read/testing-and-quality-assurance.html http://book.realworldhaskell.org/read/testing-and-quality-as...

j_baker 15y ago

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. 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).

m0th87 15y ago
Haskell has some notoriety in the financial industry. Obviously the language isn't used as extensively as, say C++ in commercial applications, but to go to such extremes as saying "nobody" uses it is plain wrong.
- deleted 15y ago
  [deleted]
- Agathos 15y ago
  A couple of years ago, the only ads I would ever see on gmail in my haskell-cafe folder were for Jane Street Capital. But they don't use Haskell. The ad basically asked if they could talk me down to OCaml. It came up for discussion on the list, and as I recall they preferred OCaml so they could write speedy code without getting hung up on lazy evaluation and its sometimes-difficult-to-predict execution time. I still haven't looked at OCaml, although I had some exposure to SML in college. I'm looking at Scala these days (The type inference isn't even Hindley-Milner! Scandal!).
Miky 15y ago
Have you seen all the libraries up on Hackage? Haskell probably has way more real-world stuff than you think.
- j_baker 15y ago
  Indeed I have. And most of those libraries are unfinished, poorly documented, or both. In short, it's great that people are putting the effort in. But Haskell has a long way to go still before it can compete with languages like python or ruby. Don't get me wrong. I love Haskell, and am willing to put up with things I wouldn't put up with in other languages. But it makes it difficult for me to sell the language to others who will also have to work with it.

bhurt 15y ago

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. 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.

devs1010 15y ago
agreed, maybe I haven't expanded my mind enough but once I started using a widely used language to program in (not saying which) where I can write relatively easily, scalable maintainable code, find plenty of work and pay the bills, my desire to experiment with other, more obscure languages has kind of fallen off, there has to be a reason why some languages are widely used and others aren't. No language is ever going to please everyone but thats how life is, you can't always change the world to suit your preferences

pnathan 15y ago

I've been spending time learning Haskell lately, as part of an investigation into tools which are amenable to static analysis at work. To learn about the situation, I've put together similar programs in Lisp, OCaml, and Haskell, as well as installed compilers for Haskell & Ocaml on the PPC. Well - I've coded for over a decade, and I've never encountered such a difficult to use language and jargony community & documentation (including AWK & SED). The only reasons I have been able to do anything are Real World Haskell, Learn You A Haskell, and Stack Overflow. 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 dance. 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: * Special operators out the wazzoo. >>= ` ++ :: 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. :) * Monads & 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. * The REPL is not identical to the compiler. This means that you can't trust the REPL. Coming from Python and Lisp, that is a pain. * Type messages that are quite unclear, and probably require referring to the Haskell98 report to fully understand. Regardless, the above are surmountable problems and reasonable when moving to a new paradigm (very frustrating, though). However, there are two key issues that are close to deal-breakers, with a third more minor one. * 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). * Building the compiler on PPC (business reasons why I would need to do this). Ocaml builds with the traditional ./configure && make. Very straightforward. GHC requires a cross compile with some funky source tweaks, or possibly 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). * 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... So Haskell is probably not going to work for me at work. :-( We'll see though.

Shakakai 15y ago

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. 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. 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.

melling 15y ago

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.

uriel 15y ago
For me Go has made programming enjoyable again.
bonch 15y ago
The author is using Go because they work at Google.
SkyMarshal 15y ago
>could bridge the iOS and Android systems for app development. How would it do that? Can it compile to Dalvik and iOS or something? Not very familiar with Go yet...
- melling 15y ago
  Compile to native code. Android has the NDK; they support C/C++.

joeyh 15y ago

I've only written two notable haskell programs. 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! 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. 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.

Adaptive 15y ago
I was very excited when I first discovered git-annex. When I saw it was written in haskell that sealed the deal for me. The haskell code I run is all very robust and I was very happy you'd selected it for g-a. Have you posted anything else about how specifically Haskell has made it better? I'd enjoy reading more about that.
- joeyh 15y ago
  I've been meaning to blog about that sometime soon. (Edit: I did write this post earlier http://kitenet.net/~joey/blog/entry/happy_haskell_hacker/ http://kitenet.net/~joey/blog/entry/happy_haskell_hacker/) Also been meaning to do a screencast showing what I think of as type driven refactoring, since while I've heard haskell programmers discuss it I've not seen it actually demonstrated
  - 15y ago

radarsat1 15y ago

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.) (There are a few array libraries, but I'm pretty sure nothing as complete as NumPy+SciPy+matplotlib exists for Haskell..)

aaronblohowiak 15y ago
save more intermediate values to disk so resuming upon failure is easier.
- TheEzEzz 15y ago
  It's painful even when it only takes a single time step to reach the error (sometimes upwards of a minute or more). It's as if I've gone from an interpreted language with no compile time to a compiled language with horrendous compile times.
nightski 15y ago
I agree, and this is something I am investigating also. Data Parallel Haskell is an awesome base for something like this, but it is hard to tell if anyone is actually still working on it - and even harder to tell how one would contribute. Especially since there are so many spin off projects like Repa which have some of the functionality but just don't quite make the cut (lack primitives, hard to implement new parallel operations, etc...). The potential is there, it just needs to be exploited.
eeperson 15y ago
It's not Haskell but its closer than Python. Have you seen Scalala for Scala: https://github.com/scalala/Scalala https://github.com/scalala/Scalala
kisielk 15y ago
Sounds to me like you're doing it wrong. I write scientific Python code every single day for work and I (nor anyone else who works with me) never run in to those kinds of problems. Why are you running simulations that take an hour before you even know your code work? Where are your unit and integration tests? Every piece of our software stack has (or should have...) tests that verify all the bits fit together correctly in a matter of seconds or perhaps minutes tops. Strong typing would be nice to have sometimes, but in practice I think it limits the amount of ad-hoc data analysis and exploration you can do while trying to piece together a piece of software. I think the scientists in our company would murder the software engineering team if they had to deal with strong typing to get things done.

kd1220 15y ago

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. 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.

tikhonj 15y ago
I've found that the error messages quickly start making more sense (most of the time anyway...); in fact, now I parse the Haskell type error messages faster and more accurately than similar messages in Java or the like. I'm sufficiently spoiled now that error messages in languages like Python just throw me off completely...

nickknw 15y ago

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. 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?". 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. The runners up were 'Tools', and 'Barrier To Entry'. 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. 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. [1] - http://blog.johantibell.com/2011/08/results-from-state-of-haskell-2011.html http://blog.johantibell.com/2011/08/results-from-state-of-ha... [2] - http://nickknowlson.com/blog/2011/09/12/haskell-survey-categorized-weaknesses/ http://nickknowlson.com/blog/2011/09/12/haskell-survey-categ...

whackberry 15y ago

Why haskell is a more appropriate question.

gawi 15y ago

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). 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.

SkyMarshal 15y ago
Yes, I actually started learning Haskell recently b/c I thought it would help me better grok Scala, which seems to borrow mostly from the ML family. Scala is definitely a better Java imho, and you get to keep the JVM and all its libraries, and the Lift web framework is superb, and you can even build Android apps with Scala. But ironically I've found myself falling in love with Haskell and not wanting to use anything else. For the first time ever I know what a real type system is and what it's for, and Haskell basically pulls a Steve Jobs in completely rethinking how to do parallelism (strictly control global state and side effects by eliminating them by default, enabled only via monad). Mind expanding indeed.

PPGualtieri 15y ago

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.

joevandyk 15y ago
Are most of those names for simple concepts / design patterns / types? I'm finding more and more that the hardest part of haskell is understanding the syntax and the terminology.
- Uchikoma 15y ago
  A lot of stuff is quite easy, after reading http://learnyouahaskell.com/ http://learnyouahaskell.com/ - but there is a tendency in the Haskell community, perhaps not in the core but at the fringes to look more elite, and with a lot of hand waving to make simple things (Monads come to mind) something complex sounding. Take the IO Monad. Everyone who wrote some web/servlet code, that needs to output stuff to the web over several classes (might not be the best design in the beginning) uses a Writer (or other class) to aggregate output. He therefore, as global vars are bad (and thread local are worse ;-) adds a Writer to every method. public T doSomeStuff(T input, Writer io) This is nasty and ugly, and the IO monad is in essence just another way to write this in a neat form, make it composable and control the IO environment. public IO<T> doSomeStuff(IO<T> input) But you would not get this insight from any of the monad tutorials written by Haskell people (except the link above). Simple monad insight comes form other people outside the Haskell community, e.g. James Iry http://james-iry.blogspot.com/2007/09/monads-are-elephants-part-1.html http://james-iry.blogspot.com/2007/09/monads-are-elephants-p...

CoffeeDregs 15y ago

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 ... 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. 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.

jlarocco 15y ago

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. 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? 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.

SkyMarshal 15y ago
I don't know if this was the intent or a side effect, but one reason for strictly controlling side effects is that it improves parallelization of the code. Global state, mutable vars, other side effects are some of the biggest obstacles to code parallelization, and that's one of Haskell's solutions to it. Haskell and Erlang seem to be the only two languages that seem designed from the ground up for massive concurrency and parallelism.
gtirloni 15y ago
One of the reasons I'd suggest Haskell to someone is exactly the community. I cannot see a question going unanswered on #haskell or at least 2-3 trying to help (doesn't matter if it's beginner-level or advanced). My experience has been the opposite.

jamii 15y ago

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. 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). 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]. 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. [1] http://conal.net/papers/type-class-morphisms/ http://conal.net/papers/type-class-morphisms/ [2] http://books.google.com/books/about/Purely_functional_data_structures.html?id=SxPzSTcTalAC http://books.google.com/books/about/Purely_functional_data_s... [3] http://github.com/jamii/erl-telehash http://github.com/jamii/erl-telehash

mseebach 15y ago

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?". Second, A resulting correct Haskell program is likely more reliable, maintainable, and perhaps faster 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.

neilk 15y ago
I am guessing that you have never worked with Haskell? Your hypothesis -- that difficult languages result in more bug-free code, due to selection bias -- is, to say the least, somewhat of a minority opinion. But even if we accept this, Haskell is different. The difficulties of Haskell are not arbitrary. Nor are they related to the difficulty of understanding the machine at a low level. In fact, Haskell insulates you from all that; it's easily the highest level language in common use. It's that Haskell insists on program correctness. You have to consider the entire range of values that any function could ever process. And due to its purity, Haskell applies a razor to your thought process, cutting out all unjustified or implicit assumptions. Luckily it also gives you tools of unparalleled flexibility when it comes to creating abstractions. Creating a new abstraction (like the composition of two functions) isn't just as easy as function application, that's how you do function application in Haskell. Typically with less syntactical fuss than it takes Java to initialize a variable.
- mseebach 15y ago
  No, I have not worked with Haskell. I agree that a good type system eliminates an entire class of bugs (being strongly typed is what makes Java bearable), but I rarely see bugs in well-written software caused by not having considered the full range of inputs to your function.
  - 15y ago

bitcracker 15y ago

Haskell demonstrates the difference between theory and practice. 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? 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? Because syntax really matters. For this reason imperative languages like C++, Java, Python, Perl, Javascript, even PHP are so successfull. 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. My current recommendation: shenlanguage.org