> Implement, as best as you can, the identity function in your favorite language (or the second favorite, if your favorite language happens to be Haskell).
def identity(x): return x
> Implement the composition function in your favorite language. It takes two functions as arguments and returns a function that is their composition.
How accessible is the book (the google preview on that page does not help assessing how complex the text is) ? I guess it's better to start with "Types and programming languages" by the same author ? I don't have a formal education in these topics.
If anyone is interested in a very good and accessible introduction to category theory that is not specifically geared towards programming I can highly recommend the book Conceptual Mathematics by Lawvere and Schanuel. It's very easy-going and can be read by someone in highschool, and it really teaches you how to think categorically about the world.
"If you’re an experienced programmer, you might be asking yourself: I’ve been coding for so long without worrying about category theory or functional methods, so what’s changed? Surely you can’t help but notice that there’s been a steady stream of new functional features invading imperative languages. Even Java, the bastion of object-oriented programming, let the lambdas in. C++ has recently been evolving at a frantic pace — a new standard every few years — trying to catch up with the changing world. All this activity is in preparation for a disruptive change or, as we physicist call it, a phase transition. If you keep heating water, it will eventually start boiling. We are now in the position of a frog that must decide if it should continue swimming in increasingly hot water, or start looking for some alternatives."
In other words, if you think this isn't relevant to the programming you do, it is likely that the programming you do is the exact kind of programming this was written to be relevant to.
That's a non sequitur. "Functional" doesn't imply having anything to do with category theory. You can learn functional programming (even including theoretical type theory, etc.) without knowing literally anything about category theory.
The author doesn't say it so I will: Category Theory is like a treasure map to FP. Possibly many other systems interesting to programmers too—circuits, optimization, DSLs, API design, etc. CT is not required for practicing FP, but it can be a powerful guidepost to solving problems. A good CT intuition will lead you to recognize opportunities for nice abstraction in a way that's difficult to replicate otherwise. It'll also give you a tool belt for communicating them to others without any arm-waving. All together that's a powerful thing.
This is like saying Tsiolkovsky rocket equation is the core of rocket science. You are not exactly wrong, but it's just one piece of the puzzle. You need to study math and algebra more broadly if you want to see and use categories solving problems.
If FP community would advocate big math curriculum for programmers with category theory at the top, hype would die fast.
I think that for many programmers there are sufficient applications of CT in their own work that learning it would be a boon. I don't at all disagree that that learning algebra more broadly here is beneficial, too, though!
And hell, you can be absolutely certain that I'd advocate a big math curriculum for programmers with category theory at the top. I don't know that the ROI is there for everyone, but I couldn't not recommend such a thing heartily.
Learn abstract algebra, as a programmer? Of COURSE that will help you.
I'm willing to believe that in the end it will all have been worth it. But I didn't find that enough to continue reading this particular series because after a while it didn't seem to be motivated by any useful problems for programmers, as was promised in the title.
Here's my heuristic for whether a problem makes a good example: whether or not it's the best tool for the job, would you write a program to solve it in C or Java or Go? If not, I'm skeptical it's solving a problem that exists outside the functional programming universe.
There are plenty of techniques that solve problems that only make sense within the particular ecosystem where you find them; lots of Java tools are like that, for example.
That does not change the fact that category theory is oversold to programmers.
You need to study math more broadly to use category theory. These intros and books for programmers just give overview of concepts. You need to study mathematics more deeply to actually use it in programming. Advanced algebra is must.
the preface sold me - I sure want to learn more about it!
after reading the first 3 chapters, I thought: that's not new I compose category's since I started programming!
Train reached its destination, can't wait to discover more about that category point of view.
Pretty good series, using Haskell (it has a pretty decent type system and the type syntax is easy to understand, OCaml's is a bit more confusing) for the examples. Great coverage as well on types and category theory.
This site has nearly black serif type on a peach-ish white background. The layout, type choice, and color scheme seems to address pretty much every objection that I've seen the "I can't read light-colored text on any background" crowd advance.
I agree with the readability issue. The small text is part of it, but I can zoom to adjust that. However, the square alignment is the bigger concern and something I can't quickly remedy as a reader.
I'm asking these questions out of a genuine sense of inquisitiveness and an earnest desire to understand what's going on here. I have no desire to belittle or criticize. I'm just confused and quizzical.
What do you mean by "square alignment"? Are you talking about the full-justified [0] body text? If you are, then:
1) This confuses me, as this is exactly what the "I can't read light-colored text on any background" crowd says that studies show improves readability.
2) What about the full-justified body text makes it difficult to read?
If you're not talking about the body text, then what are you talking about?
Kerning is a good thing, it increases readability. In a perfect world everything would be hand kerned for the best results, but that's not realistic. The compromise is automatic kerning, which isn't as good, but isn't too shabby. However, when you full justify text you're forcing the computer to abandon its best attempt at good kerning. Like newspaper on silly putty it gets stretched into spacings that aren't clean. Even if it leaves the spacings between letters untouched that forces it to make large and uneven spacings between words.
Some people might prefer that, and some people might prefer copy set to look like random letters. It's hard to have generalized rules that fit everyone. In general though I think it the standard position taught typography is to not justify text except in special situation.
> Implement, as best as you can, the identity function in your favorite language (or the second favorite, if your favorite language happens to be Haskell).
> Implement the composition function in your favorite language. It takes two functions as arguments and returns a function that is their composition. Testing these out: