3 ms·

You can't define the interface in either language. Implementations of Functor consist, in part, of type-level functions. In Haskell terms, these are "higher-ki

You can't define the interface in either language. Implementations of Functor consist, in part, of type-level functions. In Haskell terms, these are "higher-kinded types". The standard example is the list type "[]" which, as a type-level function, takes an element type and gives back the type of lists whose elements are drawn from that element type. In Java and F#, the only way to talk about the List type is in its fully applied context, where you've attached the element type. So maybe you've got "List<Int>", or you've got "List<String>" or you may have a generic "List<A>". What you don't have is the type-level function that's not been applied to anything. So there's no equivalent to the Haskell Functor implementation: instance Functor [] where fmap _ [] = [] fmap f (x:xs) = f x : fmap f xs This is barely half the story. What makes this useful in Haskell is the typeclass overloading, which makes it effortless to write functions that abstract over arbitrary Functors, and use "fmap" multiple times locally for different Functor instances, letting the type system figure out what implementation is needed to map over the particular type you're working with. And in such abstract code, where you may know very little about the Functor instance you're working with, it's extremely important that they all be absolutely law-abiding: in many cases, the laws are all you have to work with. These two features, higher-kinding and typeclass polymorphism, make it worth talking about Functors, and I don't think you can appreciate Functors in Haskell without seeing the interaction of these features and just how much it impacts the code style of the average Haskeller.

newswasboring 6y ago
Man nothing against your dedication of explaining this to me, but everytime I talk about haskell it feels like a jargon salad. I very, very humbly ask you, so what? Like you wrote a short essay on this, and I still can't grok even in the slightest why this matters. Every other language I talk about, can at least tell me why certain feature is helpful, even if I don't get it. What I got from this is this allows abstracting mapping over types. But what does that give you? Think about it this way. If the primary importance of something is only apparent from the big picture how is a user supposed to decide whether to use it or not? The big picture is rarely available to most programmers.
- momentoftop 6y ago
  > Think about it this way. If the primary importance of something is only apparent from the big picture how is a user supposed to decide whether to use it or not? The big picture is rarely available to most programmers. Maybe a user isn't supposed to. I believe that's the premise of Paul Graham's Blub Paradox [1]. I certainly didn't learn, say, Common Lisp, because I was doing a feature comparison. I had no idea what a lexical closure was at the time, and a couple of toy examples wouldn't have convinced me of their worth. I'd been programming quite happily without them for some time by then. [1] https://en.wikipedia.org/wiki/Blub_paradox#The_Blub_paradox https://en.wikipedia.org/wiki/Blub_paradox#The_Blub_paradox
  - newswasboring 6y ago
    That is an excellent point. Haskell is such a fundamental shift in thinking, perhaps the only way to learn real application is to make something with it. But I would still maintain every language at least has a highly simplistic example of why certain features work well. In fact, my curiosity reignited by this discussion, I found this video series[1] on youtube which somehow made is 100x more clear where Functors, Applicatives and Monads are to be used. The tree example is pretty abstract, but it helped me connect these features to my work. I still don't know how to get most use out of it, but I think I get the USP. Still have the question about how haskell is helping here, because I can write a hidden state changing function in Julia if I want. But one step at a time [1] https://www.youtube.com/watch?v=xCut-QT2cpI https://www.youtube.com/watch?v=xCut-QT2cpI

newswasboring 6y ago

Man nothing against your dedication of explaining this to me, but everytime I talk about haskell it feels like a jargon salad. I very, very humbly ask you, so what? Like you wrote a short essay on this, and I still can't grok even in the slightest why this matters. Every other language I talk about, can at least tell me why certain feature is helpful, even if I don't get it. What I got from this is this allows abstracting mapping over types. But what does that give you? Think about it this way. If the primary importance of something is only apparent from the big picture how is a user supposed to decide whether to use it or not? The big picture is rarely available to most programmers.

momentoftop 6y ago
> Think about it this way. If the primary importance of something is only apparent from the big picture how is a user supposed to decide whether to use it or not? The big picture is rarely available to most programmers. Maybe a user isn't supposed to. I believe that's the premise of Paul Graham's Blub Paradox [1]. I certainly didn't learn, say, Common Lisp, because I was doing a feature comparison. I had no idea what a lexical closure was at the time, and a couple of toy examples wouldn't have convinced me of their worth. I'd been programming quite happily without them for some time by then. [1] https://en.wikipedia.org/wiki/Blub_paradox#The_Blub_paradox https://en.wikipedia.org/wiki/Blub_paradox#The_Blub_paradox
- newswasboring 6y ago
  That is an excellent point. Haskell is such a fundamental shift in thinking, perhaps the only way to learn real application is to make something with it. But I would still maintain every language at least has a highly simplistic example of why certain features work well. In fact, my curiosity reignited by this discussion, I found this video series[1] on youtube which somehow made is 100x more clear where Functors, Applicatives and Monads are to be used. The tree example is pretty abstract, but it helped me connect these features to my work. I still don't know how to get most use out of it, but I think I get the USP. Still have the question about how haskell is helping here, because I can write a hidden state changing function in Julia if I want. But one step at a time [1] https://www.youtube.com/watch?v=xCut-QT2cpI https://www.youtube.com/watch?v=xCut-QT2cpI