5 ms·

To be honest I feel like the functor concept is too abstract and subtle to the point where it's probably not very useful in the context of programming. Worse..

To be honest I feel like the functor concept is too abstract and subtle to the point where it's probably not very useful in the context of programming. Worse... their usage in programming languages is very unlike how homomorphisms are typically used in their usual context, so appealing to the math seems like its just confusing learners without payoff. To give an analogy... it feels like trying to explain the chain rule by explaining pullbacks between tangent spaces. Not technically wrong, but now they're confused and asking questions whose answers wont help them.

siraben 5y ago
Of course, the chain rule explained via differential topology is simply functoriality! IME, category theory was much more valuable in differential topology in helping solidify why the structures and their compositional properties make sense. You get to work with several, honest-to-god categories and functors between them, especially when tangent bundles come into the mix. Now go to programming, there's really only one category at play, and I'm not sure how worthwhile it is to apply a (more contrived) version of CT that only has endofunctors and being cartesian closed.
- chobytes 5y ago
  Haha, I feel like thats how I started to get CT concepts too. Topology and geometry really feel like the "natural" context for those ideas. For programming... I feel like they're basically trying to do logic in a roundabout way. I suspect that (finite) model theory might be more useful for such applications if they really want theory.
the_af 5y ago
> it's probably not very useful in the context of programming This puzzles me. It turns out it's very useful in the context of programming in practice (i.e. Haskell programmers use it and find it useful), so what do you mean? I don't know CT so I wouldn't know how well it maps (pun intended) with the Math concept, but regardless, whatever abstraction is there in Haskell that programmers call "functors" is tremendously useful.
- loopz 5y ago
  CT may be appropriate to further evolve Haskell as a language, but for programming implementations; mathematical categories aren't directly useful. There Haskell is more like any other programming language, just that it's FP.
  - the_af 5y ago
    I'm not debating that; instead, I'm arguing functors are immediately useful in languages like Haskell. Don't know enough about CT to debate that point.
    - loopz 5y ago
      They are. Abstractions like functors makes the language more similar to other structured languages. Otherwise, the same would've needed explicit recursion all over the place, which is more error-prone.
- creata 5y ago
  `Functor` instances need to exist: they're obviously useful. You'll see a million `map` methods in every programming language.[0] What you won't see is a unification of them all under one interface. And the point, in my view, is that this unification doesn't really buy you much. I can't think of a single algorithm that starts with "let T be a mappable type". [0]: https://doc.rust-lang.org/std/?search=map https://doc.rust-lang.org/std/?search=map
  - rssoconnor 5y ago
    I mostly agree with what you are getting at here. However occasionally it is useful to abstract over all Functor or all Monads, etc. For example, when using the Van Laarhoven free monad[0] implementation, I'll quantify over all monads. While, there is a simple data type definition for free monads[1], it suffers from a well-known issue that the bind operation has quadratic complexity. The Van Laarhoven free monad circumvents this problem (at least in the common case where you are not trying to "execute" the intermediate monadic constructions). There are also continuation-based approaches for free monad implementations as well. The benefits of free monad are the typical ones described in "Data types à la carte" where you can, for example, instantiate your free monad in the IO monad for production, but use a pure monad instance for (parts of) your test harness. (Generic implementations of free monads and their operations is another example of quantifying over all Functors, but I'm assuming for the sake of argument that you'd prefer to repeat that boilerplate over and over again for all your specific free monad instances.) [0] http://r6.ca/blog/20140210T181244Z.html http://r6.ca/blog/20140210T181244Z.html [1] https://hackage.haskell.org/package/free-5.1.7/docs/Control-Monad-Free-Ap.html#t:Free https://hackage.haskell.org/package/free-5.1.7/docs/Control-... [2] http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCa...
creata 5y ago
> To be honest I feel like the functor concept is too abstract and subtle to the point where it's probably not very useful in the context of programming. I think it's a small convenience to have the programming language automatically derive `map` instances for you, but I think you're right for pretty much the same reason group theory's huge but monoid theory barely exists: the `Functor` typeclass is too simple to do anything interesting with it.

siraben 5y ago

Of course, the chain rule explained via differential topology is simply functoriality! IME, category theory was much more valuable in differential topology in helping solidify why the structures and their compositional properties make sense. You get to work with several, honest-to-god categories and functors between them, especially when tangent bundles come into the mix. Now go to programming, there's really only one category at play, and I'm not sure how worthwhile it is to apply a (more contrived) version of CT that only has endofunctors and being cartesian closed.

chobytes 5y ago
Haha, I feel like thats how I started to get CT concepts too. Topology and geometry really feel like the "natural" context for those ideas. For programming... I feel like they're basically trying to do logic in a roundabout way. I suspect that (finite) model theory might be more useful for such applications if they really want theory.

the_af 5y ago

> it's probably not very useful in the context of programming This puzzles me. It turns out it's very useful in the context of programming in practice (i.e. Haskell programmers use it and find it useful), so what do you mean? I don't know CT so I wouldn't know how well it maps (pun intended) with the Math concept, but regardless, whatever abstraction is there in Haskell that programmers call "functors" is tremendously useful.

loopz 5y ago
CT may be appropriate to further evolve Haskell as a language, but for programming implementations; mathematical categories aren't directly useful. There Haskell is more like any other programming language, just that it's FP.
- the_af 5y ago
  I'm not debating that; instead, I'm arguing functors are immediately useful in languages like Haskell. Don't know enough about CT to debate that point.
  - loopz 5y ago
    They are. Abstractions like functors makes the language more similar to other structured languages. Otherwise, the same would've needed explicit recursion all over the place, which is more error-prone.
creata 5y ago
`Functor` instances need to exist: they're obviously useful. You'll see a million `map` methods in every programming language.[0] What you won't see is a unification of them all under one interface. And the point, in my view, is that this unification doesn't really buy you much. I can't think of a single algorithm that starts with "let T be a mappable type". [0]: https://doc.rust-lang.org/std/?search=map https://doc.rust-lang.org/std/?search=map
- rssoconnor 5y ago
  I mostly agree with what you are getting at here. However occasionally it is useful to abstract over all Functor or all Monads, etc. For example, when using the Van Laarhoven free monad[0] implementation, I'll quantify over all monads. While, there is a simple data type definition for free monads[1], it suffers from a well-known issue that the bind operation has quadratic complexity. The Van Laarhoven free monad circumvents this problem (at least in the common case where you are not trying to "execute" the intermediate monadic constructions). There are also continuation-based approaches for free monad implementations as well. The benefits of free monad are the typical ones described in "Data types à la carte" where you can, for example, instantiate your free monad in the IO monad for production, but use a pure monad instance for (parts of) your test harness. (Generic implementations of free monads and their operations is another example of quantifying over all Functors, but I'm assuming for the sake of argument that you'd prefer to repeat that boilerplate over and over again for all your specific free monad instances.) [0] http://r6.ca/blog/20140210T181244Z.html http://r6.ca/blog/20140210T181244Z.html [1] https://hackage.haskell.org/package/free-5.1.7/docs/Control-Monad-Free-Ap.html#t:Free https://hackage.haskell.org/package/free-5.1.7/docs/Control-... [2] http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCa...

creata 5y ago

> To be honest I feel like the functor concept is too abstract and subtle to the point where it's probably not very useful in the context of programming. I think it's a small convenience to have the programming language automatically derive `map` instances for you, but I think you're right for pretty much the same reason group theory's huge but monoid theory barely exists: the `Functor` typeclass is too simple to do anything interesting with it.