30 ms·

What it's like to use Haskell

378 points by tikhonj 13y ago

amirmc 13y ago
It's good to hear stories about how FP is being used in industry and I'd like to read more. For those who have an interest in this, I recommend the Commercial Users of Functional Programming workshop (http://cufp.org http://cufp.org). It's where I first heard about Facebook's use of OCaml to create Hack (http://www.youtube.com/watch?v=gKWNjFagR9k http://www.youtube.com/watch?v=gKWNjFagR9k)
- teemo_cute 13y ago
  While visiting your link (http://cufp.org http://cufp.org), I saw Chester Bennin of Linkin Park fame there. I didn't know that he's also a programmer! Programming in a functional manner. Another Wow!
  - omaranto 13y ago
    Isn't the Linkin Park vocalist named Chester Bennington? I think you're off by a gton.
    - teemo_cute 13y ago
      Chester Bennin is what the website says. Click his picture in the upper-right corner, you'll be then taken to the page where it says his name is 'chester Bennin.'
      - omaranto 13y ago
        I agree there is a "chester Bennin" listed on CUFP, there is also a person named "Chester Bennington" who was the lead singer of Linkin Park. What I disagree with is your claim that these people with different last names are the same person.
        teemo_cute 13y ago
        Haven't you seen the picture? It looks like Chester. I was not the one who claimed they are the same person. If they are indeed different then the CUFP website is at fault for misinformation.
        omaranto 13y ago
        Oh, sorry, I didn't realize that CUFP was saying this. I searched for "chester bennin site:cufp.org" on Google and the only result returned was this page: http://cufp.org/users/genie http://cufp.org/users/genie
        teemo_cute 13y ago
        Apology accepted :) But you're kind of right. I can't really find information on Chester (from Linkin Park) doing functional programming. It's either the guy on the picture really looks like Chester, or the said person (programmer) used Chester's pic as his avatar (unlikely, though, since they are a reputable sight).
kristianp 13y ago
It always surprises me to see these imvu.com posts on HN. They are often insightful and interesting, but when you see the website you wonder who pays money for this. Do they sell virtual goods for their own virtual world, similar to secondlife?
- teemo_cute 13y ago
  They do. I was once an active IMVU user. Outward appearances can be deceiving, but believe me they are profitable. If you read Eric Ries book 'The Lean Startup' you can have a glimpse of IMVU's back story there.
  - piokuc 13y ago
    Yeah, IMVU is a company behind a product which most people know about because of the "Lean Startup" book, not because they used the product itself. I must say I read the book with great interest but I never found the product itself interesting enough to even have a look at at :)
    - Pxtl 13y ago
      The target market is pretty clearly teenaged/tweener girls. I'm not surprised to learn that Hacker News doesn't have many of those.
- doesnt_know 13y ago
  Here is the shop: http://www.imvu.com/shop/ http://www.imvu.com/shop/ Clothing, Furniture, Rooms, Avatars. I've never heard of imvu before but I don't see how it's any different than micro-transactions within a MMO. If anyone plans to make the argument that MMO's are different because they have "gameplay", then you're probably someone that has never played a very social MMO before. As an ex-EVE player, I can say with extreme confidence that at least 80% of our alliance ("guild"/social group) was not there to actually play the game. It's pretty common that after a certain amount of game time, you just see the "game" as a glorified chat room. It was an ongoing joke to point out how most of us paid $15 to CCP every month for the ability to talk to each other over XMPP.
auvrw 13y ago
i'd like to hear more about employers' perspectives on hiring for "an uncommon language without a comparatively sparse industrial track record." there was some debate about it in the clojure 1.6 release announcement. the author of the article didn't find it to be a problem, but then he was apparently only hiring one person. good post, Tikhon!
- copergi 13y ago
  I've had experience on both sides, plus know some other people who have been recently hiring haskellers. I have a huge problem hiring haskell people because the company I work for kinda sucks. I don't want to work here, so I can't really be surprised that nobody else does either. Haskell users seem to be more picky about where they work and what they work on, so if you've got micromanagement and "do this wrong because I said so" going on, you'll have a hard time. Where as you can still easily get hordes of PHP programmers willing to tolerate anything. On the other hand, someone hiring remote haskell programmers for a company where the culture values quality had 100+ applications for half a dozen openings and really has their pick of a lot of top notch people. I think if you can offer a good job, finding haskell people isn't a problem. But if you can't, then I would stick to popular_language_x.
- hibikir 13y ago
  Not all uncommon languages are made equal. It's very different to hire someone to work on Scala than it is to hire someone to work in PICK. I believe than when push comes to shove, the language your team uses is not the primary determination of the quality of your software. I've actually seen good programs in PICK, an ancient abomination that nobody should be using today. Your major difference is people. Good developers with a good direction will give you good software. Bad developers with the same toolset will give you bad software. So, if anything, your language selection is important because it gives you a very different talent pool. Hiring a Scala developer, for instance, isn't all that easy, but it's definitely not impossible. For the extra pain you pay in finding someone that will use Scala instead of Java, you get, in exchange, a major filter on your applicants, which tends to be a good thing. With an antique like PICK, the filter works against you, because what you get is the very old that have not moved on, and the desperate. I do not think that getting more and more exclusive gets you a better filter, even when you are looking for relatively hip, uncommon languages. Is your Clojure developer naturally better than your Scala developer? How about Haskell? It's not really an issue of every filtering picking the best, but picking people that care about their tools. So if someone told me that they are hiring developers, and that they completely lack a network to pull them from, it'll be easier to get a good core of developers in one of those uncommon languages than if you just place an ad for people that have 10 years of Java experience. This situation is uncommon though: If you are hiring, you typically have a network. Then what you do is to target some of the best developers you can get a hold of, and hire around the technologies they want to use. You'd be surprised by how much money a competitor has to pay a developer to poach them out of you if they really like your current toolset, but aren't really all that fond of the one the competitor uses. We decided on Scala because our seed team wanted to use it, and just went out and hired locals that had similar technology interest. We also brought in a few major independent consultants that made sure our core team really understood the language, instead of just staring with good developers with little experience in their toolset. Overall, our experience was very positive, and we have a happy Scala crew. Of course, YMMV.
noelwelsh 13y ago
I can't like this post enough. It affirms everything I believe to be true about developing software using modern languages. I wish more developers would invest more time in learning better tools.
- lallysingh 13y ago
  It's funny. I want to either give your comment a "+1 Me too!" response, or a huge rant on software quality and the language quagmire we're in with weak (C++/Java) or missing (JS/Python) type systems. To throw a statement out there without substantiation, and then cowardly running away, I'll say that Haskell feels as easy as Python, where in Python you have to do a little thinking about what types of objects get passed where, often while debugging, in Haskell you have to figure out the types of data/functions while compiling. The result, I feel, is about the same amount of work. The difference is that the Haskell result is substantially, /substantially/ easier to use in larger projects. Again, that's without substantiation, and with me immediately running away in cowardice!
  - ixmatus 13y ago
    Haskell is definitely not as "easy" as Python but I actually think it's more straight forward than Python is. There's more cognitive work up-front but the pay off is very big in terms of stability, maintainability, etc... in the long run. I actually think it costs less in amount of work to do something in Haskell than in Python (and Erlang, even). When I have to drop into Python or Javascript I feel like I'm pulling out my MiniTonka toys vs. the actual dump truck out back by the barn. When I went from PHP to Python it felt like that too. As it stands though, I write systems critical services in HS now and keep the web app stuff in Python. I have written two production web apps in Snap and I loved every minute of it.
- pekk 13y ago
  I guess saying "This." didn't seem verbose enough. Let me propose an incredibly controversial idea: Haskell isn't a better tool, it's just yet another tool. Which is aggressively promoted not so much with actual benefits, but by trying to shame people who prefer other tools by calling them dullards and telling them that they don't know what they are doing.
pron 13y ago
Switching a programming language is a major decision for a company. It requires changing the runtime library and possibly re-writing a lot of in-house infrastructure. While personal affinity to a language is important, making a decision for a company might have substantial business consequences. For a company, overall language adoption, availability of libraries, tools and talent (and I'm not talking about training someone to be productive; sooner or later you need real experts and training an expert is expensive in any language) are extremely important. That's why when choosing between two languages, assuming both are well suited to the job at hand, a company should always pick the one with the wider adoption unless the other is so significantly "better" to trump lesser adoption. And the smaller the adoption, the "better" the language needs to be. There's no doubt Haskell is an excellent programming language. I'm learning it and enjoying it. But because it has such low adoption rates, it needs to provide benefits that are orders of magnitude higher than other, more popular languages. I guess that for some very particular use cases it does, but I just can't see it in the vast majority of cases. Hobbyists can afford playing with different languages, and can (and perhaps should) jump from one to the next. Companies can't (or most certainly shouldn't, unless for toy projects); they should pick (wisely) a popular language that's right for them, and just stick with it. BTW, I think that if a company does want to try a good, though not-so-popular language, it should pick a JVM language, as the interoperability among JVM languages, and the availability of libraries that can be shared among the popular and less-so JVM languages, reduces much of the risk.
- boothead 13y ago
  I about 50% agree with you here. The factor that you're forgetting is the filter effect: Haskell is not adopted, it's learned after a thankless (there are no jobs) process of deep study. This means that the quality of available talent is of a much higher standard. If you adopt a technology with these characteristics, and you're one of the few who are hiring in this pool then you have a significant advantage! The only risk in my mind is when the big boys figure it out and start gobbling up Haskellers! :-)
  - pron 13y ago
    I think this is a bad filter. I'd rather filter prospective employees based on an ambitious algorithm or a complex project they've done. Most of the people I know that like solving hard problems with novel data structures, algorithms, or mechanically-sympathetic implementations are averse to spending time on learning new programming languages. It seems to them (and to me) like focusing on bling rather than on substance. Of course, this is a crude generalization, and obviously, anyone who's interested in learning any new, perhaps unappreciated, and difficult skill would make a good hire, and Haskellers are no exception. But I wouldn't filter based on programming language preference.
Kiro 13y ago
The problem I had with Haskell when trying it out was that every time I wanted to use a package with dependencies I ran into "cabal: Error: some packages failed to install. The exception was: ExitFailure 1.". The solution was most often trying earlier versions of the package until it worked or not use the package at all. Cabal just seemed so broken.
- chopin 13y ago
  Not to diminish the Cabal problems here, but you run into similar problems with Maven as well. Version management is a real hard problem. Especially when there is little awareness in producing compatible successors. Especially this problem made my experiences with Haskell somewhat bitter. But I have the same problem (in really productive code) with Maven. Writing a working Maven plugin can be made pretty challenging by that as especially the stuff you want to use in Maven plugins is burdened with incompatibilities. So, Cabal is in good company in that regard.
  - bjourne 13y ago
    Haskell packages like to specify requirements using both a lower bound and an upper bound. So package A depends on B being version 0.55 <= B < 0.99. Package C depends on B being version 0.90 <= B <= 1.35. So if you installed C before A you will get version 1.35 of B and will now need to either downgrade B or have two versions installed. Chaos ensues. Why Hackage packagers like to specify upper bounds I'm not sure of. Backwards compatibility either is very hard to achieve in Haskell or maintainers just don't care that much about it. I don't know about Maven so I can't say whether that is as bad. But at least pip, npm and gems are a breeze compared to cabal.
    - massysett 13y ago
      "Why Hackage packagers like to specify upper bounds I'm not sure of." There is a policy that says you're supposed to do this: http://www.haskell.org/haskellwiki/Package_versioning_policy http://www.haskell.org/haskellwiki/Package_versioning_policy The idea is that by specifying upper bounds, the package is more likely to build after the dependencies change. This idea is subject to considerable controversy. http://www.haskell.org/pipermail/haskell-cafe/2012-August/102885.html http://www.haskell.org/pipermail/haskell-cafe/2012-August/10... There's also been more recent mailing list traffic on it, but my Google skills are failing me here and the arguments haven't changed all that much. My opinion is that we are relying too heavily on upper bounds to solve a whole bevy of interrelated, but separate, problems. Other solutions are evolving to help deal with some of the problems. cabal sandboxes allow you to build a package separately from your others, reducing dependency issues. cabal freeze will help you specify exact dependencies, including transitive ones. Another project, Stackage, aims to maintain a whole slew of packages in a buildable state: https://github.com/fpco/stackage https://github.com/fpco/stackage
iaskwhy 13y ago
I didn't know what Haskell code looked like so I went to the official website and there was this code example[1]: qsort (p:xs) = qsort [x | x<-xs, x<p] ++ [p] ++ qsort [x | x<-xs, x>=p] Is this a good example of good Haskell code? [1] http://www.haskell.org/haskellwiki/Introduction#Brevity http://www.haskell.org/haskellwiki/Introduction#Brevity
- emillon 13y ago
  It indeeds looks a bit magical, like the infamous fibonacci example that uses lazy lists. I don't think that list comprehensions are very idiomatic in Haskell, one would probably use Data.List.partition instead: qsort [] = [] qsort (p:xs) = low ++ [p] ++ high where (low, high) = partition (< p) xs
  - danieldk 13y ago
    I think you are missing the recursive calls ;).
    - emillon 13y ago
      Indeed! Hey, who said that static typing caught all bugs ? :)
      - axman6 13y ago
        Sure it does, you just need Quickcheck property based testing: forall $ \xs -> sorted (qsort xs :: [Int])
        wnoise 13y ago
        That's not static.
        dangirsh 13y ago
        Or typing
exDM69 13y ago
Thanks especially for the "Not All Sunshine and Rainbows" section. It is all too easy to write about the positive things and leave the negative parts out. Resource leaks in Haskell perhaps a bit trickier to track than in other languages and I would appreciate hearing more about the issue you were experiencing and how you solved the problem. In many blog posts there have been warnings against long running Haskell processes but you guys seem to have fairly successful with it. Also, the problems you were experiencing with Cabal might be fixed in newer versions with the sandboxes feature which is now built-in with later versions of Cabal.
- klrr 13y ago
  As for resource leaks, the particular example in the post was a bit unfortunate. The problem in general have a solution though. You can either use functions that limit a resource inside a limited scope, and then have it clean up automatically when done (like 'withFile'). And if you want to do more complicated things there are the resourcet and pipes-safe libraries.
- implicit 13y ago
  We deal with Haskell resource leaks the same way you would in C++ or Java. We have production monitors on every host that show basic metrics like memory, disk, and CPU utilization. Atop that, we added a tracker for the number of suspended Haskell threads. (that is, threads which are not blocked on I/O, but are also not running) We found that the machines are usually able to handle requests as soon as they come in, so if the number of Haskell threads goes above 0 for any length of time, the machine is about an hour away from melting down. We can restart the process without losing any connections, so this leaves us a very comfortable margin of error. Once we know we have a problem, it's usually pretty simple to run the heap profiler on the process and look at recent commits. We continuously deploy, so there's only about a 10 minute delay before a particular commit is running in front of customers. This makes tracking regressions down really fast. Even in cases where we can't figure out why a bit of code is leaking, we can almost always identify it and revert it until we understand what's going on.
  - benmos 13y ago
hyperpape 13y ago
I'm curious about the claim that it only takes a few days to get people productive working in Haskell. I like the language a lot, but learning it has definitely been slow compared to any other language I've learned. It just seems like there are a lot of changes to how you think. Is this a feature of the way your code is structured that simplifies what people have to understand about the language before they can contribute?
- goalieca 13y ago
  I've been learning haskell for the better part of 8 years. I say learning, because I spend far too much time trying to study the patterns and math from the abstract point of view. Every few months I print off a research paper and struggle with it for a few days until I get it. I never get to code large projects in it because no one uses it in industry up in the north. I can code in the language no problem but sometimes I feel that idiomatic ideal is always just out of reach to all but the Simons.
  - tel 13y ago
    I highly suggest reading Richard Bird's book "Pearls of Functional Algorithm Design". It's a really great way to get some insight into top-style FP.
- nbouscal 13y ago
  To be fair to the OP, the original claim was: "People who have prior functional programming knowledge seem to find their stride in just a few days." I would be somewhat surprised if someone with no prior functional programming experience could be productive in a few days in Haskell, because as you say, there are a lot of changes to how you think about programming. It's a lot easier for people with experience in a Lisp, and even easier yet for people with experience in another ML descendant. All that said, the structure of the code definitely does help a lot in lowering the bar for contributions. When Don Stewart was on the Haskell Cast [1], he mentioned that the way they use Haskell allows contributions from people who not only have no prior functional experience but who have little CS background at all past basic programming literacy. Much of the ability to do this comes from Haskell's rigorous isolation of side effects. [1]: http://www.haskellcast.com/episode/002-don-stewart-on-real-world-haskell/ http://www.haskellcast.com/episode/002-don-stewart-on-real-w... around 42:40 or so
Pxtl 13y ago
Wait, IMVU? As in those terrible banner-ads with the Bratz-dolls-looking avatars? They use Haskell under the hood? Seriously, this is like finding out that McDonalds' restaurants are powered by nuclear fusion. Although this does make me very curious about learning Haskell - I've been pretty stagnant about learning new languages.
- mtford 13y ago
  But also the same IMVU co-founded by Eric Ries i.e. The Lean Startup
- cordite 13y ago
  That was my response, I actually gained a high amount of respect from seeing that and I browsed the rest of their engineering blog.
- judk 13y ago
  McD's runs the most technically sophisticated operation in the industry.
AnimalMuppet 13y ago
> I wouldn’t write an OS kernel in it, but Haskell is way better than PHP as a systems language. What's the definition of "systems language"? If PHP could even remotely be considered an option, the definition is clearly not what I think it is...
csense 13y ago
Haskell is a terrible choice for a production system. I know well over a dozen programming languages. I have a stronger theoretical background in mathematics, computer science, and compiler design than most web developers. But Haskell has always been utterly mystifying to me. I've attempted to learn Haskell several times, and I've had monads explained to me several times right here on HN -- but I simply don't seem to be able to wrap my mind around the concept. To be sure, if I had a year or so to devote to studying the theory behind Haskell's type system, I might indeed become more productive writing web applications in Haskell. And I don't doubt that there are certain problems in logic programming or language theory for which Haskell provides useful concepts and powerful tools, to the point where the solutions to important problems may have trivial implementations. I've always thought that a major problem with Haskell for web development is: (A) You'll have difficulty finding people who both know Haskell and are interested in web applications, and (B) you'll have difficulty training web developers in Haskell. The author of the article apparently has a training process that gets around (B), and I'd kind of like to know what it is -- a way to learn Haskell without a ton of study.
- mightybyte 13y ago
  Haskell is something that really needs to be used in order to "learn" it. I didn't learn monads by study/reading, I learned them by just using Haskell for real-world projects. We use Haskell for all our production systems and it is great. Maintenance is MUCH easier in Haskell and it's usually quite simple for new people (with Haskell experience) to get up to speed with a project. We even had a situation where one guy was able to make a highly nontrivial refactoring to a several thousand line project that he had no prior involvement with. It took him a few hours to do the refactoring and once he got it compiling it worked the first time. We are convinced that this feat would have been impossible in any other mainstream language.
  - implicit 13y ago
    It's a huge help to ask a newcomer to start off by make changes to an already-established project that has best practices and idioms already sorted. If you just start with the full language, there are just too many ways to solve every problem and it's not clear which is better for your particular use case. It's a bit like Perl, except moreso: even basic flow control is a library.

378 points by tikhonj 13y ago

It's good to hear stories about how FP is being used in industry and I'd like to read more. For those who have an interest in this, I recommend the Commercial Users of Functional Programming workshop (http://cufp.org http://cufp.org). It's where I first heard about Facebook's use of OCaml to create Hack (http://www.youtube.com/watch?v=gKWNjFagR9k http://www.youtube.com/watch?v=gKWNjFagR9k)

teemo_cute 13y ago
While visiting your link (http://cufp.org http://cufp.org), I saw Chester Bennin of Linkin Park fame there. I didn't know that he's also a programmer! Programming in a functional manner. Another Wow!
- omaranto 13y ago
  Isn't the Linkin Park vocalist named Chester Bennington? I think you're off by a gton.
  - teemo_cute 13y ago
    Chester Bennin is what the website says. Click his picture in the upper-right corner, you'll be then taken to the page where it says his name is 'chester Bennin.'
    - omaranto 13y ago
      I agree there is a "chester Bennin" listed on CUFP, there is also a person named "Chester Bennington" who was the lead singer of Linkin Park. What I disagree with is your claim that these people with different last names are the same person.
      - teemo_cute 13y ago
        Haven't you seen the picture? It looks like Chester. I was not the one who claimed they are the same person. If they are indeed different then the CUFP website is at fault for misinformation.
        omaranto 13y ago
        Oh, sorry, I didn't realize that CUFP was saying this. I searched for "chester bennin site:cufp.org" on Google and the only result returned was this page: http://cufp.org/users/genie http://cufp.org/users/genie
        teemo_cute 13y ago
        Apology accepted :) But you're kind of right. I can't really find information on Chester (from Linkin Park) doing functional programming. It's either the guy on the picture really looks like Chester, or the said person (programmer) used Chester's pic as his avatar (unlikely, though, since they are a reputable sight).

kristianp 13y ago

It always surprises me to see these imvu.com posts on HN. They are often insightful and interesting, but when you see the website you wonder who pays money for this. Do they sell virtual goods for their own virtual world, similar to secondlife?

teemo_cute 13y ago
They do. I was once an active IMVU user. Outward appearances can be deceiving, but believe me they are profitable. If you read Eric Ries book 'The Lean Startup' you can have a glimpse of IMVU's back story there.
- piokuc 13y ago
  Yeah, IMVU is a company behind a product which most people know about because of the "Lean Startup" book, not because they used the product itself. I must say I read the book with great interest but I never found the product itself interesting enough to even have a look at at :)
  - Pxtl 13y ago
    The target market is pretty clearly teenaged/tweener girls. I'm not surprised to learn that Hacker News doesn't have many of those.
doesnt_know 13y ago
Here is the shop: http://www.imvu.com/shop/ http://www.imvu.com/shop/ Clothing, Furniture, Rooms, Avatars. I've never heard of imvu before but I don't see how it's any different than micro-transactions within a MMO. If anyone plans to make the argument that MMO's are different because they have "gameplay", then you're probably someone that has never played a very social MMO before. As an ex-EVE player, I can say with extreme confidence that at least 80% of our alliance ("guild"/social group) was not there to actually play the game. It's pretty common that after a certain amount of game time, you just see the "game" as a glorified chat room. It was an ongoing joke to point out how most of us paid $15 to CCP every month for the ability to talk to each other over XMPP.

auvrw 13y ago

i'd like to hear more about employers' perspectives on hiring for "an uncommon language without a comparatively sparse industrial track record." there was some debate about it in the clojure 1.6 release announcement. the author of the article didn't find it to be a problem, but then he was apparently only hiring one person. good post, Tikhon!

copergi 13y ago
I've had experience on both sides, plus know some other people who have been recently hiring haskellers. I have a huge problem hiring haskell people because the company I work for kinda sucks. I don't want to work here, so I can't really be surprised that nobody else does either. Haskell users seem to be more picky about where they work and what they work on, so if you've got micromanagement and "do this wrong because I said so" going on, you'll have a hard time. Where as you can still easily get hordes of PHP programmers willing to tolerate anything. On the other hand, someone hiring remote haskell programmers for a company where the culture values quality had 100+ applications for half a dozen openings and really has their pick of a lot of top notch people. I think if you can offer a good job, finding haskell people isn't a problem. But if you can't, then I would stick to popular_language_x.
hibikir 13y ago
Not all uncommon languages are made equal. It's very different to hire someone to work on Scala than it is to hire someone to work in PICK. I believe than when push comes to shove, the language your team uses is not the primary determination of the quality of your software. I've actually seen good programs in PICK, an ancient abomination that nobody should be using today. Your major difference is people. Good developers with a good direction will give you good software. Bad developers with the same toolset will give you bad software. So, if anything, your language selection is important because it gives you a very different talent pool. Hiring a Scala developer, for instance, isn't all that easy, but it's definitely not impossible. For the extra pain you pay in finding someone that will use Scala instead of Java, you get, in exchange, a major filter on your applicants, which tends to be a good thing. With an antique like PICK, the filter works against you, because what you get is the very old that have not moved on, and the desperate. I do not think that getting more and more exclusive gets you a better filter, even when you are looking for relatively hip, uncommon languages. Is your Clojure developer naturally better than your Scala developer? How about Haskell? It's not really an issue of every filtering picking the best, but picking people that care about their tools. So if someone told me that they are hiring developers, and that they completely lack a network to pull them from, it'll be easier to get a good core of developers in one of those uncommon languages than if you just place an ad for people that have 10 years of Java experience. This situation is uncommon though: If you are hiring, you typically have a network. Then what you do is to target some of the best developers you can get a hold of, and hire around the technologies they want to use. You'd be surprised by how much money a competitor has to pay a developer to poach them out of you if they really like your current toolset, but aren't really all that fond of the one the competitor uses. We decided on Scala because our seed team wanted to use it, and just went out and hired locals that had similar technology interest. We also brought in a few major independent consultants that made sure our core team really understood the language, instead of just staring with good developers with little experience in their toolset. Overall, our experience was very positive, and we have a happy Scala crew. Of course, YMMV.

noelwelsh 13y ago

I can't like this post enough. It affirms everything I believe to be true about developing software using modern languages. I wish more developers would invest more time in learning better tools.

lallysingh 13y ago
It's funny. I want to either give your comment a "+1 Me too!" response, or a huge rant on software quality and the language quagmire we're in with weak (C++/Java) or missing (JS/Python) type systems. To throw a statement out there without substantiation, and then cowardly running away, I'll say that Haskell feels as easy as Python, where in Python you have to do a little thinking about what types of objects get passed where, often while debugging, in Haskell you have to figure out the types of data/functions while compiling. The result, I feel, is about the same amount of work. The difference is that the Haskell result is substantially, /substantially/ easier to use in larger projects. Again, that's without substantiation, and with me immediately running away in cowardice!
- ixmatus 13y ago
  Haskell is definitely not as "easy" as Python but I actually think it's more straight forward than Python is. There's more cognitive work up-front but the pay off is very big in terms of stability, maintainability, etc... in the long run. I actually think it costs less in amount of work to do something in Haskell than in Python (and Erlang, even). When I have to drop into Python or Javascript I feel like I'm pulling out my MiniTonka toys vs. the actual dump truck out back by the barn. When I went from PHP to Python it felt like that too. As it stands though, I write systems critical services in HS now and keep the web app stuff in Python. I have written two production web apps in Snap and I loved every minute of it.
pekk 13y ago
I guess saying "This." didn't seem verbose enough. Let me propose an incredibly controversial idea: Haskell isn't a better tool, it's just yet another tool. Which is aggressively promoted not so much with actual benefits, but by trying to shame people who prefer other tools by calling them dullards and telling them that they don't know what they are doing.

pron 13y ago

Switching a programming language is a major decision for a company. It requires changing the runtime library and possibly re-writing a lot of in-house infrastructure. While personal affinity to a language is important, making a decision for a company might have substantial business consequences. For a company, overall language adoption, availability of libraries, tools and talent (and I'm not talking about training someone to be productive; sooner or later you need real experts and training an expert is expensive in any language) are extremely important. That's why when choosing between two languages, assuming both are well suited to the job at hand, a company should always pick the one with the wider adoption unless the other is so significantly "better" to trump lesser adoption. And the smaller the adoption, the "better" the language needs to be. There's no doubt Haskell is an excellent programming language. I'm learning it and enjoying it. But because it has such low adoption rates, it needs to provide benefits that are orders of magnitude higher than other, more popular languages. I guess that for some very particular use cases it does, but I just can't see it in the vast majority of cases. Hobbyists can afford playing with different languages, and can (and perhaps should) jump from one to the next. Companies can't (or most certainly shouldn't, unless for toy projects); they should pick (wisely) a popular language that's right for them, and just stick with it. BTW, I think that if a company does want to try a good, though not-so-popular language, it should pick a JVM language, as the interoperability among JVM languages, and the availability of libraries that can be shared among the popular and less-so JVM languages, reduces much of the risk.

boothead 13y ago
I about 50% agree with you here. The factor that you're forgetting is the filter effect: Haskell is not adopted, it's learned after a thankless (there are no jobs) process of deep study. This means that the quality of available talent is of a much higher standard. If you adopt a technology with these characteristics, and you're one of the few who are hiring in this pool then you have a significant advantage! The only risk in my mind is when the big boys figure it out and start gobbling up Haskellers! :-)
- pron 13y ago
  I think this is a bad filter. I'd rather filter prospective employees based on an ambitious algorithm or a complex project they've done. Most of the people I know that like solving hard problems with novel data structures, algorithms, or mechanically-sympathetic implementations are averse to spending time on learning new programming languages. It seems to them (and to me) like focusing on bling rather than on substance. Of course, this is a crude generalization, and obviously, anyone who's interested in learning any new, perhaps unappreciated, and difficult skill would make a good hire, and Haskellers are no exception. But I wouldn't filter based on programming language preference.

Kiro 13y ago

The problem I had with Haskell when trying it out was that every time I wanted to use a package with dependencies I ran into "cabal: Error: some packages failed to install. The exception was: ExitFailure 1.". The solution was most often trying earlier versions of the package until it worked or not use the package at all. Cabal just seemed so broken.

chopin 13y ago
Not to diminish the Cabal problems here, but you run into similar problems with Maven as well. Version management is a real hard problem. Especially when there is little awareness in producing compatible successors. Especially this problem made my experiences with Haskell somewhat bitter. But I have the same problem (in really productive code) with Maven. Writing a working Maven plugin can be made pretty challenging by that as especially the stuff you want to use in Maven plugins is burdened with incompatibilities. So, Cabal is in good company in that regard.
- bjourne 13y ago
  Haskell packages like to specify requirements using both a lower bound and an upper bound. So package A depends on B being version 0.55 <= B < 0.99. Package C depends on B being version 0.90 <= B <= 1.35. So if you installed C before A you will get version 1.35 of B and will now need to either downgrade B or have two versions installed. Chaos ensues. Why Hackage packagers like to specify upper bounds I'm not sure of. Backwards compatibility either is very hard to achieve in Haskell or maintainers just don't care that much about it. I don't know about Maven so I can't say whether that is as bad. But at least pip, npm and gems are a breeze compared to cabal.
  - massysett 13y ago
    "Why Hackage packagers like to specify upper bounds I'm not sure of." There is a policy that says you're supposed to do this: http://www.haskell.org/haskellwiki/Package_versioning_policy http://www.haskell.org/haskellwiki/Package_versioning_policy The idea is that by specifying upper bounds, the package is more likely to build after the dependencies change. This idea is subject to considerable controversy. http://www.haskell.org/pipermail/haskell-cafe/2012-August/102885.html http://www.haskell.org/pipermail/haskell-cafe/2012-August/10... There's also been more recent mailing list traffic on it, but my Google skills are failing me here and the arguments haven't changed all that much. My opinion is that we are relying too heavily on upper bounds to solve a whole bevy of interrelated, but separate, problems. Other solutions are evolving to help deal with some of the problems. cabal sandboxes allow you to build a package separately from your others, reducing dependency issues. cabal freeze will help you specify exact dependencies, including transitive ones. Another project, Stackage, aims to maintain a whole slew of packages in a buildable state: https://github.com/fpco/stackage https://github.com/fpco/stackage

iaskwhy 13y ago

I didn't know what Haskell code looked like so I went to the official website and there was this code example[1]: qsort (p:xs) = qsort [x | x<-xs, x<p] ++ [p] ++ qsort [x | x<-xs, x>=p] Is this a good example of good Haskell code? [1] http://www.haskell.org/haskellwiki/Introduction#Brevity http://www.haskell.org/haskellwiki/Introduction#Brevity

emillon 13y ago
It indeeds looks a bit magical, like the infamous fibonacci example that uses lazy lists. I don't think that list comprehensions are very idiomatic in Haskell, one would probably use Data.List.partition instead: qsort [] = [] qsort (p:xs) = low ++ [p] ++ high where (low, high) = partition (< p) xs
- danieldk 13y ago
  I think you are missing the recursive calls ;).
  - emillon 13y ago
    Indeed! Hey, who said that static typing caught all bugs ? :)
    - axman6 13y ago
      Sure it does, you just need Quickcheck property based testing: forall $ \xs -> sorted (qsort xs :: [Int])
      - wnoise 13y ago
        That's not static.
      - dangirsh 13y ago
        Or typing

exDM69 13y ago

Thanks especially for the "Not All Sunshine and Rainbows" section. It is all too easy to write about the positive things and leave the negative parts out. Resource leaks in Haskell perhaps a bit trickier to track than in other languages and I would appreciate hearing more about the issue you were experiencing and how you solved the problem. In many blog posts there have been warnings against long running Haskell processes but you guys seem to have fairly successful with it. Also, the problems you were experiencing with Cabal might be fixed in newer versions with the sandboxes feature which is now built-in with later versions of Cabal.

klrr 13y ago
As for resource leaks, the particular example in the post was a bit unfortunate. The problem in general have a solution though. You can either use functions that limit a resource inside a limited scope, and then have it clean up automatically when done (like 'withFile'). And if you want to do more complicated things there are the resourcet and pipes-safe libraries.
implicit 13y ago
We deal with Haskell resource leaks the same way you would in C++ or Java. We have production monitors on every host that show basic metrics like memory, disk, and CPU utilization. Atop that, we added a tracker for the number of suspended Haskell threads. (that is, threads which are not blocked on I/O, but are also not running) We found that the machines are usually able to handle requests as soon as they come in, so if the number of Haskell threads goes above 0 for any length of time, the machine is about an hour away from melting down. We can restart the process without losing any connections, so this leaves us a very comfortable margin of error. Once we know we have a problem, it's usually pretty simple to run the heap profiler on the process and look at recent commits. We continuously deploy, so there's only about a 10 minute delay before a particular commit is running in front of customers. This makes tracking regressions down really fast. Even in cases where we can't figure out why a bit of code is leaking, we can almost always identify it and revert it until we understand what's going on.
- benmos 13y ago

hyperpape 13y ago

I'm curious about the claim that it only takes a few days to get people productive working in Haskell. I like the language a lot, but learning it has definitely been slow compared to any other language I've learned. It just seems like there are a lot of changes to how you think. Is this a feature of the way your code is structured that simplifies what people have to understand about the language before they can contribute?

goalieca 13y ago
I've been learning haskell for the better part of 8 years. I say learning, because I spend far too much time trying to study the patterns and math from the abstract point of view. Every few months I print off a research paper and struggle with it for a few days until I get it. I never get to code large projects in it because no one uses it in industry up in the north. I can code in the language no problem but sometimes I feel that idiomatic ideal is always just out of reach to all but the Simons.
- tel 13y ago
  I highly suggest reading Richard Bird's book "Pearls of Functional Algorithm Design". It's a really great way to get some insight into top-style FP.
nbouscal 13y ago
To be fair to the OP, the original claim was: "People who have prior functional programming knowledge seem to find their stride in just a few days." I would be somewhat surprised if someone with no prior functional programming experience could be productive in a few days in Haskell, because as you say, there are a lot of changes to how you think about programming. It's a lot easier for people with experience in a Lisp, and even easier yet for people with experience in another ML descendant. All that said, the structure of the code definitely does help a lot in lowering the bar for contributions. When Don Stewart was on the Haskell Cast [1], he mentioned that the way they use Haskell allows contributions from people who not only have no prior functional experience but who have little CS background at all past basic programming literacy. Much of the ability to do this comes from Haskell's rigorous isolation of side effects. [1]: http://www.haskellcast.com/episode/002-don-stewart-on-real-world-haskell/ http://www.haskellcast.com/episode/002-don-stewart-on-real-w... around 42:40 or so

Pxtl 13y ago

Wait, IMVU? As in those terrible banner-ads with the Bratz-dolls-looking avatars? They use Haskell under the hood? Seriously, this is like finding out that McDonalds' restaurants are powered by nuclear fusion. Although this does make me very curious about learning Haskell - I've been pretty stagnant about learning new languages.

mtford 13y ago
But also the same IMVU co-founded by Eric Ries i.e. The Lean Startup
cordite 13y ago
That was my response, I actually gained a high amount of respect from seeing that and I browsed the rest of their engineering blog.
judk 13y ago
McD's runs the most technically sophisticated operation in the industry.

AnimalMuppet 13y ago

> I wouldn’t write an OS kernel in it, but Haskell is way better than PHP as a systems language. What's the definition of "systems language"? If PHP could even remotely be considered an option, the definition is clearly not what I think it is...

csense 13y ago

Haskell is a terrible choice for a production system. I know well over a dozen programming languages. I have a stronger theoretical background in mathematics, computer science, and compiler design than most web developers. But Haskell has always been utterly mystifying to me. I've attempted to learn Haskell several times, and I've had monads explained to me several times right here on HN -- but I simply don't seem to be able to wrap my mind around the concept. To be sure, if I had a year or so to devote to studying the theory behind Haskell's type system, I might indeed become more productive writing web applications in Haskell. And I don't doubt that there are certain problems in logic programming or language theory for which Haskell provides useful concepts and powerful tools, to the point where the solutions to important problems may have trivial implementations. I've always thought that a major problem with Haskell for web development is: (A) You'll have difficulty finding people who both know Haskell and are interested in web applications, and (B) you'll have difficulty training web developers in Haskell. The author of the article apparently has a training process that gets around (B), and I'd kind of like to know what it is -- a way to learn Haskell without a ton of study.

mightybyte 13y ago
Haskell is something that really needs to be used in order to "learn" it. I didn't learn monads by study/reading, I learned them by just using Haskell for real-world projects. We use Haskell for all our production systems and it is great. Maintenance is MUCH easier in Haskell and it's usually quite simple for new people (with Haskell experience) to get up to speed with a project. We even had a situation where one guy was able to make a highly nontrivial refactoring to a several thousand line project that he had no prior involvement with. It took him a few hours to do the refactoring and once he got it compiling it worked the first time. We are convinced that this feat would have been impossible in any other mainstream language.
- implicit 13y ago
  It's a huge help to ask a newcomer to start off by make changes to an already-established project that has best practices and idioms already sorted. If you just start with the full language, there are just too many ways to solve every problem and it's not clear which is better for your particular use case. It's a bit like Perl, except moreso: even basic flow control is a library.