I love category theory, but I think there's a secret category of "high effort programming things" that programmers who have done them love to say that "Everyone should do x because it will make them a better programmer".
Here's the kind of things I'm thinking of:
- Learn category theory
- Build an interpretter/compiler
- Develop your own programming language
- Learn about and built distributed systems
- Learn to write code for the GPU
- Understand assembly code
- Learn about CPU architecture
I think, especially since it's the holiday season, maybe lets take a step back and just accept these things probably will make you a better programmer, but there are lots of them. If you do all of them, you'll maybe become a very good programmer, but you'll definitely become a very tired human being.
If you have an interest in the mathematical underpinnings behind some of the ideas in Haskell et al, you might love category theory, but if you just want to do effective functional programming effectively, you're fine just doing that
Every other item in your list is actually used to produce technology except one.
Compilers? Used to produce executables form source code.
Programming language? Allows us to write code using higher abstraction.
Distributed systems? Allows us to build systems across multiple machines, users, continents, etc.
GPU? Allows us to speed up heavily parallel code for graphics and scientific applications.
Assembly? Allows us to write closer to the hardware.
CPU architecture? Allows us to understand what our code runs on.
If anything, this list shows how category theory is not like the other things programmers could spend time on. If the goal is “learn a bunch of math to expand your math skill”, then maybe category theory makes sense. If the goal is to become a better programmer then I think there are better uses of time.
I suppose that's true - but then I would suggest that type systems are (at least to some extent) the application of category theory.
It's hard to see how learning about Hindley-Milner type inference isn't academic type theory (which I'd argue is a category theory subfield) but applying Hindley-Milner type inference is clearly practical and related to producing technology.
I'm not saying all branches of category theory have a section that relates to directly producing technology, but I'd definitely argue that some do.
Here's the kind of things I'm thinking of:
- Learn category theory
- Build an interpretter/compiler
- Develop your own programming language
- Learn about and built distributed systems
- Learn to write code for the GPU
- Understand assembly code
- Learn about CPU architecture
I think, especially since it's the holiday season, maybe lets take a step back and just accept these things probably will make you a better programmer, but there are lots of them. If you do all of them, you'll maybe become a very good programmer, but you'll definitely become a very tired human being.
If you have an interest in the mathematical underpinnings behind some of the ideas in Haskell et al, you might love category theory, but if you just want to do effective functional programming effectively, you're fine just doing that