5 ms·

> And when I talk to people who are actually on the front lines that try to use category theory to solve some problem, they tell me that it ended up being compl

> And when I talk to people who are actually on the front lines that try to use category theory to solve some problem, they tell me that it ended up being completely useless. I'm open to having my mind changed. I aim to provide an example of applied category theory in computer science. Your understanding may differ due to the encompassing time frame, however, I ensure that even the most recent findings can rapidly transform into a practical programming concept. The concept of 'monad' was initially introduced by Roger Godement in 1958, known as the 'standard construction'. The term 'monad' itself came into use later in 1967, credited to Jean Bénabou. The connection between monads and functional programming was first established in 1989 by computer scientist Eugenio Moggi. Moggi implemented monads in semantics to interpret the lambda calculus, a computational model that employs variable binding and substitution for function abstraction and application. The formal incorporation of monads into Haskell occurred in 1992 by Philip Wadler. Since then, monads are increasingly being integrated into mainstream programming languages, including JavaScript. For instance, JavaScript Promises can be viewed as a kind of monad. They encapsulate a value and allow its transformation with the .then method, which can be equated to the 'bind' operation in the realm of monads. Furthermore, a new Promise can be generated from any value using Promise.resolve, an operation analogous to the 'return' operation in monads. Promises have a very practical application and are used in programming by millions of developers every day. The concept of a monad is one example that is well-understood; however, there are numerous other such ideas. One of these is the Functor, often referred to as "mappable" in mainstream programming languages. Research in this field is ongoing, with concepts like applicative functors, introduced by Conor McBride and Ross Paterson in 2008, already gaining popularity in languages such as Haskell.

j2kun 3y ago
I understand those concepts well, but I find the casual chain of events questionable, especially when the story is told by category theorists. For example, I was once told by a prominent category theorist that certain aspects of the API design for C++ futures was informed by category theory. When I spoke to the people who actually wrote the RFCs, they said category theory had no part in their thinking. This is what it seems category theorists tend to do: they build a framework, express existing ideas within that framework, and then claim that the existing work is an application of category theory. I think that sort of retcon CAN be done. Many math topics like Fourier Analysis have taken practical results, built a math theory behind it, and then converted the entire field to the theory as standard domain knowledge. But the evidence that category theorists have done this, even in the realm of programming language APIs, seems slim. Even if you agree that the APIs align and the people designing the API know their thing is secretly a monad, still calling that a "success" of category theory is rather weak. By comparison, just because something has addition, units, and inverses, it doesn't mean that group theory is being applied in a meaningful way. The nontrivial results about groups that DO seem to lead to "real" applications are related to the structure of particular groups, as used in cryptography. But I have seen little similar in the way of category theory. Porting concepts from category theory to Haskell is nice, maybe, but it's not clear to me that doing so isn't creating as many problems as its solving (e.g., lenses solve a problem that no other language has, and most Haskell programs seem to me to be completely unreadable by anyone except the author, despite me being no stranger to Haskell).
- tome 3y ago
  > lenses solve a problem that no other language has Indeed other languages don't have problems dealing with immutable collections since almost none have good immutable collections. All I can say is that, when working with other languages, I wish they did have that problem! > most Haskell programs seem to me to be completely unreadable by anyone except the author Interesting. That's the opposite of my experience. Haskell is pretty much the only language where I expect to be able to read code written by others ("others" including "myself a year ago").
  - dllthomas 3y ago
    Even where they lack the problem I find myself wanting lenses (or other optics) every couple months at a minimum.
- tutfbhuf 3y ago
  > ... but I find the casual chain of events questionable ... When I spoke to the people who actually wrote the RFCs, they said category theory had no part in their thinking. I think you missed one level of indirection in my argument. I'm not claiming that language designers employ Category Theory explicitly when designing new language features (although this is indeed the case with Haskell, PureScript, and similar languages). Rather, my argument is that Category Theory features typically debut in these purely functional languages and then you will see on the Wikipedia page of mainstream languages something like: “Influenced by Haskell” (e.g. Rust, +20 others) . Category Theory is very abstract by nature, so I think it is only natural that there is some kind of indirect step through e.g. Haskell where people can see it in action first, before such features land in mainstream programming languages. The language designers would then say, 'Well, I have been influenced by Haskell (and not by Category Theory)', although the concept behind it is truly based on CT. Many programmers don't keep math books at their workstation. However, they constantly utilize mathematical concepts in their coding. Often, they refer to programming language tutorials where these mathematical ideas are already implemented, for example, in Python or C++. This is as opposed to learning the concepts directly from a book on Algebra, Geometry, or Trigonometry. However, that still qualifies as applied mathematics. Hence, I see no reason why it shouldn't count as applied CT if you borrow concepts from Haskell that are based on CT.

j2kun 3y ago

I understand those concepts well, but I find the casual chain of events questionable, especially when the story is told by category theorists. For example, I was once told by a prominent category theorist that certain aspects of the API design for C++ futures was informed by category theory. When I spoke to the people who actually wrote the RFCs, they said category theory had no part in their thinking. This is what it seems category theorists tend to do: they build a framework, express existing ideas within that framework, and then claim that the existing work is an application of category theory. I think that sort of retcon CAN be done. Many math topics like Fourier Analysis have taken practical results, built a math theory behind it, and then converted the entire field to the theory as standard domain knowledge. But the evidence that category theorists have done this, even in the realm of programming language APIs, seems slim. Even if you agree that the APIs align and the people designing the API know their thing is secretly a monad, still calling that a "success" of category theory is rather weak. By comparison, just because something has addition, units, and inverses, it doesn't mean that group theory is being applied in a meaningful way. The nontrivial results about groups that DO seem to lead to "real" applications are related to the structure of particular groups, as used in cryptography. But I have seen little similar in the way of category theory. Porting concepts from category theory to Haskell is nice, maybe, but it's not clear to me that doing so isn't creating as many problems as its solving (e.g., lenses solve a problem that no other language has, and most Haskell programs seem to me to be completely unreadable by anyone except the author, despite me being no stranger to Haskell).

tome 3y ago
> lenses solve a problem that no other language has Indeed other languages don't have problems dealing with immutable collections since almost none have good immutable collections. All I can say is that, when working with other languages, I wish they did have that problem! > most Haskell programs seem to me to be completely unreadable by anyone except the author Interesting. That's the opposite of my experience. Haskell is pretty much the only language where I expect to be able to read code written by others ("others" including "myself a year ago").
- dllthomas 3y ago
  Even where they lack the problem I find myself wanting lenses (or other optics) every couple months at a minimum.
tutfbhuf 3y ago
> ... but I find the casual chain of events questionable ... When I spoke to the people who actually wrote the RFCs, they said category theory had no part in their thinking. I think you missed one level of indirection in my argument. I'm not claiming that language designers employ Category Theory explicitly when designing new language features (although this is indeed the case with Haskell, PureScript, and similar languages). Rather, my argument is that Category Theory features typically debut in these purely functional languages and then you will see on the Wikipedia page of mainstream languages something like: “Influenced by Haskell” (e.g. Rust, +20 others) . Category Theory is very abstract by nature, so I think it is only natural that there is some kind of indirect step through e.g. Haskell where people can see it in action first, before such features land in mainstream programming languages. The language designers would then say, 'Well, I have been influenced by Haskell (and not by Category Theory)', although the concept behind it is truly based on CT. Many programmers don't keep math books at their workstation. However, they constantly utilize mathematical concepts in their coding. Often, they refer to programming language tutorials where these mathematical ideas are already implemented, for example, in Python or C++. This is as opposed to learning the concepts directly from a book on Algebra, Geometry, or Trigonometry. However, that still qualifies as applied mathematics. Hence, I see no reason why it shouldn't count as applied CT if you borrow concepts from Haskell that are based on CT.