Hacker News Reader

Comment by mej10 | Hacker News Reader

> most complicated concepts ever developed

I disagree. Much of Category Theory isn't complicated -- it is just really abstract. So you need to have some concrete knowledge that you are going to apply it to before you start learning it or alternatively "mathematical maturity" (or as I like to call it "the ability to just accept abstract statements and go with it").

As a tool it clarifies and unifies relationships between mathematical concepts and domains like nothing else has.

View on HN

To me it looks like a simple theory made needlessly harder by bad UX design. For instance, arrows are written left to right as f: X -> Y, g: Y -> Z, and composed right to left, g . f. There a lot of unmnemonic names like epic and monic morphisms, which are dual to each other but with unrelated names. The beginner, at least if they're me, must struggle to fit all these difficulties into their head together long enough to even follow what's being claimed, before they can work with the formalism.

If category theory is as cool as it sounds (and as simple as it doesn't) then somebody could do us a neat service by working out a game like http://worrydream.com/AlligatorEggs/ did for the lambda calculus. (Added: I guess it must've already been done, as formalizations of category theory in interactive proof assistants. Any tips on what's the most accessible?)

When I look at category theory diagrams, I always think that the visual embedding is underutilized. It seems like the diagrams could be enriched with more symbols to encode more information. For example (and probably a bad example) differentiating between automorphisms and identity functions using different symbols on their arrows). Somehow making these diagrams completely self-contained could be potentially interesting, and I wonder what the tradeoffs would be.

Maybe the current formulation of the diagrams is just right for people who use them to do a lot of heavy lifting. It would be interesting to hear some opinions on this.

You might have a look at section 1.39 in "Categories, Allegories", by Freyd and Scedrov. They introduce a language of diagrams and show how common definitions can be represented this way. Not a particularly easy read.

but isn't abstract the same as complicated

No.

No. The idea of a monoid is abstract but extremely simple. Conversely, the Navier-Stokes equations are very complicated but very concrete.

No.

Complicated means there are many strongly coupled parts that you have to understand before you can understand the whole. Computer programs tend to be complicated (one sign of a good computer program is that you can understand and work on pieces of it without having to understand the entire thing).

Abstract means that the idea itself isn't tied to a particular instance of what it is describing. Interfaces in Java are abstract. The idea of a group in mathematics is abstract. Abstraction is usually an attempt to make an idea less complicated so you can focus on its essence.

As an example, concretely I might have a list of people's heights and ages. I can attempt to fit a line to match heights as a function of age. Abstractly, I might have a list of numbers x and y. I can attempt to fit a line to them too. More abstract, but no more complicated.

I know I'm probably going to keep getting down-voted ,but if it's merely abstract and not complicated ,why is category theory considered a difficult course? They don't teach it in undergrad. Is it because it is poorly taught, or students don't like abstractions, or students are ill-prepared, etc. The question I'm digging at is what makes something hard to understand versus easy

It's hard to appreciate because to make the abstract nature valuable you need a body of concrete examples. You could probably do this halfway through an undergrad course, but it's not traditional. You can also do it with a body of programming knowledge.

You need to know a few interesting categories and functors before you can appreciate it. Without that, it is really abstract nonsense.

Most people find abstract hard. I've seen how hard it is for people to really grok groups, and groups are comparatively trivial, with many concrete examples. The examples in Category Theory tend to be things that are themselves abstractions of things that are already quite abstract.

Maybe because category theory makes sense only after you have sufficient math background? Just like it's easier to make sense of the definition of algebraic structures when you're already familiar with enough of their instances.

An other reason, maybe category theory isn't that useful? I'm just speculating here as I have only basic knowledge of category theory, maybe someone else can enlighten us! While all the maths taught at undergraduate level are extremely useful and pervasive in all areas of science, I'm still unsure about category theory. It's certainly nice and elegant as it allows us to reframe different theories and definitions in a same context, but is it useful for an engineer or an applied mathematician?

Category theory is very useful for certain branches of pure mathematics (and it instils a very useful mindset in the mathematician), but much less so for applied mathematics.

Also you're quite right that category theory only really starts to make sense when you have a big stock of examples, like "group theory" and "poset theory" and "topology" and "set theory". Once you've got those examples, you can detect these common threads between them and call them "category theory".

On the other hand, at least some of the ideas from the category theory have already made their way into the _practice_ of programming. I am talking about the notion of a monad. It has already become an important tool in functional programming; but even in mostly-imperative programming languages such as C# one can discern important patterns as instances of this concept. Contrary to the common perception, it is not hard to understand. Two basic examples: the optional (a.k.a. nullable) type construct is an example of a monad (called 'Maybe' monad in Haskell); a generic list construct is another one. I think it is enlightening to be able to see a common pattern behind these, seemingly different, things. And this is exactly where the power and the usefulness of the category theory lies - in mathematics or elsewhere.

> the optional (a.k.a. nullable) type construct is an example of a monad

Nullable (in the C# sense) does not form a monad, because it does not form a functor, because you cannot write fmap, because it does not nest.

Reply on news.ycombinator.com