Category Theory for Programmers: Chapter 1 - Category 

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

@@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.

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.

​@@bhz8947lol imagine being you

PureScript has c++ ffi

Wish I saw your comment before doing the search myself

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

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

**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.

@@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

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

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

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

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

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.

@@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.

All that text to make such a simple point?

@@bhz8947 sorry you find reading difficult.

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.

@@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

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.

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.)

@@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.

@@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).

@@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.

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

@@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.

@@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

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

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.

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

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

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)

@@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.

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

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

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.

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

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.