7 ms·
What makes you say Haskell is an abomination?
by farresito 9y ago
What makes you say Haskell is an abomination?
- dmitriid 9y agoShort version: You need a PhD in type theory to get anywhere. Basically every obscure overly complicated concept that Haskell throws at you (all the while pretending to be the only true FP language out there) can be explained in 5 to 10 lines of Javascript: https://github.com/hemanth/functional-programming-jargon https://github.com/hemanth/functional-programming-jargon Compare and contrast. - Monad explained in Javascript: https://github.com/hemanth/functional-programming-jargon#monad https://github.com/hemanth/functional-programming-jargon#mon... - Timeline (sic!) of monad tutorials for Haskell: https://wiki.haskell.org/Monad_tutorials_timeline https://wiki.haskell.org/Monad_tutorials_timeline The worst crime against humanity though is Haskell crap seeping into other languages (such as ramda, for instance: http://ramdajs.com http://ramdajs.com)
- willtim 9y agoYou certainly would need a PhD to fully understand Monads from that small JavaScript snippet. The Haskell link you gave gives Phil Wadler's original paper as the first link. It is easy to read, explains everything beautifully and full of many examples. Learn some basic Haskell for no other reason than to read seminal papers such as these. To favour some random JavaScript hacker on the internet and steer others away from the original work is anti-intellectualism.
- dmitriid 9y agoAh, here comes the condescending tone I've so come to appreciate from the Haskell programmers. "Go and read", "anti-intellectualism".
- willtim 9y agoYou are misquoting me. I said steering others away from the original source of work to an interior source (incomplete at best) is anti-intellectualism. I do not mean to be condescending, but I feel very strongly about this.
- dmitriid 9y agoIn order not to copy-paste, I'll link to my reply in another thread: https://news.ycombinator.com/item?id=14890766 https://news.ycombinator.com/item?id=14890766
- eastWestMath 9y agoWadler's paper is an excellent piece of exposition that's us at the level of an upper-year undergraduate textbook. There's nothing condescending about referring a professional to a relevant paper in their discipline, but it is troubling when a professional won't even read over a paper.
- KirinDave 9y agoWait... you're tone policing haskell users after referring to even the _adaptation_ of functional techniques as a "crime against humanity?" Please rethink this approach. It is a bad approach. It fails to capture (what I think you) your argument (is) and antagonizes people needlessly. And quite frankly, a lot of people are being VERY nice by not following in the tradition of absolutely burying javascript for its nonsensical primitive type semantics.
- tome 9y ago> Basically every obscure overly complicated concept that Haskell throws at you (all the while pretending to be the only true FP language out there) can be explained in 5 to 10 lines of JavaScript So presumably the same concepts can be explained in 5 to 10 lines of Haskell too. I think you're confusing the refinement and polishing of ideas that's taken place in Haskell over the last two decades with the succinct presentation of those ideas once they've been worked out.
- dmitriid 9y agoBut they can't, can they. Or we wouldn't have the bazillion monad tutorials. The funny thing, this is the trouble that plagues other Haskell-inspired work (such as Purescript)
- tome 9y agoIt's obvious that the concept of monad can either be explained in 5-10 lines in both JavaScript and Haskell, or neither. Which are you claiming?
- dmitriid 9y agoIt's not obvious. I'm claiming that: - the concept of monad can be explained in 5-10 lines in Javascript (demonstrable) - the concept of a monad requires multiple years and tens of tutorials in Haskell (also demonstrable)
- mrkgnao 9y agoDemonstrate a pair of tutorials aimed at the same level of reader, one in JS, and one in Haskell, where you end up with a better understanding of the idea of a monad reading the former (as opposed to the implementation of the Monad instance for a list).
- dmitriid 9y agoTIL there's some "idea of a monad". Basically this is (in my mind) what's wrong with Haskell: it's overly concerned with the Platonic ideal. Meanwhile that one page on jargon has shown me that I effortlessly implement any and all of those things daily (and understanding what I'm doing) without the need to understand "an idea". I just use the tool that solves the problem. If someone insists on calling this "monadic composition", or "lifting over typeclasses", or "zygohistomorphic prepromorphisms", so be it.
- mrkgnao 9y ago> You need a PhD in type theory to get anywhere. That is extremely false. Haskell isn't even a good playground for academic type theory -- you'd want Agda etc. for that. The development of the language over the last few years has been characterized by pragmatism and a focus on backwards-compatibility, which is why you can take code from something like ten years ago and have it run without issues on modern versions of the Haskell compiler with little to no modifications. (Let's not talk about how long code written in "modern" JS lasts.) And I'd really like to see type class constraint resolution with functional dependencies, or Hindley-Milner type checking, or something of that sort implemented in "5-10 lines" of JS. "There he goes again with his mumbo-jumbo," you say. That's right, you don't need to care about those things to write Haskell. What you meant is implementations of typeclasses ("interfaces") like Monad, Functor, and so on: they don't take much more code in Haskell. Array.prototype.chain = function (f) { return this.reduce((acc, it) => acc.concat(f(it)), []) } instance Monad [] where xs >>= f = concat (map f xs) return = pure And we didn't even have to go the "this" route! Notice that your 5 - 10 lines of JS don't let you write code that works in any monad, whereas I can easily write whenM :: Monad m => m Bool -> m () -> m () whenM cond action = do condition <- cond if cond then action else pure () In Elm, you'd have List.whenM, Array.whenM, Maybe.whenM, ... or a straight-up false type signature like their Eq ones, and in JS, a bunch of prototype methods with no unifying threads. -- As for an example of why I think Haskell has the right ideas (few of us will say it's the "best language evar"): I'd really like to see a JS version of the Servant library, which takes an API spec for a server and actually generates a fully functional server from that. Here's a description: https://news.ycombinator.com/item?id=14149200 https://news.ycombinator.com/item?id=14149200 Does this strike you as idle theoretical self-enjoyment?
- dmitriid 9y ago> This is extremely false [referring to "You need a PhD in type theory to get anywhere."] almost immediately followed by > And I'd really like to see type class constraint resolution, or Hindley-Milner type checking You don't even see the irony in that, do you? > they don't take much more code in Haskell: riiight. I won't even go into the number of things that need to be explained there before you even start explaining what the code does.