Why category theory matters in programming
tech.iheart.com
Why category theory matters in programming
1–10 of 47 posts
Re: Why category theory matters in programming
#2 category*Re: Why category theory matters in programming
#3Functional Programming and Category Theroy are great, there's a strong level of robustness in the whole approach to programming.
The author slams imperative programming, it isn't backboned on a robust compositional system, as is often done by FPers
BUT :)
there's lots of good programs in both styles....to me, this implies that there are more important things that matter to programming, the design to achieve a purpose. It's nice to express your designs in a robust system ( and be influenced by it), but what matters most is the design choices you make. When I look at well programmed things it's always the design choices that impress me.
Re: Why category theory matters in programming
#4Category theory is fine, I guess, but there's no need to invoke a sledge-hammer when talking about 99% of most work here.
It's a little like saying, yes, fine we can reference the hyperreals to derive infinitesimal calculus in a beautiful way, but it's mostly abstract and highly involved, even to just understand the foundational aspects (which one may argue is the case for normal calculus, but the notion of local linearity I believe is much more obvious than an extension to the reals). Though it's a nice academic exercise, which may even yield some insights, it's rather obscure and unintuitive for almost all purposes.
This is the way I view category theory and functional programming; though I'd love to be corrected if I'm wrong. There's no need to invoke almost all of it, since most things can be expressed quite clearly in the language of set theory need there be rigour.
Re: Why category theory matters in programming
#5Eh, as someone who works in scala day-to-day, and has studied actual category theory, I think the emphasis on category theory itself is silly. And in fact, most of the time, more category theory and more monads will make your code worse (e.g. MonadTransformers are D: )
Future, which is really a souped up promise abstraction, is the main star, and for-comprehensions are nice syntactic sugar. Being a "Monad" doesn't help you do anything with it though. And Future technically doesn't even truly obey the Monad laws, because of exceptions.
It's useful that a couple of container classes in scala use implement this trait:
trait ChainableContainer[A] {
def map(fn: A => B): ChainableContainer[B]
def flatten(nested: ChainableContainer[ChainableContainer[A]]):ChainableContainer
}
Re: Why category theory matters in programming
#6Functional Programming and Category Theroy are great, there's a strong level of robustness in the whole approach to programming. The author slams imperative programming, it isn't backboned on a robust compositional system, as is often done by FPers BUT :) there's lots of good programs in both styles....to me, this implies that there are more important things that matter to programming, the design to achieve a purpose…
Coming from HPC, I think imperative programming will stay as long as we don't have an AGI that does the actual programming for us, as it's the model with the highest possible abatraction that still gives you the whole truth about the underlying memory operations (and thus allows you to optimize for it without having your hands tied behind your back and just trusting the compiler gods). Not saying that this is how one should usually program in a context where performance is not the highest goal, but there's always going to be these usecases.
Re: Why category theory matters in programming
#7Eh, as someone who works in scala day-to-day, and has studied actual category theory, I think the emphasis on category theory itself is silly. And in fact, most of the time, more category theory and more monads will make your code worse (e.g. MonadTransformers are D: ) Future, which is really a souped up promise abstraction, is the main star, and for-comprehensions are nice syntactic sugar. Being a "Monad" doesn't he…
I was reading very famous paper[1] today, and I stopped at the following:
"To get an adequate definition of g [Now, this passage stood out to me because it seemed to be a set-theoretic, indirect phrasing of the exact symmetry I'm talking about. We have to consider all algorithms for computing f in order to recover the features that must be true for all f, and thus give identity to the notion of a general algorithm for f. Which in turn is used to establish theorems about such a general algorithm notion; (critically, its "relative complexity".)
My point being that I would not have expressed this notion in set theoretic language because my intuition wants it expressed in algebraic language. Things are identified by their symmetries, and building theories around symmetries directly is more efficient and insightful than building theories around how those symmetries are embedded in set theory. And when I sit around thinking about how to design a good API or an efficient program, I want to do it by stating what must always be true about the problems I'm solving, in a high-level, abstract way. (I'm not so good at it in practice.)
Set theory may be a simple model of many things, but it is only really intuitive for things that can be easily described in terms of unions and intersections. It is often just extra work elsewhere, at least if you have a frame of mind to see other ways.
[1] https://www.cs.toronto.edu/~sacook/homepage/rabin_thesis.pdf
Re: Why category theory matters in programming
#8Functional Programming and Category Theroy are great, there's a strong level of robustness in the whole approach to programming. The author slams imperative programming, it isn't backboned on a robust compositional system, as is often done by FPers BUT :) there's lots of good programs in both styles....to me, this implies that there are more important things that matter to programming, the design to achieve a purpose…
Coming from HPC, I think imperative programming will stay as long as we don't have an AGI that does the actual programming for us, as it's the model with the highest possible abatraction that still gives you the whole truth about the underlying memory operations (and thus allows you to optimize for it without having your hands tied behind your back and just trusting the compiler gods). Not saying that this is how one…
Agreed. That said, the problem is that imperative programming is still used widely in contexts (eg, 95% of web programming) where performance is not an issue and high-level abstractions such as those used in FP are more appropriate. This is almost entirely due, imo, to the paradigm's inertia and to bad education.
Re: Why category theory matters in programming
#9Eh, as someone who works in scala day-to-day, and has studied actual category theory, I think the emphasis on category theory itself is silly. And in fact, most of the time, more category theory and more monads will make your code worse (e.g. MonadTransformers are D: ) Future, which is really a souped up promise abstraction, is the main star, and for-comprehensions are nice syntactic sugar. Being a "Monad" doesn't he…
That has a little to do with Scala just being a pretty bad place to implement most of these things. E.g., Monad transformers work just great in Haskell but are terrible in Scala due to the sort of terrible ways type parameters and inference work together.
Future also doesn't obey the monad laws for not being RT and that causes a lotttt of complexity.
Re: Why category theory matters in programming
#10Earlier quoted context omitted.
Coming from HPC, I think imperative programming will stay as long as we don't have an AGI that does the actual programming for us, as it's the model with the highest possible abatraction that still gives you the whole truth about the underlying memory operations (and thus allows you to optimize for it without having your hands tied behind your back and just trusting the compiler gods). Not saying that this is how one…
Agreed. That said, the problem is that imperative programming is still used widely in contexts (eg, 95% of web programming) where performance is not an issue and high-level abstractions such as those used in FP are more appropriate. This is almost entirely due, imo, to the paradigm's inertia and to bad education.
[deleted]