Exercise 27

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Jafar Husain: Let's move on to stock ticker, how many folks actually got to this question of got past 26. Okay we got one, two, three, excellent. So this question is actually an easy question. We're going to take it a little easy now we've taken it real hard. What we're gonna do is we're gonna go through this historical list of stock prices.

[00:00:22]
So these are the NASDAQ stock prices from who knows how long and all we wanna do is we want to just filter it for the ones that are only Microsoft. And then I believe we want to just print it out so it looks like we just want to print out all of the NASDAQ prices.

[00:00:48]
>> Jafar Husain: So I think it's price records. We just want to look for Microsoft. So the name is MSFT.
>> Jafar Husain: I'm gonna run this.
>> Jafar Husain: What's going on here?
>> Jafar Husain: Does this surprise anybody?
>> Jafar Husain: Why would these results trickle in? Every single result up till now has just popped right up on to the screen.

[00:01:27]
Well what's actually going on here is instead of querying a huge historical database of NASDAQ prices, we are querying live data now in reality I'm actually spoofing this data but the point is we're working over an asynchronous data source. So we could just as easily could actually be hitting the NASDAQ right now and querying for real time stock prices.

[00:01:45]
So now we've actually made the switch from querying arrays, historical data, that's just been sitting in a database somewhere or in memory. To querying data as it comes in.
>> Audience: Yay!
>> Jafar Husain: Yay. [APPLAUSE] Asynchronous programming, I promised you'd get some, right? So now we're finally realizing hopefully that all the lessons that we've been learning about how to process data up till now, every single function you've learned.

[00:02:08]
If you can master that you can query any asynchronous data source out there, whether it's real time stock information, right? Whether it's an event, whether it's a mouse move event. You can assemble it all together to build complex asynchronous programs completely declaratively. So, let's move on and start exploring this new type, which I will call an observable.

[00:02:28]
So you guys saw in the presentation yesterday. Is that a question?
>> Audience: Is the reason this works because we're using ReactiveX's implementation of forEach?
>> Jafar Husain: That's exactly right. So an observable has a forEach implementation, right? The only difference between the arrays forEach implementation, which blocks until all the data in the array's been slurped up and processed, is the observables forEach implementation finishes immediately, right?

[00:02:53]
Cuz it doesn't block. But as the data arrives over time, cuz let's recall an observable's a collection that arrives over time. As that data arrives over time, this function that handles that data gets processed. Now let's remember forEach is different than every other function that I've taught you guys yesterday and today.

[00:03:11]
What's different about it? Can anybody tell me?
>> Audience: It doesn't modify the data, it doesn't return an array.
>> Jafar Husain: It doesn't return an array. Every single other function I've taught you up till now has returned an array, with the exception of forEach. And that's an important distinction. What we're gonna be doing as we write code, as you've seen up till now, is we're gonna be using map, filter, reduce, concatAll, and zip to be building the collection we want.

[00:03:34]
And then finally once we've got a collection that's exactly what we want, whether it's an event or an array, and we're ready to process the data inside and do something with it, then and only then, do we terminate with a forEach. So those are really thinking about things very separately.

[00:03:48]
First we're building the collection we want, but notice we don't change anything. When we build the collection we want, we don't change anything at all. When you take an array and you map it and you create a new array, you haven't changed the old array. When you filter it, you haven't change the old array.

[00:04:01]
Everything up to now it's been taking data in and creating new data, but now as we begin to use forEach we move into a different phase. We say you know what, now that I've created exactly the data I want, exactly the collection that I want, I'm gonna take the data out and now I'm gonna change something.

[00:04:15]
So inside a forEach you can expect to see us modifying things, so printing a record is a great example of modifying something right? I've written something out to the council, that is actually a change. Some where there's a buffer where it's value has been changed. Right, so we're actually changing a global object.

[00:04:31]
In this case the console, whereas in map and filter and reduce and concatAll, and so on and so forth. I only said that you could change objects that you yourself created, right. If you hand an object into the function for map, you shouldn't be modifying with that object.

[00:04:43]
So it's a very different way of thinking about what you're trying to do is you're carving your program up. You're taking the data, which is really just computation, where you're taking data in and you're computing new data. And you're separating it from data that changes data. Can anybody tell me why that would be a positive or negative thing?

[00:05:02]
>> Jafar Husain: What's the point? What's the point of separating data that doesn't change anything from data that changes something?
>> Jafar Husain: Well there's a whole class of bugs that just can't exist in code that doesn't change anything. A whole class of bugs. Has anybody here ever run off the end of an array, for example?

[00:05:21]
Or had a bug because you change the variable before you changed another variable? These are a class of bugs that sometimes are called state bugs and remember when I told you the enemy of a complex asynchronous program was? State, it's creating all those variables to track all those asynchronous things going on.

[00:05:37]
That's what we're trying to eliminate. The interesting thing about what we're learning today is that asynchronous programming is, another way of thinking about it is, it's sometimes called reactive programming. Who's heard that term reactive programming? All right, a few people, right? Now asynchronous programming in JavaScript is necessarily reactive programming.

[00:05:54]
What reactive programming means is, it's like the Hollywood principle. Don't call me, I'll call you. So you guys hand me a call back. And then I'm gonna call that callback at a totally unpredictable time, right? So you subscribe to an array, you hand it a callback, and then you don't know when that array's gonna call that callback, right.

[00:06:13]
So it's a bit of an odd position because when you're running just synchronous code top to bottom, you control when your code is called. But as soon as you hand it to another function, that function might call it any arbitrary time. Now if you structure your code. So you use use a lot of state, you change a lot of variables that might be changed.

[00:06:30]
Excuse me by a lot of the other functions. Well all of a sudden that's a real hard model when you don't know when your code is going to be called. So that's why I'm teaching you functional programming, this idea of functions, which take data in and generate new data at the same time as reactive programming.

[00:06:46]
Which is that idea of you giving somebody else a callback and them pushing to you, deciding when your code gets called. Even though these are two separate concepts, the reason why we learn them together is that it's very, very hard to build a program where you're changing a bunch of state and variables, and you can't predict when your code is gonna get called.

[00:07:05]
Because who knows? Your code might be called in any particular order. And if you're changing variables, it's very hard to structure a program that way. So if we take these two notions and put them together, which is to say that look I'm never gonna change any data other than the data I generally create and own.

[00:07:19]
And you combine that with reactive programming, which is like I don't know when my code's gonna get called. By not modifying any shared data, all of a sudden it's a wonderful thing, because now it doesn't matter when your code gets called, right? If you're not changing a global object or share data, your code could get called in two seconds or it could get called in five seconds or it could get called in ten seconds and it will just work.

[00:07:40]
That's why we take all of our code that changes the world, global objects, objects that we didn't create. Like in this case the console, and we move it all into the forEach, right? That's when we decide that we're ready to consume the data, we're ready to take it out and we're gonna limit all of our change code, all of our do code, do things, change the world code, inside of the forEach function.

[00:08:01]
Whereas everything above can run in any particular order. Well maybe the callback gets called in two seconds, maybe calls and in five seconds. It doesn't matter. And so that's why it's so important to learn functional programming. This ability of I'm not gonna change things, I'm gonna take data and I'm gonna create new data.

[00:08:18]
Because it makes your code safe to run in any particular order. Does that make sense at a high level anyways? Right, if you can't predict when your code's gonna get called, well you better only change your own objects, not objects that somebody else can change. Cuz who knows what the state of the world will be in two minutes, right?

[00:08:34]
Or ten minutes. So that's why we're teaching these two concepts together. But it's hard to absorb both of these concepts together and that's why I spent the first day on what is by far the hardest part. Which is learning to change the way you think about code from I'm gonna change this variable, I'm gonna loop.

[00:08:47]
Even a loop itself involves changing a variable, right? A for loop involves changing a counter. That's the kind of change that we want to avoid cuz you create a counter variable and every time around the loop you change it again. Even something as simple as that, all of a sudden the order and dependence of your program is sort of dictated by when this counter changes.

[00:09:04]
We're trying to get away from any kind of code changes. So the first day was learning all about functional programming. And today we're gonna be learning about reactive programming, asynchronous reactive programming, technically.