A Crash Course in Category Theory - Bartosz Milewski 

with arrows? :)

​@@maximyanchenko3780we're functional programmers, buddy-where we're going, we don't need dots (points).

this comment made my day

all valid questions. I'm thinking it should be a framework for all other abstract problem-solving. you know, the lowest set of logical operators for the human problem-domain that is easily solvable by a machine, so that when we go higher up we get more of that human-framing and less machinery bits getting in the way. to put it bluntly. but it cannot work that way ("there is no time in math"). mathematicians are just annoyed with the way computing works. we picked imperative for a reason, but they would really like to be able to code -- because they can't, for some reason, all they do is implement tools that behave mathematically so they can pursue this purity of thought. software engineers and mathematicians are quite the opposite, you never get both at once. if you look at the leading and most pragmatic languages to implement anything, they are neither Scala nor Haskell. you know, both are used in "research", and both are endorsed by 'academia' alone. well, let me put my elitistic glasses on, so that I can appreciate it all a bit more. nope, both languages just didn't want to compromise their theoretical baggage in order to get things done. unless I can make a functional game (pun intended) in Scala, it's just a technical perversion that strays people from the path of the reality of programming. so in essence, it has nothing to do with programming, mathematicians just yearn for a way to make computers a slave of their mindset. hence the category theory. but maybe something useful will trickle out of it, who knows. that certainly happened in the past. it was all theoretical to begin with, but then engineers came along anyway. so we should definitely figure this one out. thus your questions are valid.

@@milanstevic8424 Sorry, but this is untrue. Not the part about most mathematicians being poor programmers, because even most software developers are poor programmers. But the rest is false. For starters, Scala is certainly used outside academia and research - I have worked with companies ranging from startups to huge corporations using Scala to create applications which were vital to their operations. Some relatively small ones (~10 kSLoC), some relatively big ones (~500 kSLoC, which is a lot in Scala, although I know of some Scala projects which are an order of magnitude bigger). I wouldn't try implementing most of those in a lower-level, imperative language. It would be a nightmare, one full of bugs (which is not a huge problem for games, but for those clients it could mean losing millions of $). While not perfect, I believe Scala is currently one of the best choices for serious business and processing huge amounts of data (i.e. it excels at high availability, scalability and high throughput). As for Haskell, I cannot say from my own experience, but I know that e.g. Facebook uses it (see Haxl). The statement about Scala "not compromising its theoretical baggage" is the opposite of what really happened - enough to say that Scala is a multi-paradigm language and that Dotty is almost a total overhaul of Scala. When it comes to games, there is absolutely nothing inherently wrong with Scala as a language which would make it unsuitable. I think what you mean is that JVM is not a great platform for games, which is somewhat true, but there are some which do use it nonetheless (e.g. Minecraft). You just need to be careful about garbage collection, mostly (but frameworks usually take care of this for you, e.g. LibGDX). I think a major factor behind Scala being very rarely used for games (I know some game companies which do use it) is that people who know Scala can find much better jobs outside game industry. Regarding "something useful trickling out of it", it is already happening. It is clearly useful for language designers and library authors, but even in a typical programmer job it helps immensely to know the theory behind things - it lets people write cleaner, more reliable code and reason about it. I know some people who know CT quite well and I know it has even helped design a more efficient algorithm at least twice. And no, I'm not a mathematician, on the contrary - I was writing imperative code (including low-level Linux kernel stuff and some embedded programming) for 20 years before I finally gave functional programming a chance (initially having thought it was just a toy for mathematicians, too) and that was the best decision in my career. I think category theory will be the next big step towards better code, although I feel I'm still only beginning to understand these abstractions.

​@@tuesss Maybe my tone was a bit negative, but I really only wanted to sound as realistic as possible. You see, Turing was a computation forefather and a brilliant mathematician, but he _was_ a lousy programmer. There is simply no other way. It's not that I hate mathematics or that I have anything against it, in fact I adore it and I wish the world was part of a mathematical reality (instead of it being the other way around), but the set of mathematical realities doesn't overlap with the set of engineering realities. It assumes perfection in the low level domain and all functional code (and languages) exhibits this bias. It cares not how the types are actually resolved. It ignores the concept of having a hardware, neglects the memory usage patterns, tends to iron out any experience that makes you open that bonnet in order to replace oil. "We should be driving, why don't we just use robots... Or slaves.." right? I've heard more than one woman driver saying that, for some reason. While common engineering tends to factor in the processing time, the "churning" factor, the deadline, yield, utility, and user experience. It is dirty, it is messy, it is actually embedded into the universe as we know it, but most often than not it's heavily inspired by the divine mathematics, the one cannot do without the other. Mathematicians would instead like to live in a world where all of these things are not really important. It's about the level of abstraction. To quote a real world example, I give you a de facto standard, perfectly illustrating the illusion of the theoretical approach to programming: IEEE 754. It's as inaccurate and limited as it is useful, and while being conceptualized by mathematicians in order to satisfy the real world usage, it goes directly against the purity of their domain, hence it wasn't implemented by mathematicians, but hardcore engineers akin to Wozniak, who was almost autistic in his elation for being able to juggle bits on a limited piece of electronics, to switch cleverly and shave off two cycles and save the arcade panel board from a couple of extra processors, where there were normally dozens. There is no 'equality' sign in the world of IEEE 754. You cannot ever hope to get two doubles equal to each other bit by bit, unless they're both zero. The equality is a hack, and an unpure one, mangling up several domains in order to achieve the desired effect. The most "pure" incarnation of IEEE 754 is when the hardware is augmented with coprocessors capable of natively solving the comparisons in optimal time. But the reality is that the hack just descended out of sight. *And this is exactly what functional paradigm does, it draws a clear line where it thinks a line between messy and pure should be.* It is a useful thing to have, but most often than not, it doesn't solve anything on its own, but trades off by calming down the spirits of math-genius OCD, and exhibiting theoretical expressiveness at the expense of having it work more deliberately and thus more powerfully. The point is really to have the electrons take the least path, you cannot shun away from that. If your slaves are building a Giza pyramid, the key is not to have them haul the stones from England. "The point is to have the stones gathered up, eventually, but let's be honest here, the diagram is beautiful isn't it. In just a couple of generations, it will be done." While we're at it, point me to a direction of a functionally written software that is as beautiful to use as it is useful, robust, and readily available. I have plenty of imperative examples to share, so there has to be some design choice involved when it comes to picking a paradigm. As for Scala you're mentioning, that's a heavily compromised Frankenstein's monster. It simply has to be more imperative than you would like to admit -- it simply has to be, if it's really used in a robust and technically competent manner, and I'm not talking scalability, because that's just one of the few rare things you get for free in F languages, I'm talking performance, collaboration, maintainability -- and I stand firm in my statement that there is no practical >>pure

@@tuesss In essence, we do mostly agree where it matters. I wrote this for the sake of discussion, it's not that I'm opposing you fiercely.

Thanks for this thread, I get so much context from it

In a category of integers, ints are the objects. In a category of types, the type INT is an object. They both have their own Void. It can be difficult to keep straight in your head the environment (level) we are thinking in at any point.

It's the same thing, only in two different perspectives (one taking functions as fundamental, and the other taking types as fundamental). It simply shows that these theories are capable of representing more well-known, concrete theories.

Unless we consider the lack of a function itself as an arrow? Doing my best to figure out something ¯\_(ツ)_/¯

I think its saying that an empty set can be a set of anything you want you just have nothing of them

Yes I agree... What I cannot figure out is what the arrow going out of the initial object represents in the case of set theory. Best thing I can think of is the lack of a function...

Or a function without a valid implementation

sbditto85 in programming terms yes... but sleeping over it helped I think. We have different definitions of a function at our disposal. One if them fits nicely: f:A->B is the set of (a,b) in AxB under the condition that all elements in A are mapped exactly once. If you look at a (total) function from that angle, then the empty set of pairs is a function from {} to any other set, since all the pairs it contains respect the condition above... you can call that special function Nil and it corresponds to the arrows coming out from the initial object. The nice thing is that seen as a relationship between elements in A and elements in B there is no need for extra definitions and conditions in order to define the nil function. As a bonus we explicitly get the now famous product AxB at the core of definition for functions.

it's not your fault, it's dry as cotton and the lecture is badly formulated. it's actually quite simple, it couldn't be any simpler. it's the consequence of it that is perplexing, but the foundational patterns are pretty dumb. but such is a thing with mathematics, the languages and notations mathematicians use are completely human unfriendly. and not everyone can teach. I'm a software engineer and thankfully have discovered mathematics through a little backyard door, instead from the cryptic portal guarded by two gigantic sphinx in the front, stupefying everybody. the actual effort of implementing it in the real world terms is what makes it tick for me, whether it is geometry, linear algebra, calculus, logic, statistics, or the set theory, but I don't like the abstract transcendence of it, the thought-provoking fantasy mind blowing games, and yes I'm definitely not a mathematician, they're like a different caste of people, I just use it as a very clever tool to magically arrive at incredible conclusions and to visualize my problem spaces, but tbh pretty advanced areas of math are a lot simpler than they look and is pretty easy to navigate once you get the point of it and work out the fundamentals, and seriously -- what the lecturer prescribed very well in the beginning -- that math lecturers should give us the goal, the objective, and it'll all come together naturally, he failed to do. well, shit.

Irrelevant, maybe, but definitely amusing!

thats an Applicative

From where you imply you're standing, you seem to be the one who needs lifting

Yeah it could be another slide before Yoneda, but that would be too much information for such short presentation. He goes into that deeply in his CT course on RU-vid.

Yes, but you could never call that constructor. You would be defining a recursive type with no base cases, which indeed has no elements, and therefore is isomorphic to Void.