Wrapping Up

[00:00:00]
>> Okay, so throughout the day, we saw these functions defined left and right, which they kind of seem like success and error, or error and success. And I'm just wondering where the naming left and right came from, and if that's common in the functional programming where that came from?

[00:00:14]
>> So yes, so either it came out of, in type theory, it's kind of interesting. You have a sum type that says it's this or that, and they just of started with kind of the mathematical side, that says it's either left or right, this branch of this tree.

[00:00:35]
And it's kinda neat how the sum type turns out to be the sum of all the habitants of both types. And then you have product, which is the product of both types. But the point is that either is not supposed to be for errors. It's just supposed to be this or that.

[00:00:54]
And we've kind of pushed it into, it's this error handling monad over the years via convention. And so Scala has actually renamed it to success and or results and error or something like that. But you'll see it used in different ways. In fact, I have this really weird gist, Where we, there we go, it happens to be in my history.

[00:01:22]
Where we actually define a list in terms of just the sum and product, canonical sum and product types. So we actually say, it's like either null or a tuple of this and then it creates this whole list off off of just these basic building blocks. And what's interesting about it is either is not used as an error thing, it just means, am I at the end of the list or do I have more to go?

[00:01:49]
It's this or that. So being left and right keeps it abstract enough to be the sum type. But in practice, the names don't make as much sense, yeah.
>> Kinda to follow up on his question and Mark's point earlier about this, what we're really talking about is a logical disjunction.

[00:02:07]
>> Yes.
>> With left and right. There are other monads that cover the conjunctions, which are all category theoretic structures. But we're using mostly math terms to describe things that are familiar.
>> Yes.
>> So it's just a weird mishmash of nomenclature.
>> And that's true. On one hand, if you wanna go look in the literature, a disjunction would probably be the best name.

[00:02:29]
And if you wanted to look into just programs, for programs sake, error and success would be a better name with either, which is neither, [LAUGH], which is great. [LAUGH] But if you hear people say, why are you calling it a functor? They're just trying to be smart and fancy.

[00:02:47]
Why don't you just call it a mappable? And the problem with calling it mappable is you ignore all the history of functors and what they mean and what you can go look up and use from that. And mappable does not come with that same context of, if I ever hear a math name, I know immediately that there's gonna be properties.

[00:03:06]
I can build on it, I can refactor my code to it. If I hear something that's da, da, da, I know I can't. Or I don't know if I can, I have no idea. I have to go and read the docs. And most of the time, the docs is just someone's minimal amount of work to explain how to use it.

[00:03:20]
So yeah, math names, it's actually, poke a nerve when you talk about it, but that's my opinion on it.
>> And one other.
>> Yeah.
>> On the human side of functional programing, where there's this learning curve and bringing people along that aren't used to it. I'm just kinda curious what your experience has been working with others that aren't really used to it, and any advice you have on bringing people along.

[00:03:48]
>> That's a great question. So my advice has always been, if you don't know how to program, learn how to do object oriented programming first, for sure. You're not gonna go to work and be like, let's fire up the everyone. They're like, what, get out of here. So there's that, but you're working on a team.

[00:04:07]
As I go into a team, I start with introducing either and task alone pushes you into the entire, it's just like introducing promise in your code base.
>> The rest of your code base just gets infected with promise, right, so red, blue, or whatever. But the point is, once you get buy in to either saying, look, we can make a safer function, we can invert the control, but you're gonna have to map over it, and then you have to learn chain.

[00:04:30]
These are just two functions, that's it, maybe fold, so three functions. So three functions for either, hey look, they're the same for task. And if we use task instead of promise we can do more stuff. And we start to kind of get buy in of the team with those things.

[00:04:46]
I would not do, let's get rammed up, do point free code all day long. And they would be, this is really fun and interesting and cool, and it helps me understand better. But it doesn't necessarily have the same impact as kind of these formal structures do. When you combine them, you end up with this kind of beautiful mathematical program.

[00:05:09]
But definitely in a practical business setting, we've introduced this in our team, made some stuff. They started to see the benefits, full buyin, made the whole app that runs our entire infrastructure on this stuff and then we left. And the team that's supporting it now [LAUGH] is like, what is this?

[00:05:30]
So it's not as pervasive as possible or as you would think it'd be, so I think, introducing it on your team, getting buy in, but also thinking about the future of the maintenance is another thing. Until more people care, it's still on the fringe.
>> Thanks.
>> Sure.

[00:05:52]
>> Reminds me of reactive extensions, some corporate cultures really embraced that. And it's a lot of the same principles.
>> That's exactly right. And if you see RXJS, that is 100% pure functional programming in your code base done. And I would nudge people these promises and use that and you get way more experience with this stuff.

[00:06:15]
And then you're just like, well, why don't we go a little further and get more benefits? Cool. Have this as the list. And look forward to seeing y'all in the functional architecture class, where we can take all this stuff and actually we're just gonna be building apps all day in that one.

[00:06:34]
So this is kind of a long march to learn all the all the skills to be able to build apps. But hopefully, when we built that last app, you understood what was happening. We were working with functors and monads and composition and currying. And it was just there, so cool.

[00:06:50]
Thanks for being here.
>> [APPLAUSE]