4 ms·

Not at all. In fact about 95% of all Haskell I write - and I write quite a bit - is for commercial stuff, ranging all the way across large-ish (not quite google

Not at all. In fact about 95% of all Haskell I write - and I write quite a bit - is for commercial stuff, ranging all the way across large-ish (not quite google-scale, yet) scale computation, distributed systems, machine learning, modeling/simulations and web development. More academic feeling stuff like parsing and DSLs are just the cherries on top (though even those were for commercial uses). I'll admit Haskell has a steep learning curve, but once you're there, all this stuff Go is said to do real well feels fairly lackluster compared to what you can find in Haskell-land. What's built into Go can be achieved at the library level in Haskell. As a result, we keep seeing better and better manifestations of key ideas in the library space. Examples include Cloud Haskell, many, many concurrency libraries, STM, Parallel Haskell, many constant-space data streaming libraries (pipes, conduits, enumerators, ...), several excellent parsing libraries (parsec, attoparsec, trifecta, ...), etc. As a side note, I used to do lots of python/ruby - I really can't anymore. They feel simultaneously more burdensome to code (no static type-checking), more verbose (no elegant, long pipelines of computations), less expressive (no real first class functions - you barely use map/reduce/fold/etc. in python) and slower (as in runtime). Having said all that, I do see how Go fills a gap in the market. You need something that's easy to grok and gets just enough of it right that you can produce fast, type-safe-enough and concurrent programs with somewhat less mutable state than what you may be used to in C. A simple mental model and ease of entry are conceivably great for larger, homogeneous teams.

nimrody 14y ago
Can you recommend any open source project that you consider a good example of Haskell usage? (meaning both practical and well-written)
- edwkar 14y ago
  Well, xmonad is an excellent example :-)
- pufuwozu 14y ago
  Pandoc: http://johnmacfarlane.net/pandoc/ http://johnmacfarlane.net/pandoc/ XMonad: http://xmonad.org/ http://xmonad.org/
- bru 14y ago
  I'd say xmonad[1]! It is a very light and fast tiling WM. There's also a couple of elegant and blazingly fast web frameworks, such as Yesod, Snap and Happstack[2]. 1: http://xmonad.org/ http://xmonad.org/ 2: http://www.haskell.org/haskellwiki/Web/Comparison_of_Happstack,_Snap_and_Yesod http://www.haskell.org/haskellwiki/Web/Comparison_of_Happsta... http://stackoverflow.com/questions/5645168/comparing-haskells-snap-and-yesod-web-frameworks http://stackoverflow.com/questions/5645168/comparing-haskell...
  - slurgfest 14y ago
    Installing xmonad requires several hundred megs of dependencies, so what does it mean for it to be light? Low memory footprint?
    - antihero 14y ago
      Pretty much. Hard disk space is still cheaper than RAM, so I think it's a good tradeoff. Plus those dependencies can be used for lots of other things.
icebraining 14y ago
no real first class functions - you barely use map/reduce/fold/etc. in python Can you expand on this?
- hythloday 14y ago
  I'll expand a little, because I've been feeling the same thing recently. Python has syntactic support for list[0] comprehensions, which can be used a little like maps: def addOne(n): return n+1 l = [1, 2, 3] [ addOne(n) for n in l ] # [2, 3, 4] a little like filters: def isOdd(n): return n % 2 == 1 l = [1, 2, 3] [ n for n in l if isOdd(n) ] # [1, 3] and a little like folds/reductions: def accum(s): acc = s def a(n): acc += a return acc return a l = [1, 2, 3] reduce = accum(0) [ reduce (n) for n in l ][-1] # 6 You can also do Cartesian joins, though I rarely see these. There are a couple of problems I've run into. The first is that Python's libraries are just not engineered with the idea of using list comprehensions in this way - folding is as awkward as it looks above, exceptions thrown in the list comprehension functions will terminate the comprehension, many python functions alter state and return None rather than a useful output, and so on. The second is that they're amazingly uncomposable, syntactically: l.map(addOne).filter(isOdd).reduce(accum(0)) is what I'd write in Scala, which is extremely tractable. In comparison, here's the equivalent in python: [ reduce(nr) for nr in [ nf for nf in [ addOne(nm) for nm in l ] if isOdd(nf) ] ][-1] You note that I've had to rename the elements, because they "leak" to their surrounding comprehension - this can be quite confusing the first time you see it. Also these are fairly trivial comprehensions, which call functions rather than evaluate expressions in-place - this is well-supported and very idiomatic, but makes comprehension composition much harder. I find Python's comprehension style very convenient, and I'm sure you could produce an excellent theoretical abstraction over it, but if you're coming at it from the point of view of wanting them to be map/reduce or something equally reasonable-about, you're going to be disappointed. Python isn't an object-oriented language, and isn't a functional language - the more I use it the more I think it's something akin to a collection-oriented language. Maybe that's just the way I use it. :) [0] and also set comprehensions, dict comprehensions, and generator (lazy list) comprehensions, which are wonderful but exacerbate both the problems I talk about.
  - 14y ago
fauigerzigerk 14y ago
I guess it all depends on whether or not you think that pure functional programming makes sense as a general approach to programming. Pure functional or not is a very fundamental choice that influences all other features of a programming language. So I don't think it makes a whole lot of sense to compare Haskell to Go feature by feature. Anyway, I agree that there is no reason why Haskell should be confined to the academic space at all. Actually I think the whole "right tool for the job" mantra is largely misplaced when it comes to Turing complete languages (apart from _very_ low level systems programming).

nimrody 14y ago

Can you recommend any open source project that you consider a good example of Haskell usage? (meaning both practical and well-written)

edwkar 14y ago
Well, xmonad is an excellent example :-)
pufuwozu 14y ago
Pandoc: http://johnmacfarlane.net/pandoc/ http://johnmacfarlane.net/pandoc/ XMonad: http://xmonad.org/ http://xmonad.org/
bru 14y ago
I'd say xmonad[1]! It is a very light and fast tiling WM. There's also a couple of elegant and blazingly fast web frameworks, such as Yesod, Snap and Happstack[2]. 1: http://xmonad.org/ http://xmonad.org/ 2: http://www.haskell.org/haskellwiki/Web/Comparison_of_Happstack,_Snap_and_Yesod http://www.haskell.org/haskellwiki/Web/Comparison_of_Happsta... http://stackoverflow.com/questions/5645168/comparing-haskells-snap-and-yesod-web-frameworks http://stackoverflow.com/questions/5645168/comparing-haskell...
- slurgfest 14y ago
  Installing xmonad requires several hundred megs of dependencies, so what does it mean for it to be light? Low memory footprint?
  - antihero 14y ago
    Pretty much. Hard disk space is still cheaper than RAM, so I think it's a good tradeoff. Plus those dependencies can be used for lots of other things.

icebraining 14y ago

no real first class functions - you barely use map/reduce/fold/etc. in python Can you expand on this?

hythloday 14y ago
I'll expand a little, because I've been feeling the same thing recently. Python has syntactic support for list[0] comprehensions, which can be used a little like maps: def addOne(n): return n+1 l = [1, 2, 3] [ addOne(n) for n in l ] # [2, 3, 4] a little like filters: def isOdd(n): return n % 2 == 1 l = [1, 2, 3] [ n for n in l if isOdd(n) ] # [1, 3] and a little like folds/reductions: def accum(s): acc = s def a(n): acc += a return acc return a l = [1, 2, 3] reduce = accum(0) [ reduce (n) for n in l ][-1] # 6 You can also do Cartesian joins, though I rarely see these. There are a couple of problems I've run into. The first is that Python's libraries are just not engineered with the idea of using list comprehensions in this way - folding is as awkward as it looks above, exceptions thrown in the list comprehension functions will terminate the comprehension, many python functions alter state and return None rather than a useful output, and so on. The second is that they're amazingly uncomposable, syntactically: l.map(addOne).filter(isOdd).reduce(accum(0)) is what I'd write in Scala, which is extremely tractable. In comparison, here's the equivalent in python: [ reduce(nr) for nr in [ nf for nf in [ addOne(nm) for nm in l ] if isOdd(nf) ] ][-1] You note that I've had to rename the elements, because they "leak" to their surrounding comprehension - this can be quite confusing the first time you see it. Also these are fairly trivial comprehensions, which call functions rather than evaluate expressions in-place - this is well-supported and very idiomatic, but makes comprehension composition much harder. I find Python's comprehension style very convenient, and I'm sure you could produce an excellent theoretical abstraction over it, but if you're coming at it from the point of view of wanting them to be map/reduce or something equally reasonable-about, you're going to be disappointed. Python isn't an object-oriented language, and isn't a functional language - the more I use it the more I think it's something akin to a collection-oriented language. Maybe that's just the way I use it. :) [0] and also set comprehensions, dict comprehensions, and generator (lazy list) comprehensions, which are wonderful but exacerbate both the problems I talk about.
- 14y ago

fauigerzigerk 14y ago

I guess it all depends on whether or not you think that pure functional programming makes sense as a general approach to programming. Pure functional or not is a very fundamental choice that influences all other features of a programming language. So I don't think it makes a whole lot of sense to compare Haskell to Go feature by feature. Anyway, I agree that there is no reason why Haskell should be confined to the academic space at all. Actually I think the whole "right tool for the job" mantra is largely misplaced when it comes to Turing complete languages (apart from _very_ low level systems programming).