Functional Programming

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

[00:00:03]
>> Douglas Crockford: Functional Programming to the Rescue. So one of the reasons why after four years, Functional Programming is suddenly become important is because it contains the solutions to these problems. And we've got a lot of history with this stuff. And going back to future which came out of Dataflow and LISP, future is an object which represents something which isn't knowable yet, but might be in the future.

[00:00:27]
So you can begin interacting with the future object, and eventually it will communicate your interest to whatever the answer turns out to be. Futures had a big influence on a feature called Promises. Promises were discovered in a company that I founded called Electric Communities for a language that we called E.

[00:00:50]
Promises have since escaped from E and moved into Python and then into JavaScript where unfortunately they've mutated kind of badly. But there's still a really interesting mechanism for managing asynchronicity in distributed systems. The house call community has begun to Monads, and Arrows, Microsoft has something called RX, reactive extensions which allows for composing of events streams, very interesting stuff.

[00:01:16]
Unfortunately it's never been documented accurate or documented sufficiently.
>> Speaker 2: We do have a course by which covers essentially the observable pattern and how RX and are working everything. Just throwing it out there.
>> Douglas Crockford: Yeah. It's good stuff. It's just I wouldn't use it because if I'm putting it into production, I want to know how it works but it's been inspirational.

[00:01:43]
It's created a new form of programming called Functional Reactive Programming and examples include Flapjacks, bacon, and element, and others. But occurred to me that this list just isn't long enough. I'm adding my own thing to it and that is a library called RQ. RQ is a library for managing asynchronicity and server applications.

[00:02:05]
The thing that distinguishes it from the others that I mention, is that this one was designed specifically for what you do in servers. None of the other ones were. Everything can be made to work but I think for what you do in servers this one is gonna work better for you.

[00:02:22]
RQ is a very small library, that only contains four or five methods depending on how you count. If you count in Java, it's five, if you count in JavaScript, it's four. So let's look at the four, cuz once you do these four functions, that's the whole thing. So a sequence takes an array of requester functions and returns a function that will call them one at a time passing the result of the previous requestor to the next requestor.

[00:02:50]
Here for example we're gonna make a getnav requestor which will first read the file, and then get the preference, and then get the custom nav. Then we can do things in parallel. Now we're not adding parallelism to JavaScript, what we're doing is, allowing JavaScript to exploit the natural parallelism of the universe.

[00:03:11]
Cuz it's likely that you're gonna be calling services that are in different boxes or different networks. It's all going out in the universe, runs asynchronously all the time so you get to take advantage of that. Here we're gonna make a get stuff constructor which will, when it's called get the Nav, get the Ads and get the Message Of The Day, it will get them all at once.

[00:03:33]
The cost of this will be whichever of these three is the slowest. Then we can also have optional things. We can provide a second array of optional things. We will also go and get the horoscope and the gossip but we will not wait for those if they don't if either of those dozen complete before the main three complete, we'll just cancel them and return with whatever has been finished.

[00:04:01]
We can deal with races. These are the good kinds of races. We can start several things at once and whichever the first one to finish successfully, that's the one we get. We might be having trouble with our Ad network. We're dealing with three Ad networks and they're all too slow.

[00:04:17]
We tell them, we're gonna have a race. Whenever we have a position, we will ask you and two of your competitors, and whoever comes back first with a suitable placement will win. We can also deal with fallbacks, so we can try one thing. If that fails, we'll try another.

[00:04:35]
We're gonna do that to get on our weather. We'll first go to our local Cache. If that fails, we'll go to our localDB. If that fails, we go to the remoteDB. Now in theory, the fastest way to get the weather would be to have a race, but the whole point of having this kind of hierarchy is that we want to go to the remoteDB only as a last resort, and fall backs allow us to do that.

[00:04:57]
That's it, that's the whole metrics for RQ. We can start all the requesters at once, or we can start them one at a time, and then we can then take one result or we can take all of the results.