 All right, I thought it was very brave of her as well. So my name is Shannon Christopher Bosch. I go by Chris. My daughter is my namesake. My son's name is Christian. Somehow my wife was able to name both of my children after me. I didn't think we could do that, but she pulled it off. And I thought my daughter, I really told her, I thought it was brave to get up here and speak for me because actually I do this professionally. The hard part for me, I speak three hours at a time. The hard part for me is speaking for 10 minutes. So men's got the time we're going. All right, so today I'm going to talk about declarative versus imperative programming. But before I do that, a little bit about me, I have a lot of these same hobbies because I like to hang with my kids. TV movies, teaching, board games. I love programming. And then I also love to travel. And in fact, if you go look at my Google Photos thing and you looked at the evidence, the evidence would say my favorite thing to do in life is to stand in front of places with my camera and take selfies with my family. It has to be one out of every four photos. It's like family, get over here, form up. And so we took a trip to Spain this summer and this is my daughter and I looking at a big rock that's turned on its side. It's really cool. You can ask me about that later on. I thought that was pretty neat. So that's me. For my talk today, I want to give out a shout out to Tyler McGinnis. I knew I wanted to talk about this topic and I've been interested and I was on medium.com searching around and I read Tyler's medium article. I'm like, oh wow, that's exactly what I wanted to say. It was much better than I was gonna say it. So I didn't take all Tyler's stuff, but yeah, the spirit is really good. So check him out sometime if you're on a medium. He seems to be pretty articulate. So the very simplified 10 minute talk definition is when we're talking about coding, imperative is when you're talking about how to do something. It's how we're gonna go about it. And declarative is more just what you want done, all right? And for example, like if it ever ever takes a taxi or you take an Uber, the imperative thing is you get in a taxi, like for me, when I was coming here, if I'm coming from my house and I would say something like this, turn right on Lita and then go to Farah, turn right on Farah, then go to Holland, turn left on Holland. I would read them all the directions out and then drop me off at the taxi stand, right? Very explicit. This is exactly how I wanna get from where I am to Plaza Singapore or wherever I might be going. Where's the declarative approach would just be take me to Plaza Singapore, right? I don't care how you get me there, I don't care what route you take, just take me. It's easier, it's quicker, it's simple, but I've delegated a lot of the decision making off to the taxi driver, all right? And so there's some possible drawbacks if you provide too much details. Yes, if I've taken that route many times, maybe I know better than the taxi drivers the right way to go at four o'clock on a Tuesday afternoon, but it could be that they know a shortcut. It could be that a new road got built, that has actually happened to me a while out of the experience Singapore. They just built a whole new road that I didn't know was there, look at that. I was correcting a taxi driver a couple of years ago and he was like, no, this is much faster, sure enough, four lane highway that I, you know, brand new. Google Maps is a big one. I know how to get somewhere, but if I just put it into Google Maps or my loving wife, she types it into Google Maps and then starts telling me the better way to go. I'm like, honey, no, I know how to get to Vivo City. And it turns out she knew better than I did because Google Maps said there was traffic or congestion and we really should have gone the other way. More I'm talking, the more I'm gonna misspeak possibly, the more opportunity is for that taxi driver who maybe English is not his first language. Maybe my American accent is hard for the taxi driver to understand. So the more I say, the more opportunities for mistakes. And then of course, the more I'm talking, the less time I have to listen to my latest podcast, whatever I'm catching up on, AngularJS, whatever, might be a quick shot. Okay, so I'm more and more asking myself this question with so many experts in the world and me able to reach them, do I really need to know the details? When do I need to know the details? And if I'm not sure my way is gonna be better, maybe I should just sit back and give the experts a chance, all right? So you sort of understand that from the taxi metaphor, what does that mean when it comes to code? Well, some of the code that we do today, it's very imperative already. When you put up HTML, you're not telling it how to draw talk.js on the screen. You're not telling it what a paragraph is. You're just sort of defining, I want a header and I want a paragraph, you figure out how you wanna do it. And if you open up the same code in three different browsers, it'll look different. They might pick a different font, a different default size, right? But you just said, you know what? You know what looks better in Safari than I do there. Now, of course, you could over-specify and get the details, but you could just leave it at this. And then the same thing goes for SQL. When you select star from users where event equals ace of coders, you're just sort of gonna let the database system do that however it wants. It could have indexes, it could go fetch things in parallel or just have a single process. Now, these are sort of straightforward. It's hard to write a lot of, you have to put some work into doing imperative code and making these things not declarative, but JavaScript's a little different. When you start writing JavaScript, I just do a lot of things the same way I did them the first time I wrote JavaScript. And if I must be honest, I write it a lot like I would have written it in Java before I learned JavaScript, okay? There are better ways, and please forgive my code, I'm just being real honest with you here. When I just gotta get something done, this is what I'm gonna crank out. So this is a simple function that just is gonna take all the numbers in an array and add one to them. Yes, there might be a better way to do that, but just imagine any time you add a list of something and you wanted to change every item in that list somehow, correct the name, capitalize, lowercase, add something to it. So, you know, I'll typically make some type of accumulator. I make a brand new array here. I'm gonna iterate through my array with a for loop. And then I'm gonna, in this new array here, I'm gonna push whatever was in the last array. I'm gonna add one to it, push it, and I'm gonna go through that whole thing, whether it's two items or 2,000 items, it doesn't matter. And then when I've got my whole new array, I'm gonna return that back. So then if I call, if I have like an array of numbers and then I increment this numbers array, I'll get back an incremented array, right? Makes sense? Everybody with me so far? All right, we go like, okay, here's another very common example. All I wanna do is filter out all the names to don't start with capital S, right? So I've got an array, two names, 2,000 names, whatever it is. So once again, I make that empty array. I iterate through my array and I say, hey, if the array, each item in the array, because I is going, you know, up by one as we iterate through the array, look at the first letter, item zero. If it's a capital S, then hey, take that thing and push it into my new array, do that for all the items, return the results. All right, so simple, okay? All right, and I will tell you, I just reach for this all the time and I'm just so in the details of, this is the way I think of the implementation, this is how you do this. And I give you one last example. Multiply, this I don't want back the whole array operated on, I want back one single value. So I'm gonna give this function an array of numbers and I say just multiply all these numbers together and give me back the sum, right? Actually the product, product, not a math teacher. Okay, and so same thing, start with total one, I'm accumulating in this value. Okay, so one of the common things we start seeing here is all these things I have this thing up here that is, it's a variable, it's state. It's this thing that I'm manipulating as I go through the loop. And that's one signal that I'm sort of getting a little into the details and maybe I don't need to be. Now I'll talk about how that constrains things. Because that becomes important because us as developers today, we live in a very different environment than when I first came out of university. When I came out, all the processors had one core. There was no multi-threaded. There was time shifting and multitasking, but you only had one thread of execution. Today, all of us in here, we have services like Amazon Lambda where we can run literally a million function calls a month for free, for free, right? You can get that free server for a year from Amazon for free. So just a sea of computation, but those individual processors, they're not really getting any faster because not for the subject of this talk, but they are still continuing to multiply large and larger numbers. So when we write code, we wanna make sure that our code's ready to tap into all these many, many minions. So instead of doing this very serial approach, where we're sort of tying ourselves to one a minion, we'd like to just naturally write our code to where we can easily scale out no matter how many minions that we have to run our code across, okay? So that's the general idea. So I'd like to sort of kill all these birds with one stone, fix all these problems at one go, all right? So this is something you can do in JavaScript today. And actually, if you go through free code camp, I noticed this when Shannon was going through it, they teach this approach. They teach sort of the declarative first approach. So this code does the same thing as before, but if you notice it's a lot less code, and what this is actually saying, it's saying, hey, return the array that got passed in, dot map, and what map says is for every item in the array, do something to it. And maybe this, even if you've never seen this before, this is sort of intuitive. It says take for each item in the array and replace it with item plus one. That's what map does. Take each item, replace it. It can be X, it can be item, whatever it is, all right? And now if I do that same thing as the result equals increment numbers, I get the exact same response. But with a lot less code, but most importantly, there's no state. There's not that new result variable that I'm doing. And you could run this massively in parallel because if you leave it to the great algorithm writers, when they run map, if they see they have a whole lot of data and a lot of processes to work with, they can run this in a very parallel fashion and then just aggregate the final results when each process is done. This is what that looks like for the filtering operation. Now I didn't want to have all the names. I just want to keep the ones that start with capital S. Same thing, you take your array and you do dot filter. And what filter wants, it wants a boolean. It wants a truer of false. It just wants something that's gonna out. It evaluates a truer of false. If it evaluates to true, it stays in the array. If it evaluates to false, it gets discarded. It gets filtered out. So here we have filtered if item, for each item, see if I can get my language up for each item, if item of zero, the first letter, is equivalent to the capital letter S, keep it in the array. So that's filtered. All right, and then the last one is reduce. For reduce, what reduce does, this is gonna let us do our multiply. Reduce is probably the more complex one. And I still can't glance at reduce and see what they do. I always have to sort of sit back and go, what's actually happening? Because what reduce tries to do is, let's say you have two numbers or 2,000 numbers in your array. It looks at the first one and some default value you get. In this case, this little one here is the default value I gave it because I'm gonna multiply the first number by one. If I was adding things up, that number would probably be zero because I wanna start with zero and accumulate up, right? But it looks at that, you start a number, the first number, and then it does something to them. It takes the first and the second, in this case, it multiplies them together. Then it moves over, gets the next item and does that operation with the result of the first two items and then it continues on. So in my case, it's gonna multiply the first two together and then the sum of that, multiply by the next one, the sum of that and so forth. If you're adding numbers, subtracting numbers, anything where you're combining things, that's how you would do reduce. And if you can imagine a function where you could build it up just by squashing individual items together to get to one answer, then reduce is possibly something that you could use. All right. And so, I'm very intrigued with this question these days because I do ask this question, what do I teach my daughter to do? When she says, hey dad, how do I just go through all of these items and update them, change them, transfer them? My gut tells me, oh, it's called a for loop. For I? Well, I was like, but that's wrong, right? Surely we've come somewhere over the last 15, 20 years since I cranked out my first for loop in Java. Oh my goodness, before that, another language, right? You know, I should say, oh, that's easy. You remember that talk we gave and I was up in front of everybody? You just do array.map and then we just have to come up with a function. And in fact here, you don't have to put it right here. You can actually put the name of a function here and then write your function to be as big and complex as you want. All that function's gonna do, it's gonna get one item and it's gonna return something back. You're gonna map that function across all the items in the array. So I wanna say, oh yeah, I'm gonna tell her to do that. But the problem is, well, I practice what I preach, right, because one day is gonna come that we're pair programming and I'm helping her with something or we're doing something together and she's gonna look and go, dad, why are you making this results thing? What is all this junk? Why didn't you just do a array.filter? And I'm gonna feel so, actually I'm not, that's gonna be a glorious day. I'm looking for that again. Yes, this is awesome. All right, from my mouth to God's ears. Okay, all right, so I wanna practice it. If I tell my kids to do it, I need to do it when nobody's around and I'm writing my own code in case they ever see my code. And then will I ever prefer to read declarative JavaScript? Because I tell you, there's something comfortable about this for me because when something goes wrong, I come down here and I go console.log, I don't know. Anybody know that, right? Or from not array, I like from array to, you know, just put five here, right? Look at the first five. I can mess with this, you know? And I've had to because when you do stuff like this, you end up with these off by one errors of these state errors. You've been there, right? Okay, so that's better, but if that goes wrong, what do I do? Where do you put the console statement? Where do you, you know, so, so, I hope. And the other thing is when someone walks up to me with their code, like somebody saw me in the audience and I see you at a meetup and you're like, hey, can you tell what's wrong with this? I'm gonna see that dot reduce. So I'm gonna be like, I can't. And the worst thing I could do is say, could we just turn this into a for loop? All of you like your code. All right, so there are reasons to be more declarative. You should get better readability because it's very explicit. I just want every item incremented by one. I wanna combine all the items together. I wanna filter out these things. It should be easier to read. It should be much more scalable because there's no state now. We can do it massively in parallel, right? JavaScript's got its own little neat things when it comes to parallel on the server side, but like other languages, when you do the map, absolutely parallel. It's a lot faster. You get to tap into your hardware. So you get to be more scalable. You should have fewer state related bugs because you're just not updating states. There's less for you to mess up. And you get to stand on the shoulders of giants. All those people now that you've abstracted your way, I don't care how I get to pause in Singapore, just get me there. Google, Facebook, Twitter, people are doing things a big scale. They can go create better and better libraries. You just type dot map, dot filter, dot reduce, and it just happens, all right? So with that, that's all I have. Oh, just got out. Eventually from declarative to imperative. It's eventually important to move from declarative to imperative. It depends. If you've got to crank out a whole lot of code all by yourself, you could make an argument. I need to write fewer lines, debug fewer lines. I need to read fewer lines. And so less is more. When something goes, when something's not working the way you think it should work, then yes, right? But I'm talking something different. This is different than understanding how a for loop or how mapping works versus how should we write our code. I don't know, I'd love to have a conversation with someone, though. When should you use a for loop instead of using map to do mapping, reducing, or we're filtering? Other questions? Yeah. Oh, one in the back. Yes, sir. What do you think about a for loop? I don't use the for loop. Okay, but I'm a rare bird that I jump back and forth between four languages. So it just doesn't stay in my head when I see it. But it comes in every version of JavaScript since when? The beginning or? Oh, that's like four, isn't it? Okay. There you go. Okay, well, there you go. The iterators, the iterals. Yeah, yeah. Okay. In practice, besides the whole readability thing, what are the few situations where you find yourself thinking, should I write this empirically or empirically? I think it's more, if you can do it declaratively, maybe once again, I have not practicing what I preach because I just go with my own habits. But if 250 kids are learning JavaScript this year, right now, to play as encoders, I am concerned if the declarative way that free code camp teaches is better or worse than the declarative or imperative way that code combat teaches, all right? And I wanna have that debater up, which is better. I could argue that the map filter and reduce is just easier to understand and read if you started from the beginning, right? The problem is when you first teach someone to use a for loop and then, oh, by the way, you have to go make an accumulator. And it has to be inside the loop. Oh, no, wait a minute. It has to be outside the loop, right? And this is different. And I've been asked that question. Should it go inside or outside? And you wanna go, it doesn't matter? But wait, wait, wait, it does. In the function, out of the function. So it's less to teach in the beginning because you just say, hey, you have a list of items. Let's go change every one. We need one function. And the functions get very simple now because you just pass the item in and you get an item back. They're very easy to test as well, okay? So, but when do I walk away from declarative and go imperative? When I don't actually know what's going on, I need to put console.log statement section. Probably. You can actually console.log inside that too. Yes, you could. So inside where that function is, I could actually put multiple statements, right? Or probably what I would do first is I would just break out the function and I'd make a very simple function. And that's probably something I also don't do enough of that I like the idea of is every function or most of your functions being very simple functions that take one item and return to or false or one item and return the mutated item. That would be great if my code looked like that. The pureness of the function. Yeah. I've also seen a lot of people talk about it when your code is really sort of ugly and you don't like it. One of the first things you could do is make it more functional and declarative is sort of, it is in that same direction. Yes. You, when you're teaching the kids, do you break into the implementation details of map or filter where you just kind of tell them, this is map, this is what it does. Don't worry about it. Or do you actually like eventually go through like recursive functions or anything? So for me right now, I don't teach an algorithm's course and I actually don't teach an object-oriented course anymore. For kids who are playing like in the national competitions, it's whatever you need to do to get it to work. So go get it. If the overdies, you're awesome. If your code's better than John's code, you're a little more awesome than John's. And so it's just making it work, right? And there's this sort of like a test-driven development approach, right? You know, we'll worry about refactoring when you get to university. But in an architecture class, where I'm trying to teach somebody to make code that's very, very scalable, I will very quickly say, let's stop doing for loops and Java. Let's do this thing called streams. And let's go to a Java stream. And inside a stream, you do map, filter and reduce. You don't get to do for loops. You don't get to manipulate state because then it wouldn't work. So when you, so a lot of kids will have a bad habit when I see them where they think everything has to be loaded into memory into a collection or array before they can do something on it, right? And it takes a little bit of reprogram to teach them, no, no, you can just stream it off the desk and just be throwing the data away as you see it. You don't have to wait till you have it all. And even in JavaScript, it's becoming more and more like that as well, right? When you start teaching things like observables, right? So maybe that could be an advanced topic sometimes. Once you're working with observables, you're gonna want to do everything, probably map, filter and reduce because then you get to do really cool stuff with it. But it all comes back to that. You just want to back away from the state. Once you're back away from the state, you get to do a lot of cool new things. Would you like to talk on observables, I feel it would be. We'll talk offline. See if I can get Christian or Shannon to come back with me. Any other questions? All right, thank you very much. Thank you.