5 ms·

To be fair, the term "map" comes from math [0], and so at the time these functions were created, there weren't other good naming choices. Mappable and Functor a

To be fair, the term "map" comes from math [0], and so at the time these functions were created, there weren't other good naming choices. Mappable and Functor are just about as opaque as each other if you don't know what mapping is. Though now that FP concepts are mainstream, I think there is a good case to offer some friendlier, more familiar names: Functor -> Mappable Applicative -> Pairable Monad -> Thenable [0]: https://softwareengineering.stackexchange.com/questions/203374/origin-of-common-list-processing-function-names https://softwareengineering.stackexchange.com/questions/2033...

jolux 6y ago
All I see here is weakening the descriptive power of those terms by replacing them with more common ones. It may look easier but I think it’s probably better not to carry in baggage from other languages that doesn’t quite fit.
whateveracct 6y ago
Giving descriptive names just harms intuition building in the long run. I've been writing Haskell for over 5 years and to this day when I see <$>, <*>, >>= in my code I don't substitute English words for them.
- kortex 6y ago
  Was about to complain you can't google them, but I tried it and it worked. Huh. I guess you can google symbols now, even traditionally escapey-ones. News to me. mentalModel.update(). The query `python @` fails pretty hard though.
  - rossng 6y ago
    For Haskell stuff, you can go one better and use Hoogle: https://hoogle.haskell.org/?hoogle=%28%3C%24%3E%29&scope=set%3Astackage https://hoogle.haskell.org/?hoogle=%28%3C%24%3E%29&scope=set...
  - whateveracct 6y ago
    I tend to just query the repl when I don't know a symbol. :info (>=>)
- j88439h84 6y ago
  > Giving descriptive names just harms intuition building in the long run. Citation needed
  - whateveracct 6y ago
    (In my experience)
    - whateveracct 6y ago
      Like seriously isn't it obvious that I'm stating my opinion? And that the citation is my personal professional Haskell experience? We're talking about intuition building here it's not like I'm gonna be able to Debate You with Hard Facts -__-
      - deleted 6y ago
        [deleted]
      - j88439h84 6y ago
        Yes it's clear that you're stating your opinion. I asked for supporting evidence because I'm not persuaded by your opinion since I have the opposite opinion.
        whateveracct 6y ago
        Well then I'll add: Calling Functor "Mappable" and Monad "Thenable" doesn't really add much to understanding. The best advice I ever got was that a Functor is `f` with a function `fmap :: (a -> b) -> f a -> f b` that follows its laws. Same goes for Monad. If it has the type signature & follows the laws, it's a Monad. That's the definition. No need for a cute analogy-oriented name like FlatMap-able or Then-able. Once you do that, you realize that the way to understand these things is to play type tetris with highly-generic type signatures. You stop needing English/real-world analogies to understand them and instead use the type system to understand the world (the reverse of using "nice" names) It works really well but it is a steep hill to climb. It helps to talk to others who have climbed it, and it helps to just grind on a project and use Monads without being an expert. You can go a long way just knowing how `do`, `traverse`/`mapM`, etc work and not having big Monad intuition.

jolux 6y ago

All I see here is weakening the descriptive power of those terms by replacing them with more common ones. It may look easier but I think it’s probably better not to carry in baggage from other languages that doesn’t quite fit.

whateveracct 6y ago

Giving descriptive names just harms intuition building in the long run. I've been writing Haskell for over 5 years and to this day when I see <$>, <*>, >>= in my code I don't substitute English words for them.

kortex 6y ago
Was about to complain you can't google them, but I tried it and it worked. Huh. I guess you can google symbols now, even traditionally escapey-ones. News to me. mentalModel.update(). The query `python @` fails pretty hard though.
- rossng 6y ago
  For Haskell stuff, you can go one better and use Hoogle: https://hoogle.haskell.org/?hoogle=%28%3C%24%3E%29&scope=set%3Astackage https://hoogle.haskell.org/?hoogle=%28%3C%24%3E%29&scope=set...
- whateveracct 6y ago
  I tend to just query the repl when I don't know a symbol. :info (>=>)
j88439h84 6y ago
> Giving descriptive names just harms intuition building in the long run. Citation needed
- whateveracct 6y ago
  (In my experience)
  - whateveracct 6y ago
    Like seriously isn't it obvious that I'm stating my opinion? And that the citation is my personal professional Haskell experience? We're talking about intuition building here it's not like I'm gonna be able to Debate You with Hard Facts -__-
    - deleted 6y ago
      [deleted]
    - j88439h84 6y ago
      Yes it's clear that you're stating your opinion. I asked for supporting evidence because I'm not persuaded by your opinion since I have the opposite opinion.
      - whateveracct 6y ago
        Well then I'll add: Calling Functor "Mappable" and Monad "Thenable" doesn't really add much to understanding. The best advice I ever got was that a Functor is `f` with a function `fmap :: (a -> b) -> f a -> f b` that follows its laws. Same goes for Monad. If it has the type signature & follows the laws, it's a Monad. That's the definition. No need for a cute analogy-oriented name like FlatMap-able or Then-able. Once you do that, you realize that the way to understand these things is to play type tetris with highly-generic type signatures. You stop needing English/real-world analogies to understand them and instead use the type system to understand the world (the reverse of using "nice" names) It works really well but it is a steep hill to climb. It helps to talk to others who have climbed it, and it helps to just grind on a project and use Monads without being an expert. You can go a long way just knowing how `do`, `traverse`/`mapM`, etc work and not having big Monad intuition.