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.
Before my rant: I think the Haskell community is incredibly nice. It is the most helpful and brilliant group of people I have interacted with in my life.
Rant:
Yes, I have spent a while getting up to speed with Haskell. I think it has definitely made me a better programmer to learn, but I really don't like how quickly everything seems to go in the deep end.
The need for the 'right' abstraction and 'good enough' stuff like Cabal really irritates me. Cabal is especially hurtful to the community growing. I think there needs to be a much bigger investment in Nix, that is an absolutely amazing project that barely gets the attention it deserves.
Another thing that really makes me not want to invest time in Haskell is how quickly code starts to depend on language addons. I think that idea can be done well, like in Racket, but for Haskell it really seems like a scary way of bandaging the standard.
What do you mean by bandaging the standard? And why are extensions scary?
In general none of the extensions change the behaviour of valid "standard haskell" (beyond adding a small handfull of new keywords, rendering those words illegal as variable names). So calling it "bandaging the standard" seems a bit harsh/odd.
I think extensions are a nice way of keeping the language moving forward without being slowed down by the standardisation process. The standard can then catch up in its own time.
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:
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.
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).
"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!
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.
I am aware of that sentiment. I didn't want to imply that all those abstractions don't get shit done. A lot of them are very much worth learning and solve many problems. So much for the "useful" part.
But what use is a powerful abstraction without usage examples and guidance to use it? And what use is an abstraction that is just not there yet? Or if it is hard to learn the correct abstractions for certain problems, because there is no guidance about that? The lack of examples in many Haskell libraries and projects is striking and I usually resort to working through similar libraries to see how they are doing it.
My problem are not the paper-writing academics, but those that should do the footwork and make their knowledge and brightness accessible to others.
As always, its a combination of many factors.
Also, don't overinterpret words: I never said that Haskell is not useful for getting things done (some things just work tremendously well!). Its just that guidance on practical problems is hard to come by, even if the abstractions fit. Thats why I think that Real World Haskell is such a strong book, because it actually provides that.
(This must be the comeuppance for talking abstractly about abstractions. Heh.)
For starters I shan't cop-out and claim Haskell is primarily a research vehicle. So it's succeeding in some sense. We'll live.
So here's my take: Most people yield defeat at monads. And then the few that survive find that they have to face iteratees and co. Rage and tears don't even begin to express it.
You're right, there's no guidance about iteratees. Material on this issue, not unlike monads; not unlike space complexity tradeoffs in lazy evaluation; hell, not unlike almost everything about haskell, is all over the place. And that sucks balls.
Do I have a solution? I'd counter, isn't this the price to pay for being on the bleeding edge? And I'd contribute this: there used to be a time when people felt a greater affordance to try anything half-baked, fiddle with it here and there, and BBS to others about it. Over the years there's this expectation creep that everything has to be perfect like an immaculate birth. Perfect! With guidance included!
I want to say that this is due to the decline of leisure time. But that can't be the whole story.
Hrm. I was reading a book about copy writing recently, and one of the takeaways was that you really want to be selling a cure, rather than a prevention.
Meaning, people will pay a lot and care a lot about curing some particular disease, but preventing it... they might pay something for it, but it's probably not really on their radar.
Haskell, with all the fancy CS stuff, is selling prevention, in some sense. "We promise that your code will somehow be better"... well ok, but that doesn't really sell me. I'm being told to eat my vegetables rather than being shown a tasty steak. Compare and contrast with Rails when it came out, which showed you how you could write code that was 1) more organized than PHP, but 2) not as bureaucratic as Java. Cool stuff!
Reality is not black and white, but perhaps there's a grain of truth in there? Perhaps Haskell people could do a better job of showing how the CS stuff helps with real problems? I can't really say as it's simply not on my radar all that much, so they could well be screaming about it from the rooftops and I wouldn't have heard too much.
Yes, thats a catch 22, but one that every community has and it is hard to overcome. I wouldn't have written my reply if I didn't think that the parent wasn't overly positive and brushing away a few problems.
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.
Haskeline is not bindings to readline or editline, but pure haskell. It does use libiconv, which is a chamber of horrors on OS X, and the source of your problems. But if you were using ghci you were using haskeline, so it wasn't that it couldn't be built. It is an extremely high quality library -- surprisingly, or perhaps not surprisingly, considering that it was written by a mathematician.
Sorry, you are right, libiconv was the problem. Still doesn't change that it couldn't be built on OS X for a long while (0.5 to 0.6 as far as I remember, 0.7 fixed things).
No, I didn't use ghci. I just tried to install darcs among other things.
>but sometimes weirdly implemented around the corners (WAT? The templating library also serves static files?).
No it doesn't. There's a similar high level API, but that's it. Serving static files is part of snap-core, and done with serveDirectory/serveFile. Templates are part of the higher level snap module, and can be served in a similar style using heistServe.
>I would love to use any of them, but they are still not fit to build ecosystems like Django, Rails or Spring.
I'm not sure what you mean by that. Not fit to build ecosystems as in, have 3rd parties contribute "components" or something of that nature that people can optionally use? Because snap has that, they are called snaplets, and despite snap being quite new, there's already a budding little ecosystem there.
>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 is simply not true. The haskell community is very heavily focused on addressing practical concerns, cabal is under constant work and discussion, and the developers are seeking funding so they can focus on it full time. A new extensible record module was released just this week to address the issues people have with haskell records. It seems incredibly odd to keep seeing people claim that the community ignores feedback when so much of the community's goings-on are focused entirely on addressing that feedback.
>No it doesn't. There's a similar high level API, but that's it. Serving static files is part of snap-core, and done with serveDirectory/serveFile. Templates are part of the higher level snap module, and can be served in a similar style using heistServe.
It isn't "not strictly static", it literally has absolutely nothing at all to do with static content in any way. The heist snaplet adds a default "if nothing else matches, look for a template" route if you use the initialization function that says "sets up routes for all the templates". If you don't want that, then use the initialization function that doesn't do so (heistInit' which is right below heistInit in the docs, and linked to by the doc string of heistInit).
That seems like a really odd thing to try to characterize as "weirdly implemented".
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.