Hacker News Reader

Agreed. More often than not, it's just a layer of jargon that obscures the topic at hand rather than clarify it. Worse, I see a lot of folks using it to belittle and intimidate -- recently I met an instructor at a startup-focused programming school who put his (very novice) students through a lecture which began, "Is a burrito a monoid" and went down hill from there -- he was actually bragging about how lost his students were. And he told me about all this under the presumption that I didn't know category theory (easy mistake, I guess, I'm a woman after all) and my biggest regret is that I didn't ask him to explain Poincare duality to me. If only he knew that my paralysis was a result of biting my tongue at his pedagogical trashfire...

I doubt you being female had anything to do with it.

> startup-focused programming school

Curious what are these? They place into a startup after you are done?

surprised that they are teaching category theory if that is the case.

That's just the thing. Category theory isn't really a part of their standard curriculum -- it's something that a lone instructor decided to put into his syllabus.

My one-line description of the business doesn't really do it justice -- it's programming school with a focus on web & app development, and they have fairly good (dev-)community engagement. They also teach some business skills along the way, and students often end up with startups, or founding their own. Also many of their instructors currently work at startups.

That guy is an imbecile and your life is better for not having engaged with him.

> Poincare duality to me

next time don't pass the opportunity

I'd go a step further. If you're trying to do functional programming in scala/js/ruby/php you don't need to care about any of those words (functor/monoid/monad/category).

You can write high reusable, generalized, clean functional code without knowing a darn thing about the theory behind it. Moreover, if you do learn these words you probably shouldn't use them around your peers because they'll serve to socially alienate you and confuse them.

What the hey, I'll pile on more --

Category theory type stuff is a very useful thing to know when designing programs, because it is useful to know things like, "Well, if I give this data structure these properties, then it'll be well-behaved when I map over it."

But you do not need to learn all the technical jargon for the concepts in order to develop a command of them, any more than you need to memorize a natural language's formal grammar rules in order to speak it competently. (Since the grammar needs to be explained using natural language, one could even argue that it isn't really possible to do the one before the other, in a big picture sense.) Also similar to learning a natural language, learning all the technical, formal stuff isn't necessarily all that useful for helping you to achieve practical competence.

To stretch that analogy even further, getting too enamored of the category theory stuff is likely to earn you a certain measure of benevolent disdain from experienced functional programmers in the same way that getting too enamored of grammar rules is likely to earn you a certain reputation of disdain from people who write for a living. It's not that they don't value these things, it's that talking about them too much sends signals that you're more interested in reading the rulebook than playing the game.

In my view, "Functor" and "Monad" are the wrong emphasis, while "map" and "flatMap" are the parts that really matter, and are much easier to teach in comparison.

Most programmers are familiar with "map" today, and "flatMap" is not much of a stretch. But once you understand these two things, you're 90% of the way to understanding monads and why they're useful.

Very well said. The practical reality is that the “category theory” used in functional programming paradigms (like Haskell’s) has only a passing resemblence to formal category theory in mathematics. It’s a nice idea to formalize some concepts in functional programming algebraically, but learning formal category theory won’t realistically improve your programming ability. There is some conceptual overlap, but they’re just very different things.

On the one hand I know what you mean: I know practically no category theory (basically I know enough to expect "co" as a prefix to mean "everything the other way around"), but I can still produce good Haskell code.

But on the other hand, I look at some of the stuff Edward Kmett has produced, particularly his lens library which I use all the time, and its very obvious that the design has been informed by a deep knowledge of category theory.

As a contrasting point of view, the excellent graduate level introduction to algebra, Algebra Chapter 0 by Paolo Aluffi introduces category theory right from the start and it's a very good book. It just uses the concepts of a diagram and a universal construction, which have a high power-to-weight ratio.

I agree that the danker category theory is more useful for research than for teaching. In particular when you want to try to import definitions and theorems from one context to another, or you want to decompose a proof into its abstract skeleton and concrete particularities.

As an example of how "A monad is a monoid... etc." can be useful for the abstraction (i.e. library) builder, if you import this definition of a monad into the bicategory of endoprofunctors, you get arrows [1].

[1] http://www.riec.tohoku.ac.jp/~asada/papers/arrStrMnd.pdf

I think this is a good point. I find the language of category theory an invaluable tool in my own understanding of abstract algebra, and universal properties are a large part of that. I think that a lot of undergraduate mathematicians could benefit from seeing the universal properties of a product/coproduct, and reflecting on what this means in categories that they're comfortable working in. Universal properties are usually quite useful.

My specific gripe is with expecting that a statement like "a Lie group is a group object in the category of manifolds" is going to lead to any new theorems in the theory of Lie groups. It's just not, and you are not going to become any better at Lie groups by understanding that statement. It's good to understand at some point, because it unifies the definition of group / Lie group / algebraic group, etc, but it will really not give you anything new to work with.

> It's good to understand at some point, because it unifies the definition of group / Lie group / algebraic group, etc, but it will really not give you anything new to work with.

I think that's true at an elementary level, but on the other hand when one doesn't know what concepts they're looking for in a new area, category theory can be a machete cutting a swathe through the jungle. I think Grothendieck was right :)

> "a Lie group is a group object in the category of manifolds"

The point is of course to motivate the definition of a Lie group. Whether such strong motivation counts as "a better understanding of Lie groups" is largely a matter of semantics that there's some room to disagree over. Same goes for the categorical definition of a ring that's been mentioned at the start of this thread, or indeed the definition that OP talks about.

I love Aluffi's Chapter 0 and mentioned it in another comment. But I don't think it's appropriate as a first pass on abstract algebra, even for pure math majors. Maybe for an Honors Intro to Abstract Algebra course...otherwise, I think Aluffi is pretty clear in that while he thinks category theory should be covered early on, it's really a text for graduates and not undergrads. Abstract algebra should be covered before you get to grad school.

What is a good textbook in abstract algebra for the beginner?

Somewhat less of a "textbook", but good at showing applications of category theory - Fong, Spivak: Seven Sketches in Compositionality https://arxiv.org/abs/1803.05316

(Notably, this includes application to a "graphical" treatment of fairly-elementary linear algebra, which a different HN user is mentioning even as I write this, as a part of math where CT cannot possibly be useful and will only ever confuse students!)

It depends what "beginner" means -- what's your level of sophistication? Are you a budding mathematician or just an interested programmer?

Assume I know 0 math and want to learn mathematics for mathematics sake. What is the most gentle intro to algebra book?

True Beauty of Math Volumes I and II. These build up math from the ground up starting with sets and assume you have zero knowledge of math. What's cool is that you don't use any theorems, structures, or notation that you haven't proven or introduced previously in one of the books. I've found them to be very valuable in both understanding the topics that they cover and giving an intuitive understanding of math as process (which the all the classes I took in college tended to gloss over).

The first volume is roughly about set theory and the second volume is roughly about abstract algebra.

https://truebeautyofmath.com/

https://www.amazon.com/True-Beauty-Math-Foundations/dp/15120...

https://www.amazon.com/True-Beauty-Math-Giving-Life/dp/15448...

Bought the first book. Thanks for the recommendation!

If you know 0 math I would start with basic arithmetic (+, -, *, /) before doing anything else.

My undergraduate Abstract Algebra course used Gallian’s “Contemporary Abstract Algebra.” Unfortunately if you are truly looking for an introduction assuming no mathematics, you will need to learn high school algebra and a bit about sets and proofs first.

Pinter's A Book of Abstract Algebra.

A good recent release is Bartosz Milewski's Category Theory for Programmers.

https://bartoszmilewski.com/2014/10/28/category-theory-for-p...

In the order of increasing complexity and/or volume: Pinter, Fraleigh, Rotman, Dummit & Foote.

I like Algebra by Mac Lane and Birkhoff, if by beginner you mean undergraduate.

On the flipside, knowing that a ring is "like a group (which we already covered), with another operation that follows these axioms" is useful, and still mostly rigorous.

It's better than "eh just use it a lot and you'll figure it out."

Of course I'm not recommending learning ring theory without learning the (usual) definition of a ring. This is absolutely rigorous and useful, and immediately after you learn it you can start playing around with rings, and start proving some interesting theorems.

The analogue of this approach in Haskell is probably something like sections 1 and 2 of "Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell" [1], which is quite an old paper (from around 2000 or something?). It does not even contain the word "monoid", but instead shows what an IO action is, and how functions like >> and >>= can be used to sequence and thread them. It also provides a lot of context as to why monadic IO exists. After reading this, a new programmer could start playing around with making new IO actions using these operators. After reading about monoid objects, a new programmer is no closer to being able to write a Haskell program.

[1]: https://www.microsoft.com/en-us/research/wp-content/uploads/...

True, but that likeness is normally taught in abstract algebra without requiring category theory. For example this: https://i.redd.it/yqnbigi032i11.png doesn’t require any category to understand.

Not my point.

For education, there is a happy medium between providing theoretical context and hand-waving over technicalities and learning by example.

Very nice diagram though.

To give credit where it's due, that diagram is from a /r/math thread: https://www.reddit.com/r/math/comments/99y547/my_digram_of_a...

that's definitely a neat diagram but the examples (the blue) almost entail already know the definitively.

And "these axioms" are indeed the axioms of a monoid operation (for multiplication), plus some sensible notion of "consistency" with the underlying abelian-group structure. Which is all that the "monoid object" characterization is saying, actually. So, I disagree that the perspective is inherently unintuitive.

I think you may have a different definition of intuitive than the top level comment, or else you two are speaking to different things. Category theory is certainly "elegant" and provides a lot of insight in the connection between various algebraic structures. But I think it would be completely asinine to use category theoretic formalisms in a first course covering algebraic structures like groups, rings and fields. That level of abstraction doesn't make the distinctions between each structure more intuitive; if anything it obfuscates them and requires setting up far more machinery to explain what they even are. It would be highly inappropriate for an undergrad's first exposure.

That is my impression of the top level comment's point, and I largely agree with it. If you understand what a group is, I can explain what a ring is to you in a very straightforward way that still shows you the connections between the two things. But setting up category theoretic language would take up a nontrivial portion of the course itself, and at the end you'd have a much less specific understanding of the relevant theorems on rings and groups. You'd be missing all the trees for the forest.

Look, it's 2019. "Setting up category-theoretic language" is something that should begin in the first lesson of the first course in formal, non-K12 math, starting with the use of ETCS or a comparable "structural" set theory as the 'naïve' foundation of choice. It provides countless advantages not just in abstract algebra, but in a wide variety of other subfields of math as well.

To be clear, how much category theory are you envisioning setting up in a first course on abstract algebra? Are you basically just talking about a modern treatment of morphisms in the abstract sense, or do you also mean discussing things like functors?

My perspective on this is basically informed by the following: I like category theory a lot. I've chatted with Baez about this on a few occasions and insofar as I need to use algebra, I like the category theoretic formalisms that come along with it. I think if you had students with a lot of mathematical maturity but no prior exposure to abstract algebra (except maybe a rigorous treatment of linear algebra), you could accomplish what you're proposing.

To your point, one of my favorite math textbooks is Aluffi's Chapter 0. You're probably familiar with it, but if not: it builds up abstract algebra in a rigorous and modern fashion alongside category theory. However, there are a few caveats here:

1. Aluffi explicitly states it's a textbook for upper level undergrads and preferably graduates. In my experience, when authors say this they actually mean it's appropriate as a year one graduate course. That's not the time to learn abstract algebra for the first time!

2. Aluffi does a great job of covering things like morphisms and categories, but the size of the book is massive. He doesn't have any nontrivial coverage of deeper category theoretic concepts like functors until much later in the book; it's probably far enough in that you couldn't reasonably cover it in a single semester course.

3. I really don't think most math majors would benefit from it. Those who are applied math majors will get questionable benefit from a slower, more comprehensive approach to algebra than a faster approach that lets them get to applications. Moreover, not all pure math majors have the mathematical maturity to approach category theory before grad school. Proofs in traditional abstract algebra are a lot less abstract than category theory, and it's easier to motivate them even if they aren't ultimately as elegant.

The problem with "a faster approach that lets [you] get to applications" is that it will depend a lot on what applications you have in mind. And often it's not even faster in any real sense - there's a whole lot of pointless duplication involved in tailoring things to a lower level of abstraction. It may be better to begin with a more effective explanation of what sorts of "mathematical maturity" we're actually seeking here, so that attaining it is easier in the first place for the average student. For all their supposed "unintuitiveness", category-theory-based explanations do this quite well, in a way that I haven't really seen elsewhere - I mean, this very thread is one where we're discussing software developers learning category theory and benefiting from it, so why couldn't this be also a part of mathematical training?

I strongly disagree. From experience teaching category theory to undergraduates, it is totally obtuse before that have a large pool of examples on which to draw. In a very first course, students are still struggling to learn concepts from linear algebra, which will be the bread and butter of the rest of their mathematics. In a second course, they are struggling to learn why the definition of "linear map" is different from the definition of "matrix" they learned in their first course. You could say the same thing about metric spaces or topology.

Perhaps the third course is a nice place to start introducing some category theory, since they will now have actual examples on which to draw, and learn about the unifying concepts of "morphism", "categorical product", and so on. They might even be ready for some interesting functors, such as the fundamental group of a topological space.

If you were to teach category theory as a very first course, what would you teach? What examples of categories do you have? What examples of functors?

The consistency with the underlying abelian group could be restated as "multiplication is bilinear, and has a unit", which is the correct perspective to take if you want to "upgrade" from the usual definition to the "monoid object in the category of abelian groups" definition.

But understanding bilinearity and its connection to tensor products is the key part of changing between those definitions, and also the most useful step to understand. The final description is pretty uninteresting in contrast with universal mapping properties of a tensor product.

Yup, and I think it's actually a completely rigorous definition – all rings are commutative groups under one operation (often referred to as "addition"), plus another operation ("multiplication"), plus rules for how they interact.

The point of the category-theoretical definition is to explain how these "rules for how they interact" might arise, and in what sense these might be understood as 'minimal' rules. These are not "equivalent" definitions in any real sense, and to think of them as such is arguably missing the whole point of how category theory can be useful here.

> knowing that a ring is “like a group...” is useful

Turns out, not so much, though. The ring theory bears surprisingly little resemblance to the group theory, to the point that these concepts seem to have nothing to do with each other...

Except that a ring is literally a group under addition?

Do you seriously mean to suggest there's no pedagogical value in using groups to teach rings?

There's actually a big debate between math educators on whether abstract algebra courses should follow a groups first or a rings first approach so it is totally possible to teach rings without appealing to groups. (I'd still argue that both approaches have their advantages and disadvantages and that there can be value in using groups to teach rings though, I just wanted to say it's not as obvious as you might think)

I could be wrong here, but my read of that comment is that they're talking about the structural differences between rings and groups at the research level. Which I guess makes sense, since you're in very different territories if you're talking about something like representation theory of finite groups...

Otherwise I agree with you, there's a lot of pedagogical value in combining coverage of algebraic structures.

Yes obviously you need to know what a group is to even begin ring theory but ring theory looks and feels nothing like group theory.

The fact that "A monad is a monoid in a category of endofunctors" explains everything while clarifying nothing is exactly why Haskells repeat that phrase -- as a joke.

Having studied abstract algebra before using FP, I must say that I instantly made this connection when I came into contact with monads, and that it helped me a lot to understand them.

So I wouldn't be so quick to dismiss the idea of associating these concepts. After all, category theory is all about making that kind of associations.

This is a good observation. Though, most programmers don't study, and don't have to study, enough abstract algebra before being exposed to promises, optionals, and even lists (which all exhibit some form of monadic behavior).

What worked best for me was both playing with code, reading the definitions in code, and then look up some CT to get to the mathematical roots and where they fit in the intuitive picture. (Then you can continue with arrows, monad transformers, etc.)

Since my primary purpose for learning monads (and other algebraic constructs) was and is their use in programming, I concentrate on "practical" intuitions, and periodically check if I can go down to the algebraic base of them in a particular case. If I still can, I suppose I know enough math to get by in the particular area. If not, I open a book and clarify my understanding, and maybe glean something new.

If you already know category theory, sure, that's fine. (Or maybe if you already know abstract algebra really well.)

I'm going to go out on a limb, though, and speculate that the average person starting to use FP does not already know category theory.

For me category theory is more concrete. The basic reason is simple: categories provide type information. If all you want to do is grind out some calculations to pass an exam, then yeah, memorize the ring axioms and have at it. Anything more than that, and you need direction, or context, Ie. types, categories. Once you de-categorify that's when things become mysterious and confusing, and the impressive calculations abound. But it's just because you forgot the concrete thing that you are calculating.

It's all a bit paradoxical, and I'm not explaining it very well. (And I have no clue about the Haskell stuff.)

I fail to see how a category theory perspective is going to help with "grinding out" any interesting theorems about commutative rings, such as:

- Every commutative ring has a maximal ideal.

- The quotient of a commutative ring by a maximal ideal is a field.

- The quotient of a commutative ring by a prime ideal is an integral domain.

- The classification of finitely generated modules over a principal ideal domain.

There are some universal properties which define what it means to be a quotient, which can help you work with them. But for example, the only "categorical" definition of prime ideals that I know is based on that third theorem.

I think it is easy to forget just how much underlying theory you need to know before you can check that the categorical analogues of definitions are even the same as the original ones.

>and means you have to define things like the tensor product of abelian groups properly before you can even define a ring

Hmm, someone managed to do it at Wikipedia:

"In mathematics, a ring is one of the fundamental algebraic structures used in abstract algebra. It consists of a set equipped with two binary operations that generalize the arithmetic operations of addition and multiplication. Through this generalization, theorems from arithmetic are extended to non-numerical objects such as polynomials, series, matrices and functions."[0]

[0] https://en.wikipedia.org/wiki/Ring_%28mathematics%29

You missed the point of the parent comment.

They were saying that the definition you found, on wikipedia, is better than the definition of "a monoid object in the category of abelian groups" because the definition on wikipedia doesn't require knowing about tensor products etc.

You're proving their point. Wikipedia doesn't define it with that language for exactly the reasons the comment pointed out.

Yes, exactly. That's not category theoretic language, which is why that definition is so approachable. There are far fewer prerequisites to understanding what's going on in that definition.

That's precisely what the parent commenter is getting at.

Seems like all language would be "category theoretic".

No, not at all. Here are two equivalent definitions of a ring:

1. A monoid in the Ab-category.

2. A set R which is equipped with addition and multiplication.

The first definition is category theoretic, and requires you to know what abelian groups are and what it means for something to be 1) a category, 2) a monoid, and 3) a monoid in the category of abelian groups.

The second definition is straightforward if you can follow a few axioms and know naive set theory. It is helpful but unnecessary to understand that a ring is an abelian group which also supports multiplication in order to get the second definition. But even if you know this about rings, you'll still need to understand all the heavy lifting behind what the category of abelian groups actually means.

I'm not saying it's not useful. But I am saying one is clearly more accessible than the other, with fewer prerequisites.

All those words are in various categories.

All mathematics is abstraction.

Numbers are abstractions

Variables are higher level abstractions

You can have properties that you abstract and then see what you have. Banach spaces. Metric spaces. Three different ways to define compactness.

I liked to teach calculus by teaching the limit of a sequence first and then defining limits of functions by considering all sequences x_n that converge to x, and then looking if y_n converge. Building up definitions from simpler definitions, instead of the STUPID handwavy definition they use in Calculus 1 that can’t even handle limits of functions like cos 1/x and answer about limits of certain subsequences of x_n that approach 0.

I started a course about mathematics this way, building up from the very basics:

https://m.youtube.com/channel/UCuge8p-oYsKSU0rDMy7jJlA