6 ms·

I don't think the library situation is nearly as bad as some people--not necessarily the author of this presentation--make out. For one, Haskell actually has a

by tikhonj 14y ago

I don't think the library situation is nearly as bad as some people--not necessarily the author of this presentation--make out. For one, Haskell actually has a pretty good and growing collection of libraries, probably disproportionate to the language's popularity. Web development, in particular, is well represented: there are several competing web frameworks; Yesod even has commercial backing now. Haskell even has some libraries that are not well reproduced in other languages like QuickCheck and Parsec. I've also been looking at sbv lately, which seems rather more convenient than other languages' alternatives. Additionally, libraries aren't the only thing that matters. In fact, most libraries are pretty trivial. I remember seeing a presentation by Brian O'Sullivan online about his experiences with using Haskell at a startup. One point that really stood out to me was about libraries: sure, some libraries (like JSON parsing, I believe) were missing; however, it only took him something like a couple of days to write it from scratch. Those days are easily overshadowed by Haskell's core advantages. I would much rather spend a couple of days writing a new library than trying to track down a bug Haskell's type system would have caught. The beauty of this system is also that each library only needs to be written once and can then be reused, making the world better for everyone. Now, there are some other issues with Haskell. Cabal really is a big one. I just spent quite a while fighting cabal, and I'm not even sure how I won in the end :P. Happily, I believe people are working on addressing the cabal issue. I'm sure there are other annoyances besides. But no language is entirely free of annoyances. Considering everything, I really do think Haskell is a good choice for a very wide range of programming problems, especially in a startup setting.

Argorak 14y ago
I find the linked slideset uninteresting, as it misses the speakers words - its just a collection of positive and negative words. Still, I want to reply to your comment, even if my reply is bit harsh, but Haskell always makes me a bit bitter: First of all, I played with some web frameworks in Haskell and didn't like them at all: the yesod community had a very dismissive tone towards people that didn't want to use what they perceived as "standard" and Snap is well organized, but sometimes weirdly implemented around the corners (WAT? The templating library also serves static files?). I would love to use any of them, but they are still not fit to build ecosystems like Django, Rails or Spring. Its nice that you picked the JSON library (by Brian?) as an example for a lib that can be written in "a few day". `aeson` is a great library. Its just not something that someone without detailed Haskell knowledge can write in a few days. It requires good knowledge of Haskell, especially things like the GHC.Generics library and Template Haskell (Hint: GHC.Generics is not very well documented for practical uses as well, the documentation spares you of the hard cases). I found that if you go away from those 'core' libraries, quality drops sharply. Giving just one example may be unfair, but I do it anyways: the readline bindings (haskeline) didn't build on OS X for 2 major releases straight. Also 0.1 and 0.2 seem to be very common version numbers on hackage and most documentation boils down to type descriptions. For loves sake, I couldn't find a good and proper tutorial working with bidirectional streams (think websockets) and asking a GHC committer ended in "well, we're still not sure what the best abstraction for this is, theres multiple competing" and someone on the Haskell User Group Berlin said "well, its not such an easy problem, but it will be solved in a year or so". In Ruby, thats implemented in an hour (safe and sound using libraries, with proper abstractions), today. Yes, I honestly think that the library situation is bad - its not the lack of libraries, its the number of half-hearted libraries vs. the real good ones. Also: Pro-active teaching, like producing screencasts and tutorials is sadly not very common in the Haskell community as well (weirdly, this is spotty: haskell-cafe, Real World Haskell and Learn you a Haskell are shining examples of how things should be, also in other communities). I am surprised by how much the Haskell community always says "type system" first, but seems to put all other practical considerations on the backseat. Also, it is common to just dismiss concerns without addressing them. That said, I still love Haskell and enjoy developing in it when things are working smoothly, I just wished that the community were more receptive and less dismissive to actual problems of people that are not as deep inside the language as people spending every evening on it.
- davidw 14y ago
  > Also, it is common to just dismiss concerns without addressing them. That's human nature. I used to put a lot of effort into Tcl, including revamping John Ousterhout's book: http://journal.dedasys.com/2009/09/15/tcl-and-the-tk-toolkit-2nd-edition http://journal.dedasys.com/2009/09/15/tcl-and-the-tk-toolkit... But Tcl became increasingly untenable commercially, and a number of years ago I jumped into Ruby on Rails quite enthusiastically. It does things mostly the 'right' way in my opinion. However, while I like it, it's not "mine" in the way Tcl was, and I stepped back and started looking at everything in a more critical, but also more open way and have been a lot more inclined to call a spade a spade, even with the languages I like: http://news.ycombinator.com/item?id=4716838 http://news.ycombinator.com/item?id=4716838 http://news.ycombinator.com/item?id=4716890 http://news.ycombinator.com/item?id=4716890 But coming back to it, that attitude of "if Tcl doesn't do that, it doesn't really matter, and maybe not doing that is a good thing anyway" is prevalent in language flame warriors of all stripes, and, in my opinion is something to be avoided: if you can't look at yourself honestly, you won't improve.
  - Argorak 14y ago
    Thats true, but I rarely found the tension between the brute capabilities of the language, the number of geniuses working on the language and the failure at communicating about it as big as in the Haskell community. Its full of gems waiting to be used, but sometimes I have the impression that many practical problems are seen as downright mundane in some circles there. I really hope for a second coming in that regard. Amen to your opinion about language flame wars (and this wasn't intended as a flame).
    - ky3 14y ago
      "Practical problems" is one of those expressions that mean different things to different people, emphatically so in the Haskell community. The response is that far from treating the problems as mundane, the community actually sees the problems for what they are and are taking steps to solve them. Shit's hard! Dan Doel elaborates on this: http://www.reddit.com/r/haskell/comments/wn882/clarification_classy_prelude/c5f1akv http://www.reddit.com/r/haskell/comments/wn882/clarification... I find the whole, 'we're the people actually getting shit done,' line quite amusing. Because the recurring theme of Haskell (and its family) is that those LaTeX paper/pseudocode writing academics keep inventing language features and abstractions that are better for getting shit done than the people just settling for something ad-hoc so that they can get shit done.
eklerks 14y ago
I used haskell in different startups and is was most of the times a good choice. I have written a dozen of (embedded) domain specific languages to support rapid development. This is quite easy in haskell. Parsec helps with writing parsers for your DSL. What I saw, was that the amount of tests could be reduced, when using haskell. The type of testing is also somewhat different. You don't have to test for type errors. QuickCheck let you test mathematical properties (in an empiric way). The FFI compensates for the missing libraries, but is a bit difficult to use. But the biggest reason of using haskell for me, was the way it handles concurrency and the high abstraction level. This enables you to write distributed applications in a more convenient way than usual. If you working in a web start up, you hit somewhere a point, where you need to think about this stuff. Besides Yesod, Snap is also a interesting choice, because of it's simplicity. I enjoy using this language. I would choose it anytime. It made me a better programmer.
- davidw 14y ago
  > But the biggest reason of using haskell for me, was the way it handles concurrency and the high abstraction level. Anyone care to point to something online that spells these out in (simple) details for someone who knows next to nothing about Haskell?
  - danieldk 14y ago
    Simon Peyton Jones had a talk with a very nice overview of concurrency in Haskell. He is a very good presenter as well :). http://www.youtube.com/watch?v=hlyQjK1qjw8 http://www.youtube.com/watch?v=hlyQjK1qjw8
  - eklerks 14y ago
    There are a lot of concurrency related libraries implementing all kind of abstractions. Distributed computation is upcoming. There is an overview here: http://www.haskell.org/haskellwiki/Applications_and_libraries/Concurrency_and_parallelism http://www.haskell.org/haskellwiki/Applications_and_librarie...
  - padrian2ss 14y ago
    one big kick, since haskell is pure functional you don't have state (okay, in terms that imperative programmer use that term) and all data are immutable.
papsosouid 14y ago
I'm using haskell for web development, although we're not the typical faddish startup.ly. I agree that the library thing is a non-issue. I've had absolutely no cases of wanting a library to do X, and it not being there. Quite the contrary the only library issue I've had so far is "there's 3 libraries for X, which one is the best?".

by tikhonj 14y ago

Argorak 14y ago

I find the linked slideset uninteresting, as it misses the speakers words - its just a collection of positive and negative words. Still, I want to reply to your comment, even if my reply is bit harsh, but Haskell always makes me a bit bitter: First of all, I played with some web frameworks in Haskell and didn't like them at all: the yesod community had a very dismissive tone towards people that didn't want to use what they perceived as "standard" and Snap is well organized, but sometimes weirdly implemented around the corners (WAT? The templating library also serves static files?). I would love to use any of them, but they are still not fit to build ecosystems like Django, Rails or Spring. Its nice that you picked the JSON library (by Brian?) as an example for a lib that can be written in "a few day". `aeson` is a great library. Its just not something that someone without detailed Haskell knowledge can write in a few days. It requires good knowledge of Haskell, especially things like the GHC.Generics library and Template Haskell (Hint: GHC.Generics is not very well documented for practical uses as well, the documentation spares you of the hard cases). I found that if you go away from those 'core' libraries, quality drops sharply. Giving just one example may be unfair, but I do it anyways: the readline bindings (haskeline) didn't build on OS X for 2 major releases straight. Also 0.1 and 0.2 seem to be very common version numbers on hackage and most documentation boils down to type descriptions. For loves sake, I couldn't find a good and proper tutorial working with bidirectional streams (think websockets) and asking a GHC committer ended in "well, we're still not sure what the best abstraction for this is, theres multiple competing" and someone on the Haskell User Group Berlin said "well, its not such an easy problem, but it will be solved in a year or so". In Ruby, thats implemented in an hour (safe and sound using libraries, with proper abstractions), today. Yes, I honestly think that the library situation is bad - its not the lack of libraries, its the number of half-hearted libraries vs. the real good ones. Also: Pro-active teaching, like producing screencasts and tutorials is sadly not very common in the Haskell community as well (weirdly, this is spotty: haskell-cafe, Real World Haskell and Learn you a Haskell are shining examples of how things should be, also in other communities). I am surprised by how much the Haskell community always says "type system" first, but seems to put all other practical considerations on the backseat. Also, it is common to just dismiss concerns without addressing them. That said, I still love Haskell and enjoy developing in it when things are working smoothly, I just wished that the community were more receptive and less dismissive to actual problems of people that are not as deep inside the language as people spending every evening on it.

davidw 14y ago
> Also, it is common to just dismiss concerns without addressing them. That's human nature. I used to put a lot of effort into Tcl, including revamping John Ousterhout's book: http://journal.dedasys.com/2009/09/15/tcl-and-the-tk-toolkit-2nd-edition http://journal.dedasys.com/2009/09/15/tcl-and-the-tk-toolkit... But Tcl became increasingly untenable commercially, and a number of years ago I jumped into Ruby on Rails quite enthusiastically. It does things mostly the 'right' way in my opinion. However, while I like it, it's not "mine" in the way Tcl was, and I stepped back and started looking at everything in a more critical, but also more open way and have been a lot more inclined to call a spade a spade, even with the languages I like: http://news.ycombinator.com/item?id=4716838 http://news.ycombinator.com/item?id=4716838 http://news.ycombinator.com/item?id=4716890 http://news.ycombinator.com/item?id=4716890 But coming back to it, that attitude of "if Tcl doesn't do that, it doesn't really matter, and maybe not doing that is a good thing anyway" is prevalent in language flame warriors of all stripes, and, in my opinion is something to be avoided: if you can't look at yourself honestly, you won't improve.
- Argorak 14y ago
  Thats true, but I rarely found the tension between the brute capabilities of the language, the number of geniuses working on the language and the failure at communicating about it as big as in the Haskell community. Its full of gems waiting to be used, but sometimes I have the impression that many practical problems are seen as downright mundane in some circles there. I really hope for a second coming in that regard. Amen to your opinion about language flame wars (and this wasn't intended as a flame).
  - ky3 14y ago
    "Practical problems" is one of those expressions that mean different things to different people, emphatically so in the Haskell community. The response is that far from treating the problems as mundane, the community actually sees the problems for what they are and are taking steps to solve them. Shit's hard! Dan Doel elaborates on this: http://www.reddit.com/r/haskell/comments/wn882/clarification_classy_prelude/c5f1akv http://www.reddit.com/r/haskell/comments/wn882/clarification... I find the whole, 'we're the people actually getting shit done,' line quite amusing. Because the recurring theme of Haskell (and its family) is that those LaTeX paper/pseudocode writing academics keep inventing language features and abstractions that are better for getting shit done than the people just settling for something ad-hoc so that they can get shit done.

eklerks 14y ago

I used haskell in different startups and is was most of the times a good choice. I have written a dozen of (embedded) domain specific languages to support rapid development. This is quite easy in haskell. Parsec helps with writing parsers for your DSL. What I saw, was that the amount of tests could be reduced, when using haskell. The type of testing is also somewhat different. You don't have to test for type errors. QuickCheck let you test mathematical properties (in an empiric way). The FFI compensates for the missing libraries, but is a bit difficult to use. But the biggest reason of using haskell for me, was the way it handles concurrency and the high abstraction level. This enables you to write distributed applications in a more convenient way than usual. If you working in a web start up, you hit somewhere a point, where you need to think about this stuff. Besides Yesod, Snap is also a interesting choice, because of it's simplicity. I enjoy using this language. I would choose it anytime. It made me a better programmer.

davidw 14y ago
> But the biggest reason of using haskell for me, was the way it handles concurrency and the high abstraction level. Anyone care to point to something online that spells these out in (simple) details for someone who knows next to nothing about Haskell?
- danieldk 14y ago
  Simon Peyton Jones had a talk with a very nice overview of concurrency in Haskell. He is a very good presenter as well :). http://www.youtube.com/watch?v=hlyQjK1qjw8 http://www.youtube.com/watch?v=hlyQjK1qjw8
- eklerks 14y ago
  There are a lot of concurrency related libraries implementing all kind of abstractions. Distributed computation is upcoming. There is an overview here: http://www.haskell.org/haskellwiki/Applications_and_libraries/Concurrency_and_parallelism http://www.haskell.org/haskellwiki/Applications_and_librarie...
- padrian2ss 14y ago
  one big kick, since haskell is pure functional you don't have state (okay, in terms that imperative programmer use that term) and all data are immutable.

papsosouid 14y ago

I'm using haskell for web development, although we're not the typical faddish startup.ly. I agree that the library thing is a non-issue. I've had absolutely no cases of wanting a library to do X, and it not being there. Quite the contrary the only library issue I've had so far is "there's 3 libraries for X, which one is the best?".