This is not a critque of the work, but I have now been often encountering category theory in many of the research topics I'm working on, and even as somebody who majored in math, I sort of feel like it doesn't add much. I know ML frameworks intimately, and you really don't need category theory to describe them. But this is maybe (probably) a failure of mine, because I have not yet groked what category theory is really bringing to the table.
Category theory isn't usually intended to add things. Often, what category theory brings to the table is connecting different branches of math. (It's a bit similar to abstract algebra in that way, but at a different level.)
For example, the lambda calculus is the base for many useful programming languages. But the lambda calculus maps to a "closed Cartesian category". And many, many other interesting things in math can be mapped to a closed Cartesian category.
So now you can ask, "What if affine or linear logic were a programming language?" And the answer is, "You'd get a language with safe resource management, like Rust." Or you might ask, "What if probability were a programming language?"
Or on a smaller scale, a parameterized collection type with "map" is a functor. Add a single-element constructor and a "flatten" operation, and you have a monad. Functions with parameterized types are often natural transformations. And so on. This can then be directly analogized to constructs in different areas of math. Which might sometimes produce an interesting idea or two.
So category theory isn't always used to add something new and profound. Sometimes it's just a handy way to see something already there.
It helps to not make a cluttered mess of an API. Breaking up the problem space with a few composable functions that can express all that you want to express is a definite win.
Category theory is all about relationships and structural patterns. so its useful when you want to interoperability and composition between systems i.e. invariants under transformations, etc.
Without reading too much into what this framework does, I'd say category theory could be useful for some ML problems (i.e. layer composition, gradient propagation, etc.) - but I'd think it would be more useful as an analytical tool than as actual lib/code structures.
You don't need category theory to describe the Result type. But the people who first introduced it to programming languages, were thing about category theory.
I don't understand, this looks to me like regular Rust, or regular programming for that matter.
You use types to represent domain objects, and the program is composed of functions that transform domain objects into other domain objects.
Sure types are used a bit more aggressively than usual to restrict domains, particularly the newtype pattern (`struct TokenId(usize)` instead of just `usize`). But it doesn't look too exotic to me, or Category Theory influenced, other than in the sense that Category Theory terminology can be used to describe the structure of a regular typed program.
It's possible that I'm wrong and I'm missing the point. Frankly I really struggled reading this because of the AI generated vibe of the language, more than usual. I generally hate when content is criticised for just being AI generated, you can write very good and valuable things with AI by guiding it properly with authorial intent, but this one does really reek of bloated slop.
The style of writing here feels very Claude...
This is not a critque of the work, but I have now been often encountering category theory in many of the research topics I'm working on, and even as somebody who majored in math, I sort of feel like it doesn't add much. I know ML frameworks intimately, and you really don't need category theory to describe them. But this is maybe (probably) a failure of mine, because I have not yet groked what category theory is really bringing to the table.
Category theory isn't usually intended to add things. Often, what category theory brings to the table is connecting different branches of math. (It's a bit similar to abstract algebra in that way, but at a different level.)
For example, the lambda calculus is the base for many useful programming languages. But the lambda calculus maps to a "closed Cartesian category". And many, many other interesting things in math can be mapped to a closed Cartesian category.
So now you can ask, "What if affine or linear logic were a programming language?" And the answer is, "You'd get a language with safe resource management, like Rust." Or you might ask, "What if probability were a programming language?"
Or on a smaller scale, a parameterized collection type with "map" is a functor. Add a single-element constructor and a "flatten" operation, and you have a monad. Functions with parameterized types are often natural transformations. And so on. This can then be directly analogized to constructs in different areas of math. Which might sometimes produce an interesting idea or two.
So category theory isn't always used to add something new and profound. Sometimes it's just a handy way to see something already there.
It helps to not make a cluttered mess of an API. Breaking up the problem space with a few composable functions that can express all that you want to express is a definite win.
Category theory is all about relationships and structural patterns. so its useful when you want to interoperability and composition between systems i.e. invariants under transformations, etc.
Without reading too much into what this framework does, I'd say category theory could be useful for some ML problems (i.e. layer composition, gradient propagation, etc.) - but I'd think it would be more useful as an analytical tool than as actual lib/code structures.
You don't need category theory to describe the Result type. But the people who first introduced it to programming languages, were thing about category theory.
https://en.wikipedia.org/wiki/Result_type
Maybe expand ML to Machine Learning to avoid confusing with the programming language
> Rust
> No HKTs
> Category Theory
It's nice to see that.
I don't understand, this looks to me like regular Rust, or regular programming for that matter.
You use types to represent domain objects, and the program is composed of functions that transform domain objects into other domain objects.
Sure types are used a bit more aggressively than usual to restrict domains, particularly the newtype pattern (`struct TokenId(usize)` instead of just `usize`). But it doesn't look too exotic to me, or Category Theory influenced, other than in the sense that Category Theory terminology can be used to describe the structure of a regular typed program.
It's possible that I'm wrong and I'm missing the point. Frankly I really struggled reading this because of the AI generated vibe of the language, more than usual. I generally hate when content is criticised for just being AI generated, you can write very good and valuable things with AI by guiding it properly with authorial intent, but this one does really reek of bloated slop.
Off topic, removed
I think this would be considered off topic.
I'll remove the comment then