I do not agree with this (however, I only have one grad category theory course). I think category theory is a fine tool for formalizing computation and thinking about type systems, but wouldn't approach it as a program design tool.
You are taking Type A and converting it to Type B. That is the entire point of computation. All else is abstractions on top of that and algorithms below.
Category theory is what lives on top. Haskell is a programming language and style that borrows very very heavily from category theory. Getting a certain level of mastery in haskell well help you see how programming is related to CT.
I have studied haskell from this perspective. Like I said, you learn how to model computation and how the haskell language works, you don't learn how to design programs. I actually have gotten much more program design ideas from traditional branches of math (analysis, algebra, etc).
> If you designed programs in haskell then you designed them using concepts from category theory.
It's the level of abstraction and focus. Category theory can describe "mapping over promises" it doesn't give a lot of insight into how to design an internet communication protocol with low latency (for example).
> I would say you didn't get very far then
Sounds like you put a lot of value in your experience with this topic and I am unlikely to convince you.
I actually agree with you. Its not a good theory for finding optimal speed.
I would say it's more of a better theory for optimal organization and reuse of code. It's a theory of interfaces. If programming is all about abstraction then CT is the theory of design and abstraction.
I agree that detail and speed and execution are important in computer science but these things maybe aren't general enough as the efficiency of speed also relies on which turing complete language (out of an unlimited set of languages) that is used to drive the computation.
We also do have a general theory for optimizing speed. Computational Complexity theory. Which is based on Knuth's little assembly language. This theory can literally help you converge onto the best possible solution. Not by calculation but it can quantify the speed of an algorithm for definitive comparisons.
But then would complexity theory be the Maxwell's equations of programming? I think there's a good argument for that route but I don't think that's what the OP is thinking about in his article.
The op is thinking about design because Lisp is definitely a design philosophy. Lisp won't help you design an internet communication protocol for low latency either.
Maybe you did study category theory deeply but your thinking about it from an angle of computational cost. This is certainly valid. Apologies for that comment, Haskell and CT like any other design pattern out there is usually not targeted specifically at optimizing speed, but more for optimizing code reuse and increasing modularity. It's for dealing with technical debt and how to handle the complexity of programming through abstraction.
If you're thinking about it from that angle then I think the universe already has your answer. Computational Complexity theory is the Maxwell's equations of software. It's not a very complete theory but it's much more concrete then all the other "design" stuff in computer science.
> Haskell is basically a category theory framework.
Haskell probably draws more from category theory than any other mainstream language, but in absolute terms that's still not very much. It's okayish for modelling cartesian closed categories, but if you want any more structure than that things get quite painful. Even something as simple as a category with finitely many objects requires stupid amounts of type-level boilerplate.
There is no best mental tool. This is design, we don't have methods to converge on optimums. So you can't probably say any mental tool is better. It's all just different sets of primitives and category primitives, if you squint, feels like the proper theory of design.
Category theory is also so abstract that you can literally find it in everything. So it's not like it doesn't apply, it applies to everything.
When I say Haskell is a category theory framework I mean that Haskell has primitives that are explicitly modeled after CT and named with the same mathematical names. You don't have to know CT from a mathematical angle to use Haskell but it doesn't change the fact you are using CT primitives like functor to build things.
Other languages have CT concepts like functors but they don't crystallize the concept in such a pure and explicit form. That's just my opinion on it. You are welcome to disagree.
But when you say garbage like "100% nonsense" it's just fucking rude and against the rules here at HN. Don't say it again. Speak respectfully or don't speak at all.
> But when you say garbage like "100% nonsense" it's just fucking rude and against the rules here at HN. Don't say it again. Speak respectfully or don't speak at all.
I found that commment to be seriously rude and disrespectful. Yes I should have avoided the "100% nonsense" comment. However that doesn't give you licence to be rude and abusive in return.
It is rude, but it is reasonable. When a child acts unruly and immature he must be disciplined with a forceful hand. I called you out harshly and the harshness was fucking deserved, no matter how miffed you get about it.
I mean you expect me to just stand here and get raped by your rudeness? No reasonable man with spine will take that shit in real life and that's also typically why you don't likely speak that way in real life.
