5 ms·
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 wa
by 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 agoEven 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> Often, they refer to programming language tutorials where these mathematical ideas are already implemented, for example, in Python or C++. The difference is that _someone_ is actually implementing the features they're relying on, and those people know the math, understand its importance, and deliberately apply it. I know because I dig through their git commits so I can interview them about their work for my book. Your argument puts a lot of faith in Haskell. Let me take one path in your example to make this concrete. Rust was influenced by Haskell, how specifically? [1] claims it was mainly in "typeclasses, type families." Picking one randomly, the GHC user guide [2] describes type families as originating from three specific papers, [3], [4], [5], none of which mention category theory (nor does the much longer Haskell Wiki [6]). It seems to suggest, what is obvious to me, that not _all_ features of Haskell are related to category theory. If every time I trace claims of applied CT I find big holes, how could I possibly believe that so many great ideas that programmers use every day are secretly deliberately based on CT? There is a deeper discussion to be had here, along the lines of "does it count as an application of math if none of the people doing the applying think about the math." I think the answer is no. Math is a modeling language and if nobody models their problems with it then theorems do nothing. And so, if all of the category theory is lost in the translation from some (perhaps itself far removed) language feature of Haskell and later inspired language design, then that tells me category theory is the _wrong_ modeling language for that design problem. If it were good, and if the resulting theorems were essential and useful, then the practitioners would adopt it. That is a failure of CT. [1]: https://doc.rust-lang.org/reference/influences.html https://doc.rust-lang.org/reference/influences.html [2]: https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/type_families.html https://downloads.haskell.org/ghc/latest/docs/users_guide/ex... [3]: https://www.microsoft.com/en-us/research/wp-content/uploads/2005/01/assoc.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [4]: https://www.microsoft.com/en-us/research/wp-content/uploads/2005/01/at-syns.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [5]: https://www.microsoft.com/en-us/research/wp-content/uploads/2008/01/icfp2008.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [6]: https://wiki.haskell.org/GHC/Type_families https://wiki.haskell.org/GHC/Type_families
- amboo7 3y agoI would appreciate if someone wrote here their opinion on Matriarch [1], an application of category theory to biology/physics via software. [1] https://web.mit.edu/matriarch/ https://web.mit.edu/matriarch/
- j2kun 3y agoMy first approach is to look for references to the project on GitHub. Since this project is not itself on GitHub, next best option is to search the URL for code comments, docs, etc. https://github.com/search?type=code&q=web.mit.edu%2Fmatriarch https://github.com/search?type=code&q=web.mit.edu%2Fmatriarc... It has one result, which appears to be someone demonstrating their visualization library using a model from Matriarch as an example. Would love to hear from users of the software.