I can write libraries in COBOL and then proceed to claim "these libraries only exist in COBOL, therefore COBOL is better than other languages", which is to me exactly what this post reads like.
That's pretty ungenerous of you. There are factual differences between languages, and Ed's list is full of illuminating examples. You've wandered into a conversation on /r/haskell between Haskell users about why they like Haskell. It's insane to expect them to be less excited or biased.
I'm not complaining about /r/haskell posters making pro-Haskell posts. I'm guilty of similar things.
I'm just not sure what it's doing on the HN front page, and I find the contents of the post lacking in terms of convincing outsiders into a favourable opinion on the language.
There's nothing wrong with such a comment on /r/haskell, but I think it's out of place here. I realize the fact that it is voted up to the front page proves that many people think otherwise, but when I last checked, people were allowed to voice contrary opinions on the Internet.
I haven't seen anyone trying to prevent you from voicing a contrary opinion, only people politely trying to explain to you that they feel you are missing an essential point of understanding. (OK, I was a bit snarky, but it was on point)
No, you've exactly missed the point of the thread and of Kmett's reply. Every single thing he lists (except perhaps the containers library) uses some unique features of Haskell, or is uniquely well done in their Haskell implementations. Read it again!
Maybe, but the response doesn't really explain for most of the cases why that is the case or why we should care for anyone that doesn't already use Haskell.
That's fine, but as another commenter points out, while that's perfectly fine on /r/haskell, it makes it a poorer post here without additional commentary as to why these things matters.
Yes, if we only look at things with a naive high-level generalization then we can force anything to be constrained by our existing world-view. However, as it turns out, there are some details worth paying attention to here.
But Edward Kmett is not the author of the Reddit thread! You make it sound like it's been staged to showcase his stuff. He can certainly point to the (awesome) libraries he has built in answer. The original question was
Besides features of the haskell language itself, I was wondering if there were any libraries in haskell that stood out as being unique--not a sinatra-like web interface for example. Something like erlang's mnesia or rails for ruby, maybe, or hazelcast for java or any frameworks (for web programming or whatever), that were truly a step above comparable libraries or don't even have a non-Haskell equivalent. Something that once you use it, you hate not using it in other projects.
Perhaps his "argument" doesn't make sense because it isn't an argument, it's a list of examples. Of course, insinuating that you don't trust the comment because the author points to his own libraries is a golden example of an ad-hominem fallacy, but in order for such fallacies to be relevant, this would have to be a debate, and it isn't, it's just you aimlessly complaining.
If you wanted to make it into a meaningful debate, perhaps you could furnish us with a non-Haskell example of:
- A differentiation library that avoids the perturbation problem at compilation time,
- A library for defining compositional uniform access across structured data types,
- A dependency injection framework with an algebraic basis,
- A speculative evaluation library that can safely discard running processes,
- A name binding library free of ordering effects
While I'm quite sure with some searching you could find one or two of these, most of them depend on the strong safety guarantee provided by Haskell isolating side-effectful processing in the I/O monad. Other languages can do this (or have other ways to do this) but none are popular enough to have such a wealth of libraries as to have these problems already solved. Unless, you know, I'm factually off-base. I look forward to seeing what you have to show us.
That's the first time I noticed that mtl was a DI library. Transformer classes are just such a nice concept in and of themselves that I never found value in mapping the concept back to something like DI. I'm definitely using that going forward.