Category Theory for Programmers: Chapter 1 - Category

PL Virtual Meetup: www.meetup.com/Programming-La...
CtFP Textbook: github.com/hmemcpy/milewski-c...
Github Repo: github.com/codereport/CtFP-2021
Ben Deane's Identifying Monoids: • C++Now 2019: Ben Deane...
Rich Hickey's Simple Made Easy: • Video
Combinator Birds: github.com/fantasyland/fantas...
Functional C++ Talks: github.com/graninas/cpp_funct...
PLVM Discord: / discord
PLVM Twitter: / plvirtualmeetup
Follow me on Github: github.com/codereport
Follow me on Twitter: / code_report
Follow me on LinkedIn: / codereport

[@taylorallred6208]

A teacher of mine once said that a good programming language is one where a given piece of code has more *intentional* parts than *incidental* parts. I think that's one way to look at the expressiveness of the Haskell and APL solutions vs C++.

[@bhz8947]

Nothing about expressive power, orthogonality, readability, consistency, memory safety, error handling, terseness, or anything’s else, just how “intentional” the design was. Interesting...

[@foxoninetails_]

@@bhz8947 While those things are certainly important, the quote is speaking to a very specific and abstract kind of "good" which indirectly improves the other metrics you mention. For example, a language that tends to involve a lot of incidental code will also tend to be less readable, less consistent, and drastically less terse than one with a higher "ratio of intentionality", if you will. No single metric is ever going to completely encompass the entirety of what makes something as complex as a programming language good, but the idea of comparing intentional and incidental code is not one without merit; the less of your code by volume is "ritual" rather than useful meaning, the easier that code typically becomes to write and maintain.

[@AlexRodriguez-gb9ez]

Dunno, man sometimes I don't know what I intend to code that well, so languages like the LISPs that let me change a piece of code to do something completely different to what I started with are good, but maybe I am unenlightened.

[@user-tx4wj7qk4t]

​@@bhz8947lol imagine being you

[@azatkadyrov3634]

Wow, i have been reading this book along with Bartosz Milewski's Series for half a year now. And now with your series, it's a nice way to internalize those concepts once more. Thanks for your effort!

[@code_report]

Sorry if the audio sounds a bit clippy (will fix for next time)

[@SirMeowric]

Bartosz makes heavy videos, so good thing you're doing this read-along.

[@kostasgkoutis8534]

I barely can believe this video series exists. Thanks so much!

[@williamb.2031]

Just started reading this! Perfect timing!

[@jannik8664]

Amazing stuff! Please keep these videos going 🙏 very important for the European audience that can't make it due to timezone differences

[@hendrikdevloed]

Thanks for sharing the prerecorded presentations! I'm also unable to attend the live events due to time zone shift (CET) and would hate to miss out on the opportunity to follow the course.

[@tommybandzaw5865]

Great start! I’ll follow along! Love your APL examples. I guess I should get a copy of that Mastering Dyalog APL book. Also, regarding next book, my vote goes to the EoP book, Elements of Programming. That would be an awesome challenge!

[@capability-snob]

Starting a Bartosz video with an Inigo Montoya meme is so sublimely meta

[@tricky778]

Love the clip of Bartosz Milewski at the start of your video

[@VRchitecture]

As an ornithologist I’m in love with these combinatoric birds! 😌

[@insertoyouroemail]

Don't skip the comparison between modern software development and the construction of the old cathedrals!

[@BeansEnjoyer911]

APL. For when you know APL. But definitely NOT for when you don't know APL.... I feel J is much easier to understand without knowledge of the language. And Haskell is all around just perfect.

[@JohnCorley13]

im so happy about this!

[@harshrathod50]

I learnt that we can only keep 7 ± 2 things in our head. 🤓

[@olekslitus]

Thank you

[@dhuxdheerdahir2736]

Thank you.

[@angeldude101]

"Implement in your favourite programming language." Well mine is rust, which doesn't seem like much except it has this little tiny hiccup: There is no single "function from a to b" type. Every function is a distinct type. The best you can actually do is a parameterised function that is polymorphic over function _types_ and you can't even say what the output type is. Only that it implements to contract of a function from a to c. What does this mean in terms of Category Theory for "function from a to b" to not be a type, but rather a type class? (Technically it's _three_ type classes due to Rust's strict control of aliasing and mutability.)

[@tytrdev]

Holy shit the intro had me rolling.

[@stephenjames2951]

Examples in apl are not conducive to making the bridge to category theory.

[@dewijones92]

thanks

[@tricky778]

Which book has the best foundational coverage?

[@mastershooter64]

are infinity-categories used in programming?

[@dancingcactus5271]

I don't write C++ but wouldn't the idiomatic version of [x + 1 for x in reversed(array)] (python) be something more like a loop that performs the operation in a single pass?

[@dancingcactus5271]

Would be interesting to see if the compiler simplifies it down to a single pass.

[@tejarex]

If the array type has a __reversed__ method, as at least list and range do, but tuple does not, then there is one iteration.

[@alexanderskusnov5119]

The next should be DirectX 12 (Frank Luna) - a way to a high-speed 3D graphics.

[@TrackballClick]

Haskell would be a great choice as a language, but I don't like the workflow around GHCI, it makes impossible(at least to me) to build an app to target multiple platforms. I cannot solve to have dynamic libraries, therefore remains to write big-bang-monolithic app or a web of microservices. I would like to build in plugin architecture to be able to load/unload (update) certain parts. Not to mention, that I don't see fit to firmware development as much as a C++ it does already.

[@user-tx4wj7qk4t]

PureScript has c++ ffi

[@tcnymex]

this has almost (but only almost) answered a question I had a couple of years ago "Roger, why do I need left tack and right tack, when I can just wrap the stuff to the left in parentheses or curly braces?" maybe you could go over that in the next video. also is 1+rotate really a composition? whatever you put on the right of the rotate is going to be returned as an array which will then serve as the right argument to a diadic +, the left argument of the + is the scaler constant 1. that's more like strand notation or piping than composition. wouldn't a composition be something like foo leftarrow +jot rotate, and now Foo is truly a new function

[@code_report]

**I think** you are correct about 1+rotate not being composition (note I didn't use ∘). I honestly don't know what it is. I think of APL having two types of composition - composition via ∘ (aka compose) and composition via juxtaposition. This is the latter. But this is just my mental model that I am sure if wrong. Also, ∘ can be used for partial application as well - when you do something like: 1∘+¨2,/⍳5. If there is an APL-er language lawyer that reads this and knows the precise differences I would love to know.

[@tcnymex]

@@code_report @code_report I'm on an Android phone so I can't check, but I'd be curious to know if "1jot+ each 2 RavelReduce iota 5" returned a simple numeric vector, or a nested numeric vector. i.e. does " ]disp " draw boxes around the result of that expression

[@tcnymex]

@@code_report by the way, how did you get APL characters to appear on my Android phone?

[@code_report]

@@tcnymex It is a nested array: tryapl.org/?clear&q=1%E2%88%98%2B%C2%A82%2C%2F%E2%8D%B35&run

[@code_report]

@@tcnymex It is just unicode characters, so it should display fine in most apps.

[@broccoloodle]

why would haskel and apl use (1+) for the function f(x)=x+1? isn't it confusing with (+1)? or is it better to use placeholder notation as in math, i.e. ( horizonal line + 1)?

[@eLBehmo]

The c++ examples should use ranges - nobody wants to see all the begin/end iterators

[@richardblain4783]

I’m surprised to learn that anybody still uses APL, let alone that it’s their favorite language.

[@davidw.4972]

Thanx for the talk. Here is the link to Bartosz' channel, you were mentioning at the end: kzbin.infovideos

[@atsmyles]

Wish I saw your comment before doing the search myself

[@nutbunny10]

How different is Dyalog APL different from APL?

[@supplychainoperationsresearch]

i didn't know category theory could be useful for programmers. would you happen to know a few use cases?

[@code_report]

If you make it to Chapter 3, Monoids are introduced and they show up everywhere. Identify a monoid and you have just identified something that can be parallelized.

[@Evan490BC]

Think of Category Theory as the mathematics underpinning functional "design patterns" in (typed) functional languages. The difference with the object-oriented design patterns (say, from the "Gang of Four") is that now you have a solid foundation, whereas in the OO case they seem to come almost out of the blue. (This is not completely correct, strictly speaking, since people like Luca Cardelli have proved certain equivalences, but CT is a much more general theory.)

[@andik70]

@@code_report For monoids we do not need category theory (as also shown in the book). So you are referring to section 3.5 where it is explained that a monoid can be viewed as a category with the (advantage) of having automatively associativity since composition is associative; did I understand that so far? This seems to be a small advantage. A disadvantage seems to be that commutativity cannot be seemingly expressed naturally in functor language? I still get the feeling while thinking about functors is sometimes neat, it is more on the level of a footnote. But I am open for useful examples.

[@Evan490BC]

@@user-tx4wj7qk4t That's why I put the phrase in quotes. By "design patterns" I mean monads, applicative functors, monoids, etc. And categorically, OO is dual to functional programming (co-algebraic data types).

[@Evan490BC]

@@user-tx4wj7qk4t No, I mean that classes in OO are closed for modification but open for extension, which is the exact opposite (i.e. dual) to algebraic datatypes in functional languages. In the latter you cannot easily extend the interface (typeclasses) but you can easily compose more complex data types algebraically (sum and product types). You can mimic those using e.g. templates, up to a point, but templates are not part of OOP.

[@mohamedsaif1928]

May Allah blesses you Conor, you are a lifesaver.. could you give us some tips for making such an effective, focused, and informative video?

[@code_report]

Thanks! At some point this year I will be making a "Tips For Making Conference Talks / Code Videos" - so look out for that.

[@Fogmeister]

Seems like a good series. Not sure why you would implement the challenges in APL though. Surely your goal for a series like this should be accessibility to people. Using something like APL which is arguably more abstract than Haskell is doing just the opposite. True, you might do them in APL for your own achievements but for a video like this is would seem more reasonable to use something that more people are knowledgable like Javascript or something. Yes, it's a million miles away from Haskell and APL but these ideas are possible to implement in JS which at least gives the videos the accessibility for people coming to these ideas for the first time.

[@code_report]

Someone else commented the same thing earlier. This is my copy & pasted response: I use APL because I love APL and it makes it more fun for me. I get more excited about writing solutions in APL than any other language. I make them to share my passion for those that are interested.

[@Fogmeister]

@@code_report fair enough. It's your video series so you can do anything you want to do. But it appears that you are trying to discuss (and teach to some extent) some of the ideas around category theory. It is on that point that I question the usefulness of using APL. In order to teach people you need to communicate with them at a level they understand. And then use that communication to bring their understanding up to the level of the ideas you are teaching. Haskell is already a fairly abstract language when it comes to 90% of developers. Category theory is even more abstract. The way to discuss and teach it (and consequently to reach a wider audience) is not to explain things using even more abstract means like APL. It might be your passion and 100% keep doing it. It just feels a bit strange that it's used in a video like this as a means of explaining things but is more obscure than the ideas it is explaining.

[@bhz8947]

All that text to make such a simple point?

[@Fogmeister]

@@bhz8947 sorry you find reading difficult.

[@LambdaJack]

Do you dare to /join #programminglanguages mortal?

[@user-sv7fo4ps3k]

I really wish you'd have stuck with haskell or something slightly readable instead of APL. I'm sure for you it's amazing, but it's too much cognitive load for someone unfamiliar with APL to digest all the symbols and the ideas of category theory all at the same time.

[@kahnfatman]

Fate has it that I WILL BECOME a COOK :D

[@Oktokolo]

The difference between Haskell and C++ is expressiveness. But the difference from Haskell to that other language seems to just be replacing words with obscure glyphs. Just makes it harder to read and write.

[@user-tx4wj7qk4t]

They're not obscure, they're from math. C++ is the one that did pretty much everything randomly with no connection to anything else. Also it's very objectively much easier to write which is why mathematicians write this instead of spending half a day setting up c++ boilerplate

[@Oktokolo]

@@user-tx4wj7qk4t Okay, here is the proof that math notation is more obscure as subjectivly perceived by mere humans: The overwhelming majority of programmers uses non-mathy programming languages - despite the mathematicians having been there _first_. Seriously: The symbol-fetishism of math is an accessibility problem. Give things proper names instead of just some greek letter and people will have a much easier time learning it.

[@user-tx4wj7qk4t]

@@Oktokolo ugh no the proof that math symbolism is better is the very fact that despite being allowed to use literally any means of expression they want, mathematicians use extremely terse symbols to express just about everything because once you're educated on what the symbols mean it becomes by far the easiest way to communicate. 1000s of years of math evolution has led to what we have now and it only gets more and more abstract and terse. Meanwhile most modern programmers are uneducated in just about anything and just copy paste whatever is handed to them. Not to mention that most languages until recently weren't very capable of handling higher level mathematical concepts to begin with. The only reason you don't like symbols is because you don't know what they mean and by the way words are also symbols. But ok go write a massive math proof and replace all the + and - with "addition" and "subtraction". That sure won't get old really quick. Also make sure parenthesis is changed to "START" and "END" like Pascal. That's really very pleasant to look at Also another funny thing is all these imperative programmers don't even use full words and make words 3 letter versions of everything so I have to sit there and wonder what "ret" means

[@ludoviclagouardette7020]

15:45 You put a finger in why i really dislike Haskell and APL: symbols. Even when I know the symbols, I cannot read them. I can read words, but i cannot think in symbols, which is why I actually prefer to write pure functional code in C++ That of course does not make it invalid, but it shows how much of my mindspace just having those symbols here takes compared with words

[@stretch8390]

Do you think that could just be from a lack of cognitive ease in programming with symbols though? You have x amount of years programming with words, if you had the equivalent amount of years dealing with symbols would you still be unable to think with them? Mathematics has a multitude of symbols and we don't struggle to think with them.

[@ludoviclagouardette7020]

@@stretch8390 that is absolutely the case, despite using mathematics a lot too when working. I transform every single mathematic statement I encounter in words and very simplified equations or geometrical representations

[@dancingcactus5271]

I think the problem with category theory for programmers is that they try to push all the unhelpful category theory conventions on programming, making it much harder to understand. For example, calling f g h morphisms instead of functions or procedures.

[@warwolt]

Morphisms are much more general, but the book does a poor job at exemplifying different categories except for Set

[@stephenjames2951]

So much noise in the c++ code.

[@qG0L0r6W]

If you assume that most of your viewers don’t read APL, why are you using APL? Haskell is a barrier enough for most people, yet you’ve decided even more obscure language such as APL. I think you should rethink this decision. What you’re doing is incredibly valuable, and a lot of people could benefit from it, but category theory is dense enough as it is, there’s no need to complicate things even further. Just my $0.02.

[@code_report]

I use APL because I love APL and it makes it more fun for me. I get more excited about writing solutions in APL than any other language. I make them to share my passion for those that are interested.

[@jursamaj]

Seems to me that 'performant' is a much more important criterion than 'elegant'. For instance, it is trivial (and elegant) to write fibonacci in recursive code, but if you use it for any large value, your runtime may exceed the lifetime of the universe. With just a bit more effort (and less elegance) you can write an iterative version that will actually complete.

[@johk2293]

For some reason I think python implementation of iterative version of fibonacci is more elegant because of a, b = b, a + b

[@aioia3885]

in Haskell you can just implement O(n) fibonacci in two lines of code fib n = (f 0 1) !! n where f a b = a : f b (a + b) Haskell is still much slower but for other reasons, so the analogy still works but I still wanted to point that out

[@aioia3885]

a much better example of what you mean is the following piece of code which computes prime numbers primes = f [2..] where f (p:xs) = p : f (filter (\x -> mod x p /= 0) xs) it sure is elegant but it is significantly less efficient than writing a program that does the sieve of eratosthenes, being O(n²/log²n) instead of O(nloglogn)

[@jursamaj]

@@aioia3885 So, what you've shown me is that Haskell handles the fib code you wrote as the iterative version. Doesn't change my point at all. By the way, what I gave was an example, not an analogy.

[@framegrace1]

Why that obsession on writting less characters? Learning a new alphabet just to save a couple of characters per command?. What's wrong with using "rev" "comp" "rot" instead of the symbols ? Do you really thing it makes it more or less "elegant". Test

[@yarrowification]

It changes the way you think about it. For example if I asked you to write math with English like this "five to the power of seven plus the reciprocal of twelve all decided by three pi" you probably would find that hard to work with and think about mathematically. If somebody grew up that way they might ask you why you need these funny math symbols. Anyway ultimately it is a preference thing

[@bhz8947]

Sounds like you’re under the impression that this is his personal notation.

[@pexoto5093]

Ok so lets point a few things out here. Category theory comes primarily from math, and in maths, it will obviously inherit some standards from it, such as the extensive use of symbols. We do it because we're used to it, so the compiler natively supports infix operators. We like it because we think it's easier to reason about (e.g.: it's easier to understand a ++ b ++ c ++ d than to understand concat a (concat b (concat c d)). ) But if you prefer a more verbose way, just define in those terms (i, for instance, dont like the g o f notation because i like to go from left to right, so i merely define f |> g = f . g and go on with my life). You're free to do as you please, and nobody will annoy you for that. We're not like the oop community, which loves to pull stupid creativity killing rules out of their asses and enforce them on everybody else.

[@user-tx4wj7qk4t]

I like how guys like you will write extremely opinionated things like this and then just never reply to anybody. I see it in every single fp video. To answer your question, math

[@rossdrew9217]

Tries to sell how readable APL is then spends ages having to explain every character in the most terse, functionally/mathematically thick language. There's a good reason the industry will never be fully functional. Because you don't just need to understand it, you need to live it. It's more readable if you invest a huge amount of time changing everything you know. Which is only beneficial is everyone else does it.

[@alexandershendi7428]

I always knew it: You need 3 PhDs and a comprehensive knowledge of category theory to program in Haskell. "Java, the bastion of OOP": ouch, that hurt... "convert to functional programming" sounds like a religious choice...

[@michaelflynn6952]

the comparison between knowing chemistry in baking and knowing abstract math in coding is perfect because no world-class chef is paying any attention to the chemistry of their work, just as functional programming is just a buzzword for mocking bad examples of object-oriented programming

[@vazn4143]

It's all about your goal. Do you want to understand the truth and facts behind a given domain ? Or do you just want to be a top tier user of the ideas ? To add another analogy, there's world class musicians out there who don't understand shit about what they are doing. They create amazing things don't get me wrong. But they don't understand them at all. They don't know anything about harmony theory, rythm theory etc It's the same for programming. Everything depend on what your goal is. Not every CS enthusiast goal is to become "world class" programmer or whatever. For some, the goal is to understand things.

[@darrenweston4777]

C++ is fugly. APL has to mean Alien Programming Language.