
Category Theory for Programmers (2014) [pdf] - furcyd
https://github.com/hmemcpy/milewski-ctfp-pdf/
======
CTmystery
Can someone please explain to me the excitement for category theory in this
forum?

I've gone through the first 10 chapters + exercises of this book, and truth be
told the content is interesting but the ROI is low for programming (FWIW I
started this book as part of a study group in a large unicorn co, and after
approximately one month I was the only person left grinding through the
exercises, hoping for some payoff).

It's cool that I know what a functor is, I guess, but where others tout CT as
unlocking a higher level view of programming, all I see are little curiosities
(when you do X you are really doing Y, isn't that cool!?).

I've heard it said that CT's true power comes as a "refactorer" for what would
otherwise be complicated proofs. I.E. we discovered a new tool to make proofs
that already existed more elegant. That's cool that it has a use! Does this
somehow extend to programming?

I don't mean to sound like a grouch, but I'm genuinely baffled by the level of
excitement around this topic.

If you're looking to scratch a math itch, ML has plenty of opportunities to
hobby some math while advancing your career and marketability.

For programming in general, there are tens of topics I would pick before
reaching for this, with major immediate payoff to our occupation as
programmers.

Finally, after going through 10 chapters I skipped to the end to see if there
was some culminating breakthrough that we were striving towards... and I found
more definitions stacked upon other definitions. I suppose memorizing all
these definitions is supposed to give me a different mental model about
programming. Is that right?

I'll quote here the first line of the Analects, "Isn't it a pleasure to study
and practice what you have learned?". This is what I look for in studying any
topic: something that gives me joy to put into use. In the best cases it gives
me a feeling of a super power - something that was previously impossible or
extremely difficult is now elegant and clear. Can CT offer that in any way to
programming?

-Sincerly, Guy that doesn't get it, but wants to

~~~
philzook
I think I've got the category bug. I very much was intrigued by Milewski's
course and found that it made things happening in Haskell make more sense to
me. There are a couple of things that really excited me.

Conal Elliott's compiling to categories. Categories make a great intermediate
representation for DSLs. They are very easy to manipulate/optimize in a simple
algebraic manner without issues related to named variables. This proposal
showed how a plugin could take ordinary programs written in more user friendly
syntax and compile it to the category IR. You can overload ordinary programs
to automatically differentiable programs and more.
[http://conal.net/papers/compiling-to-
categories/](http://conal.net/papers/compiling-to-categories/)

Another thing I think is really interesting is calculating programs. It is
possible in the right formalism to write down a specification of a program in
a simple small form, and use algebraic manipulation to derive an executable
form of the program. It feels like doing an integral or something. Check out
these books on that topic.
[https://themattchan.com/docs/algprog.pdf](https://themattchan.com/docs/algprog.pdf)
[http://www4.di.uminho.pt/~jno/ps/pdbc.pdf](http://www4.di.uminho.pt/~jno/ps/pdbc.pdf)

~~~
runeks
Great example!

Here’s a video where Conal demonstrates interpreting a Haskell program (actual
Haskell, not a DSL) into a) an image of a graph-like structure (visualizing
the algorithm), b) Verilog (for compiling to hardware), and c) GLSL (for being
rendered by a GPU in the browser).

[https://youtu.be/vzLK_xE9Zy8](https://youtu.be/vzLK_xE9Zy8)

------
reykjavik
Watched that guy's lectures and conference talks. While it's quite interesting
and educative - I still don't get the "for programmers" part of it. I don't
quite get how I would jump from understanding categories, morphisms, monoids
etc. to building actually better systems. There are zero practical examples in
his talks. Is it because i'm not using functional languages or what am I
missing here?

~~~
crimsonalucard
I watched the first part of his lectures on category theory. Keep in mind I'm
the furthest thing from a mathematician you can find.

The feeling I'm getting when learning category theory is that if there was a
formal theory for how to design programs. Category theory is it. Application
is therefore not straightforward... You have to get really creative and think
really hard to see the insights that category theory has to offer.

The notion of a isomorphism and a functor and lifting was directly applicable
to programming after I learned about it. Here's what happened:

In postgresql there are specific library functions for dealing with specific
types of json structures in the postgresql library. If your json blob doesn't
fit the structured type parameter that the library function accepts you have
to do some very awkward joins to convert the json into the right format which
can cause massive slow downs.

I use the notion of two isomorphic objects and the opposing functors between
them to convert the json into a string functor. Then I did string
manipulations to convert the serialized json into a different form of
serialized json then re-lifted the serialized json back into the json functor.
The converted json type fit the parameter of a library json function and thus
the result was a query that executed 10x faster then the other implimentation.

If I didn't know category theory the code would look absolutely crazy. I cast
json to a string, replace a bunch of characters in the string then cast it
back to json. The notion that a string can contain another type as a functor
and the notion that string manipulations operations on serialized json have an
isomorphic equivalent in "json space" was what allowed me to creatively come
up with this optimization.

Note that the json equivalent morphisms I needed do not actually exist in the
postgresql implimentation but because of the isomorphism that exists between
stringified json and actual json I can build the json morphisms I need by
composing two opposing functors and a string manipulation operation.

The thing about this though is that it's debatable whether or not you would
actually need such "creativity" in a language that wasn't as terrible as SQL.

~~~
philzook
Check out Program Design by Calculation and The Algebra of Programming.
Category theory and related formalisms do have a strong case to being a formal
theory for designing/calculating programs

[http://www4.di.uminho.pt/~jno/ps/pdbc.pdf](http://www4.di.uminho.pt/~jno/ps/pdbc.pdf)
[https://themattchan.com/docs/algprog.pdf](https://themattchan.com/docs/algprog.pdf)

~~~
crimsonalucard
Super interested in this and thanks for posting. Your first link is dead
though. Do you have an alternative?

~~~
feanaro
[http://web.archive.org/web/20190519200157/http://www4.di.umi...](http://web.archive.org/web/20190519200157/http://www4.di.uminho.pt/~jno/ps/pdbc.pdf)

~~~
philzook
Yes, thanks for this. It appears that maybe the entire university's website
has changed location? So maybe a more official link will come back up soon

------
westoncb
The clearest and most concise treatment I've come across on how Category
Theory is used is Tai-Danae Bradley's "What is Applied Category Theory":
[https://arxiv.org/abs/1809.05923](https://arxiv.org/abs/1809.05923) (It's a
50 page PDF)

Unfortunately the examples aren't within CS, but at least for me personally,
seeing it _clearly_ applied in any context was the most important thing. It
may be a good pre-req for looking at (or conjuring up your own) more detailed
applications within CS specifically.

Also, if you like that, Tai-Danae Bradley has more writing at:
[https://www.math3ma.com/](https://www.math3ma.com/)

~~~
knzhou
I'm familiar with the applications here, and I've never found them compelling.
They amount to taking things we already understand perfectly well (chemical
reactions, written in terms of differential equations or visualized in terms
of graphs) and draping huge amounts of formalism around them. The "theorems"
they then prove do not provide any new insight -- they're only called theorems
because the excess formalism makes completely trivial things hard to see!

For example, the main theorem of one of Baez's very long papers is:

> There is a symmetric monoidal functor from the category Petri to the
> category Dynam.

When you plug in the hundred relevant definitions, you find that this is
literally just the statement that you can specify a chemical reaction network
in terms of differential equations, or pictorially in terms of graphs where
the edges represent reactions, which is a standard thing taught in ordinary
chemistry classes. The language of categories is not achieving anything here
but obfuscation.

Category theory is only good when there's a very rich preexisting mathematical
structure, so that introducing it simplifies things. That usually isn't true
in science.

~~~
westoncb
I think you may be missing something here.

> The "theorems" they then prove do not provide any new insight

Knowing that you can model reaction networks using categorical concepts may
not provide new insights IF you have no deep familiarity with those
concepts—but if you do, then knowing there is a "symmetric monoidal functor
from the category Petri to the category Dynam" is a richly useful piece of
information. It's probably more accurate to say that the amount of new insight
conferred is proportional to your familiarity with the categorical concepts.

And yes, it's true the concepts are 'just' being translated into a new
language—but if this new language is extremely general, applicable to a wide
range of domains, then:

1) You can build a set of skills and knowledge related to concepts in this
general language, which become automatically applicable to a wide range of
domains (when their concepts are imported into the language).

2) It's possible to build 'machinery' (i.e. theorems or software) which deals
with / operates on (representations of) concepts from this very general
language—so once again, if you can translate some concept from domain X into
e.g a symmetric monoidal category, now your general machinery can operate on
things from domain X (which it was built with no awareness of).

Additionally, at least in Bradley's paper, the point wasn't to prove new
things about e.g. reaction networks; instead it was to illustrate a method. To
be more specific she is showing how "functorial semantics" can be applied in
this context, using Petri nets as the syntax and dynamical systems as the
semantics. From there the categorical classification of these objects gives us
guarantees on their behavior under composition (the utility of which I assume
is clear).

I'm not sure in the context of reaction networks whether modeling the system
with compositionality guarantees and a clean mapping between graph
representation and differential equations gives scientists something new or
not—but the illustration of this method is done clearly, and the generality of
the method is enormous.

And maybe I'm also missing something. I'm not a mathematician, but that's how
the situation looks to me.

~~~
knzhou
> Knowing that you can model reaction networks using categorical concepts may
> not provide new insights IF you have no deep familiarity with those
> concepts—but if you do, then knowing there is a "symmetric monoidal functor
> from the category Petri to the category Dynam" is a richly useful piece of
> information.

Look, I completely agree with the general point. I love new ways of thinking
about things. But blindly applying extremely complicated tools to domains
where their power isn't helpful is not good.

What is happening here is like taking a 2-line program that adds together two
numbers and dressing it up into thousands of lines of OOP, until you have
AdditionObjectFactoryGetterSetter objects being created by
AdditionObjectFactoryGetterSetterFactory objects. Then you can bring in
powerful OOP tools, but the _only_ things they help you with are understanding
the excess complication you added in. Maybe the sheer scale of that structure
is beautiful to someone, but we're discussing whether scientists should bother
learning it.

> I'm not sure in the context of reaction networks whether modeling the system
> with compositionality guarantees and a clean mapping between graph
> representation and differential equations gives scientists something new or
> not

And I'm telling you, it really doesn't! There simply is not a rich enough
formal structure present in chemical reaction networks for category theory to
yield anything useful, like it did in parts of pure math. Adding a complicated
structure on top of something simple does nobody any good. All of the
"guarantees on compositionality" were not useful, in the sense that they _went
without saying_ in freshman-level courses, or worse, were problems solely
_created_ by the introduction of category theory.

> the illustration of this method is done clearly, and the generality of the
> method is enormous.

The fact that the technique is extremely general does not improve things. If a
technique makes science harder to do, you can't make it up on volume.

~~~
feanaro
> What is happening here is like taking a 2-line program that adds together
> two numbers and dressing it up into thousands of lines of OOP, until you
> have AdditionObjectFactoryGetterSetter objects being created by
> AdditionObjectFactoryGetterSetterFactory objects. Then you can bring in
> powerful OOP tools, but the only things they help you with are understanding
> the excess complication you added in. Maybe the sheer scale of that
> structure is beautiful to someone, but we're discussing whether scientists
> should bother learning it.

In my opinion, this severely misrepresents what's happening. Your example is
simply adding extrinsic, incidental complexity and this is not what the
categorical treatment of this is doing, in my opinion. The additional
complexity introduced by the CT machinery is not a lot and most of the
complexity is intrinsic to the problem.

~~~
feanaro
Argh, I wrote this in an editor and accidentally posted only a partial
response. I cannot edit anymore so I'm responding with the full comment:

> What is happening here is like taking a 2-line program that adds together
> two numbers and dressing it up into thousands of lines of OOP, until you
> have AdditionObjectFactoryGetterSetter objects being created by
> AdditionObjectFactoryGetterSetterFactory objects. Then you can bring in
> powerful OOP tools, but the only things they help you with are understanding
> the excess complication you added in. Maybe the sheer scale of that
> structure is beautiful to someone, but we're discussing whether scientists
> should bother learning it.

In my opinion, this severely misrepresents what's happening. Your example is
simply adding extrinsic, incidental complexity and this is not what the
categorical treatment of this is doing, in my opinion. The additional
complexity introduced by the CT machinery is not a lot and most of the
complexity is intrinsic to the problem.

What this does is to add rigor to something that you (or a chemist) may
understand intuitively. To a person with a working, intuitive knowledge about
a subject, that may seem a bit pointless, but it is nevertheless useful since
an intuitive understanding might overlook reasoning holes or edge cases.
Building upon this result may yield further useful insights.

Granted, this really may not be useful to a working chemist. The cost/benefit
ratio of a chemist doing chemistry is more favourable than investing a lot of
time in CT, hoping for a large breakthrough.

------
playing_colours
I liked “An Invitation to Applied Category Theory“, pdf is available here: [1]

It is written in a more terse, mathematical language, but it is very clear and
friendly for non-mathematicians. The authors provide interesting examples of
applicability. Hardcover is quite expensive, but the quality is great [2].

[1]
[http://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf](http://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf)

[2]
[https://www.amazon.com/gp/aw/d/1108482295](https://www.amazon.com/gp/aw/d/1108482295)

~~~
rubyn00bie
I've quite literally spent the last month trying to read, digest, and apply
the above to a record layer I'm writing for FoundationDB. Dr. Spivak's work
has been absolutely beyond helpful and insightful. There's no way I'd even be
able to approach the subject with his efforts.

I'd also recommend these as they're associated with the 7 Sketches and help
fill in some blanks:

Functorial Data Migration -
[https://arxiv.org/pdf/1009.1166.pdf](https://arxiv.org/pdf/1009.1166.pdf)

Category Theory as a Unifying Database Formalism -
[https://arxiv.org/pdf/1009.1166.pdf](https://arxiv.org/pdf/1009.1166.pdf)

Database Queries and Constraints via Lifting Problems -
[http://math.mit.edu/~dspivak/informatics/LiftingProblems.pdf](http://math.mit.edu/~dspivak/informatics/LiftingProblems.pdf)

Additionally, there's also
[https://www.categoricaldata.net/](https://www.categoricaldata.net/) which
helps provide more actualized implementation details of "FQL" (Functional
Query Language) which he mentions in his papers.

For anyone else looking to get started with Category Theory, I'd also highly
recommend choosing a functional library (i.e. something with Applicative,
Functor, Category, Monad, Semigroup, Semgroupoid, Comonad, etc) in whatever
language you're most familiar with and then _re-implement_ the functions to
learn what it's doing (and what properties each class of item must conform
to). In Elixir, I've been using Witchcraft...
github.com/witchcrafters/witchcraft

For me, it has helped a great deal by forcing me to think about things like
associativity, identity, and composition which I normally... didn't really do.
It lends some nice patterns and naming conventions, even if you don't adhere
to them perfectly. After a month of category theory, and only a
crude/rudimentary understanding of it, has been enormously beneficial. My
refactor of my FDB record layer after category theory has less code, works
more correctly, and has more features. It's crazy...

Category theory gets 10/10 from me.

P.S. You'll probably, at some point, want to learn a little Haskell to help
elucidate things in a "pure" context. It also helps as most every functional
library is modeled after Haskell's standard library (? I'm still new, heh). To
get started, this will save you time, as it seems most things in the Haskell
world now-a-days be using this to setup/manage applications:
[https://docs.haskellstack.org/en/stable/README/](https://docs.haskellstack.org/en/stable/README/)

~~~
tome
Since you sound like you're from the category theory community you may already
know this, but my database library Opaleye is directly based on David Spivak's
ideas.

[https://hackage.haskell.org/package/opaleye](https://hackage.haskell.org/package/opaleye)

~~~
rubyn00bie
I'm totally new to the community! So I have no idea about almost anything I
didn't link to or isn't linked here, ha.

That is a freakin' awesome link, thank you so much! Though, it'll probably
mean yet another rewrite of my record layer :) (at learning is fun)

~~~
tome
Feel free to email me if you have any questions around Haskell/category
theory/databases. My email address is linked in the Opaleye README.

(BTW I meant "sounds like you're from the _Haskell_ community" ... thinko)

------
dang
A thread from 2017:
[https://news.ycombinator.com/item?id=14026360](https://news.ycombinator.com/item?id=14026360)

A bit more:
[https://news.ycombinator.com/item?id=15372856](https://news.ycombinator.com/item?id=15372856)

2015:
[https://news.ycombinator.com/item?id=9459520](https://news.ycombinator.com/item?id=9459520)

------
jesuslop
Also released today, "Notes on Category Theory with examples from basic
mathematics" by Paolo Perrone. (preprint state). arXiv:1912.10642v1

~~~
darkkindness
Nice find!

Abstract:

> These notes were originally developed as lecture notes for a category theory
> course. They should be well-suited to anyone that wants to learn category
> theory from scratch and has a scientific mind. There is no need to know
> advanced mathematics, nor any of the disciplines where category theory is
> traditionally applied, such as algebraic geometry or theoretical computer
> science. The only knowledge that is assumed from the reader is linear
> algebra. All concepts are explained by giving concrete examples from
> different, non-specialized areas of mathematics (such as basic group theory,
> graph theory, and probability). Not every example is helpful for every
> reader, but hopefully every reader can find at least one helpful example per
> concept. The reader is encouraged to read all the examples, this way they
> may even learn something new about a different field.

> Particular emphasis is given to the Yoneda lemma and its significance, with
> both intuitive explanations, detailed proofs, and specific examples. Another
> common theme in these notes is the relationship between categories and
> directed multigraphs, which is treated in detail. From the applied point of
> view, this shows why categorical thinking can help whenever some process is
> taking place on a graph. Form the pure math point of view, this can be seen
> as the 1-dimensional first step into the theory of simplicial sets. Finally,
> monads and comonads are treated on an equal footing, differently to most
> literature in which comonads are often overlooked as "just the dual to
> monads". Theorems, interpretations and concrete examples are given for
> monads as well as for comonads.

pdf: [https://arxiv.org/pdf/1912.10642](https://arxiv.org/pdf/1912.10642)

------
whatshisface
Is there any point in learning category theory without first learning the
things that it generalizes? I didn't see any value in learning about geometric
algebra until I had learned enough about complex analysis to appreciate what
it would mean to connect it with vector calculus.

~~~
lgas
I think category theory generalizes pretty much everything, so that may be
tough.

~~~
whatshisface
The only thing that can generalize everything is something with no structure
of its own.

------
wellpast
Started reading this and was disappointed to find the same disingenuous claims
about strong static type systems.

I say disingenuous because the people that espouse these beliefs seem to have
a minimum modicum of intelligence and do or would certainly (after a moment of
reflection) certainly realize their fallacy:

> The only serious argument I hear against strong static type check- ing is
> that it might eliminate some programs that are semantically cor- rect. In
> practice, this happens extremely rarely and, in any case, every language
> provides some kind of a backdoor to bypass the type sys- tem when that’s
> really necessary.

This is patently false. Port a correct dynamically typed program to Haskell
and it will certainly fail until you satisfy the type checker through no small
_extraneous_ effort. And this is not a theoretical matter; it is an enormous
cost to the programmer that is not there in weaker or non- typed systems.

It is a certainty that type systems ask for far more than is needed to produce
correctness. Anyone who tries to dodge this obvious and fundamental truth is
operating off of a religious not rational commitment to defending their type
system. Note that I am not saying the type system doesn't _give you something
back_ but it certainly comes with a _inherent_ cost over alternatives.

> Another argument I hear a lot is that dealing with types imposes too much
> burden on the programmer. I could sympathize with this sen- timent after
> having to write a few declarations of iterators in C++ my- self, except that
> there is a technology called type inference that lets the compiler deduce
> most of the types

This is the most heinous and sad lie. Type inference changes nothing. The
types are there even if you don't have to type them in and they are
significantly constraining your set of accepted programs.

I've heard this response before from seemingly smart static typers. I just
can't believe a smart person would not see the obvious emptiness of this
claim. There is no way anyone would think that _having to type characters_ is
the exclusive cost of static typing that inference suddenly whisks away.

I want to buy into the strong static typist's promise of utopia but I have yet
to meet a static typist enthusiast that doesn't parlay in these lies,
wittingly or unwittingly.

Because of this I have a serious suspicion that there is nothing else to stand
on and that strong static typing is simply a case of the Emperor's New
Clothes. Prove me wrong.

~~~
tome
> > The only serious argument I hear against strong static type check- ing is
> that it might eliminate some programs that are semantically cor- rect. In
> practice, this happens extremely rarely and, in any case, every language
> provides some kind of a backdoor to bypass the type sys- tem when that’s
> really necessary.

> This is patently false. Port a correct dynamically typed program to Haskell
> and it will certainly fail until you satisfy the type checker through no
> small extraneous effort. And this is not a theoretical matter; it is an
> enormous cost to the programmer that is not there in weaker or non- typed
> systems.

It seems like this disagreement should be easy to resolve. You are saying that
it's hard to satisfy the type checker when porting a dynamically-typed
program; OP says this happens very rarely. Therefore you can easily disprove
OP's claim by providing some examples that happen commonly in practice.
Provide them, please!

> There is no way anyone would think that having to type characters is the
> exclusive cost of static typing that inference suddenly whisks away.

OP is not claiming that the benefit of type inference is that it automatically
"types characters".

> I have yet to meet a static typist enthusiast that doesn't parlay in these
> lies

I don't think it's necessary to bring a moral dimension into this discussion.
Let's keep it technical please.

~~~
wellpast
> It seems like this disagreement should be easy to resolve. You are saying
> that it's hard to satisfy the type checker when porting a dynamically-typed
> program; OP says this happens very rarely. Therefore you can easily disprove
> OP's claim by providing some examples that happen commonly in practice.
> Provide them, please!

Great, let's stay in a weakly typed language -- and give the smallest of
examples. This is so easy to come by it should be obvious that extrapolating
this up to real business systems greatly magnifies cost. Here's weakly typed
Java:

    
    
       Function<String, Integer> countChars = str -> str.length();
    

That's a function that counts characters in a string. It compiles. Now let's
drop the types:

    
    
       Function countChars = str -> str.length();
    

That is a correct definition of the same function but it doesn't compile. The
compiler needs information to carry out its proof.

This extrapolates to infinite more examples and the cost in building actual
business systems is profound.

Now carry this to a strongly typed system.

The general claim is that type inference will allow the second form to somehow
magically pass the compiler.

Not true.

The type inference _requires_ `length` to be formally declared before the
compiler can pass the program. I.e., the compiler must be told about the types
_somewhere_.

In a dynamically typed language I can late bind `length`; ie the compiler
doesn't need to be "told" something that I, the programmer, have got fully
covered by my own measures.

But the compiler doesn't know this. I've already done _my_ proof of
correctness (as I should). But because the compiler does not have context, I
have to tell it something that has no innate value to me and what I'm
delivering -- it only has value to the closed-room of the compiler. This is
hostile to productivity and serves only my early commitment to having a type
prover guard my every move.

------
philzook
People who like this may also be interested in the awesome applied category
theory list [https://github.com/statebox/awesome-applied-
ct](https://github.com/statebox/awesome-applied-ct)

~~~
philzook
And Conal Elliott's Compiling to Categories, which I've seen discussed here
before [http://conal.net/papers/compiling-to-
categories/](http://conal.net/papers/compiling-to-categories/)

------
furcyd
or:

[https://bartoszmilewski.com/2014/10/28/category-theory-
for-p...](https://bartoszmilewski.com/2014/10/28/category-theory-for-
programmers-the-preface/)

or 20-video lecture series:

[https://www.youtube.com/playlist?list=PLbgaMIhjbmEnaH_LTkxLI...](https://www.youtube.com/playlist?list=PLbgaMIhjbmEnaH_LTkxLI7FMa2HsnawM_)

~~~
walleeee
Highly recommend the lecture series. He makes it accessible and fun

~~~
guerrilla
Seriously, second this. It was extremely helpful. I had both the background in
programming and abstract algebra but it wasn't until this course that I was
really on the path to understand what was going on with category theory.

------
Y_Y
Worth it just for the illustrations, but this book is excellent, especially if
you already know Haskell.

------
xvilka
The book itself is constantly updated by the author and community, people add
particular language flavors. Scala flavor[1] (along with the original Haskell
one) is already part of the book, OCaml flavor[2] is being worked on and
mostly finished.

[1] [https://github.com/hmemcpy/milewski-ctfp-
pdf/releases/tag/v1...](https://github.com/hmemcpy/milewski-ctfp-
pdf/releases/tag/v1.3.0)

[2] [https://github.com/hmemcpy/milewski-ctfp-
pdf/pull/201](https://github.com/hmemcpy/milewski-ctfp-pdf/pull/201)

------
heinrichhartman
Question to all CS majors, that invested in learning Category Theory:

Did you have any concrete take aways from learning it?

( I have a math background, and struggle to find something concrete. Maybe I
am just blind. )

~~~
davidxc
I believe my real analysis class made me a significantly better programmer and
thinker in general, but I don't use anything specific from it (not yet,
anyway).

~~~
BeetleB
Genuinely curious how real analysis made you a better programmer...? I've
taken it and loved it, but my interest was more due to physics/engineering
applications. I can't see a connection to programming.

~~~
atq2119
I suspect it could be that real analysis truly makes you challenge your
assumptions and forces you to build a habit of thinking through corner cases.

Other maths courses do this as well, but real analysis is particularly vivid
for some people because of all the fun counter-examples you get to see in a
well-taught course, such as a function that is everywhere continuous but
nowhere differentiable.

This habit of thinking through corner cases is something I miss from a lot of
(junior) programmers.

------
auggierose
I very much like: "Sets for Mathematics", which I currently read and which
finally clicks with me. I always found expositions of category theory tiring
in that it bombarded me with trivialities and examples that were kind of
obvious. Instead, "Sets for Mathematics" describes one particular and probably
the most familiar and important category, the category of sets, and I very
much like this fresh look at sets.

------
mathgenius
Here's a really great introduction to CT for the non-mathematically inclined:

Lawvere and Schanuel. "Conceptual mathematics: a first introduction to
categories." Cambridge University Press, 2009.

The authors are two of the "founders" of the subject, so don't be fooled by
the elementary appearance of this book.

------
smcl
There's a lecture series he did if anyone's interested:
[https://www.youtube.com/watch?v=I8LbkfSSR58](https://www.youtube.com/watch?v=I8LbkfSSR58)

I must say that there is a slight Tommy Wiseau energy about the guy, but
that's no bad thing :-)

------
jokoon
I wish some subjects of mathematics could be summarized in a TLDR fashion. It
would make it much more interesting as an introduction.

I remember that we used to write very small sheets of formulas and other memos
to condense a class into a much shorter thing.

Simple.wikipedia.org seems to somewhat be that.

I have always liked math, but I can see why people don't like math or get
interested in math. The literature is exhaustive, unnecessary long, and just
too arcane.

I will always be frustrated with the image of mathematics and how laymen often
say "math is not for me", but sometimes I can understand why.

------
SensateCreature
Also by the same author: Applied Category Theory 2020

[https://johncarlosbaez.wordpress.com/2019/12/23/applied-
cate...](https://johncarlosbaez.wordpress.com/2019/12/23/applied-category-
theory-2020-adjoint-school/)

