What it's like to use Haskell(engineering.imvu.com)
engineering.imvu.com
What it's like to use Haskell
http://engineering.imvu.com/2014/03/24/what-its-like-to-use-haskell
300 コメント
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.
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.
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.
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.
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?
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?
> 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...
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...
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.
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.
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). It's where I first heard about Facebook's use of OCaml to create Hack (http://www.youtube.com/watch?v=gKWNjFagR9k)
For those who have an interest in this, I recommend the Commercial Users of Functional Programming workshop (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)
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?
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!
good post, Tikhon!
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.
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.
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
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
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.