Programming is also applied physics. But understanding the kinetic forces behind typing is no guide to improved programming.
To say that learning a field is useful is to say that knowing these abstractions is useful.
Much of Haskell's "category theory" is a reuse of terms. Replace Monoid by Appendable, Monad by Composable, Functor by Runnable, etc. and most programming languages are "category theory".
This says little about whether knowing the field of category theory will be useful to programming. Indeed, I think there's a good argument to say Haskell programming is much harmed by it.
If its authors hadnt used their knowledge of category theory, but rather named the abstractions in more ordinary terms, the language would be more useful to more people.
> Replace Monoid by Appendable, Monad by Composable, Functor by Runnable, etc. and most programming languages are "category theory".
I'm not sure an "Appendable" Int or IO type, or a "Runnable" / "Composable" List type is any less confusing to Joe Programmer. These descriptions do not articulate the same things implied by the Monoid, Functor, and Monad laws. Some of these aren't even correct (i.e. not all Functors are "Runnable", Monadic types do not necessarily compose directly, just via Kleisli composition).
> This says little about whether knowing the field of category theory will be useful to programming. Indeed, I think there's a good argument to say Haskell programming is much harmed by it.
> If its authors hadnt used their knowledge of category theory, but rather named the abstractions in more ordinary terms, the language would be more useful to more people.
I think this is really the least of Haskell's problems. Mystifying/poorly written monad tutorials and conflation with IO (or confusion about how IO works in the haskell runtime) is more responsible for confusing new programmers than the concept itself. I have no background in mathematics above undergrad calc 2 and I was able to understand them just fine.
I take it all Functors are runnable if you see (1) map as generalised function application and (2) functors as lifted map.
The concepts, at the level of abstraction i just use there, are confusing. Thinking this abstractly about programs actively impairs programming in many cases.
This level of 'unification of syntax via abstraction' is relevant only really to language designers.
> If its authors hadnt used their knowledge of category theory, but rather named the abstractions in more ordinary terms, the language would be more useful to more people.
The language would be just as useful, but it might _feel_ more approachable. Depending on the terms that replaced those it might be more confusing, or the opposite, than it is now.
To say that learning a field is useful is to say that knowing these abstractions is useful.
Much of Haskell's "category theory" is a reuse of terms. Replace Monoid by Appendable, Monad by Composable, Functor by Runnable, etc. and most programming languages are "category theory".
This says little about whether knowing the field of category theory will be useful to programming. Indeed, I think there's a good argument to say Haskell programming is much harmed by it.
If its authors hadnt used their knowledge of category theory, but rather named the abstractions in more ordinary terms, the language would be more useful to more people.