Derivation Summary and Q&A

[00:00:00]
>> Kyle Simpson: And so now we have ended up back where we started several slides back which is now we have a single reduction using our transducer. Take several deep breaths, I heard a couple, but take several more deep breaths. That's some really heavy stuff, okay?
>> Kyle Simpson: One out of 1,000 people might have any clue what the gobbledygook that just came out of my mouth says, okay?

[00:00:29]
I get it, it's very confusing stuff. But what I want you to come back to is to remember that we don't have to understand how 1 plus 1 equals 2. We don't have to able mathematically prove or derive that to be able to add up our check at the restaurant.

[00:00:45]
I've now shown you that there is a way to derive things and there is a meta commentary that I make. The reason I include this derivation in the course, it's not just, so that I can like totally blow your mind. But the reason I wanted to include this is if you go back through these slides, you won't be able to do it right at this moment, cuz I know things are awash in your head, just like they almost are in mine, I get it.

[00:01:09]
But if you go back and you look through these slides, you're gonna see that every single step of that derivation that I did uses the basic principles that I've taught you in this course. There was actually no black magic at all. There was no fancy other utility that I came up with out of the blue.

[00:01:25]
No other kind of pattern I used. I just did abstraction which we've talked about, we did composition, we did currying, we did all of those little Lego pieces that I've already taught you in the course. And what's fascinating and amazing, to me, is that those little pieces can, in just the right configuration, produce something as powerful as transduction.

[00:01:48]
Imagine what other sorts of things we can accomplish if we really get our brains wrapped around the power of these fundamental functional principles.
>> Kyle Simpson: Yes?
>> Speaker 2: Could you take it us, well I sure maybe you can or can't, or maybe it wouldn't be a good idea. But you could take it a step farther and adjust and change the shape of that reducer so that instead of having pass in 2 arguments, you could just then pass in sum.

[00:02:21]
>> Kyle Simpson: I'm not sure I understand.
>> Speaker 2: So instead of having to pass in 2 arguments then-
>> Kyle Simpson: Reductions always need an initial value.
>> Speaker 2: Yeah.
>> Kyle Simpson: So you remember several slides back when I showed you the transduce utility it also takes an initial value and into also takes an initial value.

[00:02:40]
Generally speaking a reduction always needs an initial value. Could you make it so that that initial value could somehow be assumed? Well, in a particular problem domain, if you knew you were doing numeric addition, you could assume 0.
>> Speaker 2: Yeah.
>> Kyle Simpson: But if your transducer was doing multiplication, you'd have to assume 1 and if it was doing string concatenation, you'd have to assume empty string.

[00:03:00]
So, generally speaking, the safest approach is to always know that when you're going to do a reduction you need a good initial value.
>> Speaker 2: Thanks.
>> Kyle Simpson: What's key to note here though, is 0 doesn't get passed into the transducer. The transducer didn't care about the 0 at all.

[00:03:18]
0 is for the purposes of the .reduce, cuz reduce has to have somewhere to start.
>> Speaker 2: That's right.
>> Kyle Simpson: Okay, transducer itself is a mathematic thing that's been reshaped entirely and it's completely agnostic of what values are about to flow through it.
>> Kyle Simpson: Yes?
>> Speaker 3: I'm curious, if you weren't actually summing it afterwards, how far back would you go to set this up?

[00:03:41]
Cuz I can picture a bunch of times when I would wanna just filter and map something.
>> Kyle Simpson: So if I didn't pass in sum, if I passed in a string concatenator. It takes an x and a y and adds them together as a string concatenation, what would the end results of this have been?

[00:04:01]
>> Speaker 3: It would just be a string of all those-
>> Kyle Simpson: It would be a string of each one of those individual numbers which ended up adding up to the number 42, but it would've been each of those individual numbers as a string. What if I passed in list combination, what would we have gotten?

[00:04:16]
>> Speaker 3: An array?
>> Kyle Simpson: We would have an array that had the values that had been mapped and filtered. So what reducer I pass into my transducer completely decides what end results I get.
>> Speaker 4: Yes, but if-
>> Kyle Simpson: If I want to mathematics summing, I pass in sum. If I want a string concatenation, I pass in and that's exactly what into is doing.

[00:04:36]
Into's saying you gave me a 0 as an initial value, it's a pretty good bet that what you want back is a number, I'm gonna go ahead and guess that you want to just add everything together. That's what it's doing. It's making those sorts of assumptions and we can see the power of that here.

[00:04:49]
We can use this exact same transducer with any different reducer and come up with a different end result.
>> Speaker 3: So if you just wanted to do the filter in map, would you not do a transducer or would you pass in like identity or something that?
>> Kyle Simpson: Yeah, you pass an identity.

[00:05:04]
That's exactly right. If you feel awash with confusion, and fear and terror, come back to what hopefully was a little bit more comfortable, which was, how do I just use that transduce utility? Let the API do it for me, right? [LAUGH] I need to pass any of my filters to a utility called filter reducer, I need to pass any of my mapper is to a utility called mapreduce.

[00:05:28]
And then I compose those using my plain old normal regular compose, which we've already written on it in this course we know how to make compose. And I take that transducer pass it into transduce the utility and we get our end result
>> Speaker 5: Does this it all explain how RxJS works with streaming?

[00:05:50]
>> Kyle Simpson: Hm, I am certainly not qualified to speak to the internals of RxJS. I can say that RxJS in the version 6, which was at this moment, was the latest version that had been released of RxJS. They moved in a direction where instead of having chained methods that you basically do piping, you do a composition with piping.

[00:06:18]
That's not the same thing as a transduction, but it is friendlier to transduction, right. So with those chain methods that you had in RxJS before, you really couldn't have combined all of those steps. Now that we're in a piping, but a composition you at least theoretically could transform some of those RxJS operators that are reducers, you could transform them into transducers that could compose.

[00:06:50]
I haven't tried that, but I do think it would probably be more friendly to that.
>> Speaker 5: Cool, thanks.
>> Kyle Simpson: Yeah. Yes?
>> Speaker 3: I'm just curious cuz I was looking earlier. Do you know why they made a pipe and not a compose?
>> Kyle Simpson: Where?
>> Speaker 3: RxJS, I was-
>> Kyle Simpson: Why they called it pipe rather than compose?

[00:07:09]
>> Speaker 3: Well like you had said that compose go's is right to left-
>> Kyle Simpson: Right to left.
>> Speaker 3: And pipe is left to right and I just was looking through the API and I did notice they didn't even have a compose at all.
>> Kyle Simpson: Yeah I don't think they do.

[00:07:19]
And there's a very simple reason, I don't know if this is really the reason, but there's a very simple reason. What they're trying to do is get you to convert from your chained list to a pipe and those are in the exact same order in pipe. To convert to a compose you'd have to reverse everything, and they probably felt like that would be super confusing to people, so they just made an API that allowed you to just probably indent and take out the dots and that's it, right?

[00:07:43]
>> Speaker 6: They actually wrote a tool to do that, so yeah. [LAUGH]
>> Kyle Simpson: So, there you go.
>> Speaker 3: You could still write the compose.
>> Kyle Simpson: Yeah, again, we actually talked about this earlier in the course when we were talking about composition and piping. When you're in the habit of doing these imperative things like method chaining, piping feels more natural to you.

[00:08:03]
When you fully immerse yourself in the ideas of functional programming, I think compose ends up being a lot more natural to use. So it's kind of, maybe a different way of getting there. They still have composition but they got there from a very sort of imperative method chaining kind of routine.

[00:08:19]
>> Speaker 7: It seems much more natural to me right now.
>> Kyle Simpson: Yeah, it definitely does to most people, start out seeming more natural to do piping. But, my experience and many people that I've seen is eventually it ends up being composition is more convenient and useful, so. I think that's why it's more common in functional programming.

[00:08:39]
Certainly both compose and pipe are composition from the perspective of declarative data flow, and that's a good thing. That is definitely consistent with functional principles.