 Thank you. It's a great pleasure to be here to talk about something that I'm sure we all share with the common excitement about programming and how we can develop software and definitely exciting times right now with a lot of changes that we have seen over the past several years. But we started a long time ago. But before I get started, let's do a little warm up also to just reflect on certain things that we need to be a little bit aware of. So if I could kindly ask you to just stand up for a minute. So that's good. It's good to be standing, isn't it? That just gets a little blood flowing. Just look around. These are the people that we form a community, right? We get excited about programming. We share our passion to program. I want you to continue to stand. However, I want all the men to sit down. And I want the ladies to be still standing. And I want you to look around how few we have women here. We need to change that, right? That is an inequality that we definitely have to fix. And of the women here, is there anybody who is not a programmer? So everybody's a programmer. Excellent. Well, give them a hand. Thank you for coming here, absolutely. So we need more of that, absolutely. We need to really build it. Among the ladies standing, and I'm going to exclude Lena because I know her fairly well. Other than Lena, I want one of the other ladies to come here and present with me on stage. How about that? Who wants to join me? One of you four other people, unless I'm counting wrong. Who wants to volunteer? Don't be shy. No? None of you? Who wants to volunteer? I'm going to wait. We've got time, right, Naresh? I'm going to wait until one of them comes and joins here. Who wants to come? Oh, even better. Thank you. Give her a hand. Thank you. Give her some space for her to walk over here. Thank you very much for coming. What's your name? Aletha, pleasure to have you. He's going to get you a microphone, so we'll just go up on stage and we'll do some talking. So I think he's bringing it over. Excellent. Well, so while she's going to get the microphone, let's talk a little bit about this. I travel a lot. I go on flights quite often. And the other day, I was sitting next to a gentleman, and he asked me what I was doing. And I said, well, I'm a programmer. And then he said, that's the easiest job on Earth. I said, that's great. Somebody thinks so. May I ask you why? He said, because all you have to know is zeros and ones. I said, you were absolutely right. But you know why I could pay the big bucks? And he said, why? Because I know in what order to put them together. So absolutely, this is a fascinating field we are in. So tell me a little bit about yourselves. What do you do? Basically, I am Assistant Vice President in Comviva. All right. So I'm handling the team, but I am basically a programmer. Excellent. Wonderful. Wonderful to have you here. So I want to talk about quite a few things. We need to get the slides up on, if you would please. So we're going to talk about, there we go. Excellent. So we're going to talk about programming. But I want to start with something else this morning. And for the next about 15, 20 minutes, I'm not going to talk about programming at all. I'm going to talk about life as we know it. And I want you to think about this word called mainstream. That's what we're going to. I totally apologize. The lady is still standing. Please sit down. I totally forgot about it. So mainstream, I want you to think about this word, mainstream. Now, we've been wrong. Have you been wrong before? Many times. OK. I'm wrong most of the time. My wife reminds me all the time. So we've been wrong several times. But I'm not talking about you and me here. We're talking about we collectively as human beings. We've been wrong so many times. In so many different levels, we've been wrong over and over and over. And it's just amazing to see how broken we are in terms of how we have been. So let's talk about a few things. I'm going to start with the quiz for you. There's a ball up here. You see that? I'm going to drop it. What's going to happen? Just drop it. What's going to happen? It'll fall down. How do you know? Because of the gravity, we say that walls fall. Well, it's because of gravity. Who told you about gravity? We have read in the book. We have read, right? But do you know that there was a time when they didn't know about gravity? Yeah. So what did they do before that? The lines, but it will be there. Well, sure. I mean, gravity did exist before they knew about gravity. I'm not denying that. But they didn't know about gravity, right? For a long time. But it has given the name, and Newton has given the name. Ah, Newton. I was waiting for that. So it turns out that we all attribute this to Newton, right? The word gravity comes from the word gravitas, which is actually for heavy. And this was introduced by Aristotle back in, oh, what, fourth century BC. But really, you do know who actually talked about gravity? A guy not far from where we are standing. His name was Bhaskar Bhattacharya. And he really talked about gravity way back in the 11th century. So this is something that a lot of people have been interested in. And then came along, of course, Copernicus and Galileo talked about this, too. And then, of course, Kepler came along, and Hoke, actually, Robert Hoke. So there was a time, actually, when Robert Hoke was actually taking more credit. Please reduce the volume here. So Robert Hoke was taking more credit, actually, for the work on gravity. But of course, we have to be a lot of this to Newton. But it turns out, Newton actually is not really as much towards gravity as his work was really towards the inverse square law of gravity. And that's where his main contribution was. But again, you can look at the time span. This was what, in 1600s, several centuries it took for us to really understand this. We take time. And it takes time for us to learn several centuries sometimes. But let's talk about something else. What's the center of our system where we live in? And again, it really is the question of, whom do you ask, and when do you ask this? So the Roman Catholic Church actually believed that Earth was the center of the system as we know. And in fact, if you were around that time and you decided to speak against the Roman Catholic Church, really bad things can happen. And so what was the belief, the held belief then? The held belief was that Earth is the center. And of course, there was one problem. There were these sailors. And the sailors went sailing. And they thought, there's something wrong here. Because if Earth was really the center, and if we apply all this math, why are we deviating from our course? So they were kind of puzzled. Something is really wrong here. They quite didn't know what was wrong. And more important, they quite can't speak against the authority because you're speaking against the church. So they kind of quietly put up with it. Until, of course, Copernicus came along, and he drew this little diagram to show maybe this is the way things are. Of course, he was not right still. And then eventually, Kepler created this elliptical idea. And then, of course, it turns out that Sun being the center was not really mainstream. And if you said Sun was the center, you would have been a fool. In fact, there was one such fool. His name was Galileo. And I say he's a fool because that's what everybody said. Galileo was arrested, actually. And he was kept on house arrest until he died. And why? Because he said, you guys are wrong. That Earth is not the center, and Sun is the center. So he was not the one who actually discovered this, but he's the one who was very vocal about it. And of course, people didn't like because he was talking against the established belief because it was not mainstream. So what happened? Well, that's what happened to Galileo, unfortunately. Well, let's say for a minute, a good friend of yours comes over, and your friend says, I'm going to have a baby. And she asks you for any advice, right? Do you think I should hire a midwife and have the delivery at home? Or do you think I should go to a hospital? What would be your advice? Well, tell me more. Hold on to the microphone. Yeah, they gave some advice. Whatever you know about it. Right, but what's your advice? If a good friend comes to you and says, I'm going to have a baby, should I do it at home or should I go to the hospital? What would be your instinctive advice? Generally, these days we say no. Go to the hospital. Absolutely, right? Well, sure, that would make sense, isn't it? Well, but unfortunately, though, you wouldn't have said that if this was 1800. And the reason is that back in 1800, people had an opportunity to die three times more in a hospital than at home. Now you may wonder, why would people die if they go to the hospital? Well, again, they didn't know what the reasons were. And it turned out that about 10 to 35% of mortality rate was really very high mortality rate was resulting a result of infection. But of course they did not know about this. And the first person who got a little hunch about this was this gentleman who was a Hungarian and he said, hey, looks like there's germs. And he did something by accident he discovered it. He started heating things. He started boiling things. And his patients died a lot less than the patients of other doctors. He didn't quite have an explanation. He said, something is weird going on here, but I'm gonna really boil things and people are dying less. And then he said, there's germs. Well, the doctors came to me and said, really, germs, have you seen them? No, I haven't seen germs. Well, you're lying. So they actually stoned them to death. This guy died because he wanted to help people and kill fewer people, right? And of course, eventually, we know that washing hands is actually a thing. Washing hands before meals, washing hands after going to the restroom, washing hands just after coming home, after going out. These are very simple practices to stay healthy, right? We know this. But that was not the mainstream back then. In fact, Louis Pasteur and also Joseph Lister are the people who actually made a lot of progress in this area. Before the time of Lister, the hospitals would actually open the windows and try to get the air out because they thought something in the air was killing the people. And back then, the doctors, really good doctors, walked around with a lot of blood on their coat. And the great, the doctor was, that there was more blood on the coat until Joseph Lister once said, hey, you guys are killing the patients, do you know? And of course, they removed his license and they said you cannot practice it. Well, apparently, washing hands was not mainstream. And what is this here? We hold these truths to be self-evident that all men are created equal. Do you know where this is from? No, that's from the Declaration of Independence for the United States. Well, if you notice something here, it says all men are created equal. And I was actually in Mount Vernon, which is Washington's, whatever you call it, residence when he was alive, of course. And as I was walking through it, I was amazed at one thing. I looked through the window and there were slave quarters. And I said to myself, how could you write all men are equal and you could have slave quarters, right? And that kind of bothered me a little bit. And then, of course, Thomas Jefferson is known for having a lot of different slaves. George Washington had them too. And I always thought about, if they really wanted equality, why didn't they give equality? And there's a really good pragmatic reason for it. When you're trying to fight a war against the British, well, we know exactly what that means, right? We have done that too. And when you fight a war against the British, you cannot ask for independence from the British and abolishment of slavery because then you get, this is like programming, right? You don't change two variables at the same time, right? The really bad things happen. Well, that's exactly the point here is that he was very practical. He realized what the problem is. Well, it took about a hundred years later, almost, he were to take for this fine gentleman to come on board, right? Of course, Abraham Lincoln, who really declared emancipation and he really put an end to slavery. But unfortunately, you can turn a lob, but it takes a lot more to turn the minds of the people. It took another hundred years and it turns out that sitting next to a colored person was not mainstream. And this wonderful lady here, called Rosa Parks, was one of the persons who said, I will not get off from the seat and give way. And so she started a very interesting movement back then and back, you know, behind her, you can see Martin Luther King. And so she really started a very interesting movement. And this is against things I learn about history that fascinates me. Woman's suffrage, women did not have right to vote. And that just doesn't make any sense to me. Doesn't make sense to you, right? I mean, why would you not want women to vote? And it turns out that in 1913, this was a picture taken from that time. And if you really look at this, women having the right like men to vote was not mainstream. So again, let's think about mainstream for a second. This is the years when voting rights were given to women. And I wonder why they should be given in the first place, right? They have the every right to have it. And when I read history about these things, about all the different things committed, I always look at these and I ask myself, what's wrong with people? Were these people born to women? They have sisters, they have daughters. And again, think about mainstream. So the word mainstream is one of the words that scares me the most. Now let's talk about programming. If you go around people programming, what is mainstream in your observation? Hold the microphone over here when you speak. So what is mainstream? What are you seeing your people use? Mainstream, basically we talk about what is the kind of language they use. Right, yeah, so what languages are they using? Nowadays only Java. Java, they're using Java, that's okay, that's good. But if you think earlier we will see C++, now it is more of Java. Okay, so C++ and now more of Java, maybe a little bit of C-sharp, depending on the company. Yeah, a little bit of C-sharp. Right, now, so this is very fascinating, right? Why is Java and C-sharp so popular? Do you know why? With this fast programming we can do as compared to C. How? Well, but how is- Many things which are already there, you just have to use those things actually. That is the key, right? So this is fascinating. When you start programming in Java, what does the syntax look like? It is similar to what C or R are. Exactly, it is much like C++ except, you know, remove a few things like delete and destructors, right? So why did C++ become so successful? Because it looked like C. Yeah, I can say- Right? Because- It is C only, so it is grown from C. So what does that tell you? So basically, USA mainstream we can see C only. Well, no, basically the idea is we don't want to change. We are a bunch of lazy people. No, no, people are now, I mean, if you see new generation, all are coming with Java only. But is it mainstream, right? For them, it is Java is the mainstream. Yeah, but why? That's the whole point, right? We are pretty lazy, we don't want to change. I will say productivity, and because you can write applications very fast as compared to what you can do- But that's a fallacy, right? Yeah. That's not true. Have you even tried, even given chance to other things? No, maybe in the colleges also they teach more of Java. Now we have to blame the faculty. Not the faculty, but that is actually, I'll say that to them. Please do, they deserve the blame, I'm not saying they don't. I'm one of them, absolutely. So the point is, it is fascinating to see why some languages become popular, and just because a language is popular doesn't mean it's better. It just means that it is popular, right? That's all it means. So, absolutely. The Java byte code is full of go-tos. So we, you and I cannot use go-to, that doesn't mean there's no jumps happening in the code. So just compile your Java code and look at Java P minus C, and take a look at it, there's go-to all over. But Dykstra's work was phenomenal in that. He really said in structured programming, we shouldn't arbitrarily jump across code, we should follow the structure. Well then came along the structural programming. Then what happened? Well, these two guys, Dal and Nygard, where the two people who actually created the very first object-oriented programming language. These were two Norwegians, and they created this. So I'm gonna ask a quiz, and I'm gonna ask you, but anybody can answer it. Can you take a wild guess what year did object-oriented programming become mainstream? Throw a number at me. Mainstream, everybody started using OOP without even questioning what year was that. Doesn't matter what language, what year. I said, did I hear 95? Did I, 93, 94? Okay, I'm gonna say 1990, right? Give or take 1990, just hold on to that. Do you know what year these two guys created the first OOP language? 1967. Now think about that for a minute. 1967 to 1990, how much time is that? 22 years. If object-oriented programming was a human, it had a terrible childhood. Nobody cared, right? Until one day it was 22, and they said, hey, handsome. Right? Look at this, right? So what a long time isn't it? 22 years. Just keep that in mind for something to become mainstream. We'll come back to that. So, but then what happened? Well, OOP became mainstream, and what have we been doing mostly? We create objects, put state into objects, then what do we do? Call methods on it, and now the objects have become bulky, bloated, heavy, and somehow this doesn't seem right, but mainstream, most people do this, right? Well, it was uh-oh, but it soon became uh-oh, right? And this guy here is the guy who termed object-oriented programming. He didn't create it, but he gave this name for it, Alan Kay, and he said, I invented the term object-oriented, and I can tell you I did not have C, plus was in mind. And Javi is not very different from this actually. So what is wrong? What's wrong with it? One of the things I do a lot of code reviews, and I can't tell you, have you asked me what do I do mostly in code review these days? I beg people, please remove that state, because objects become very, very heavy in state, and when objects are heavy in state, it becomes hard to maintain it, concurrency goes out of the door, it becomes very difficult to program it. Well, object-oriented programming certainly was a great idea, but there were a lot of other great ideas, like this one here. Sometimes ideas are really great when you look at them first, but they turn out to be not so good afterwards. Like this 10-year-old child discovered, they created this little pencil. What a great slogan in there. It says, do cool to do drugs. Why not? Well, a few weeks went by, the kids started using the pencil, and they said, cool to do drugs. Do drugs, drugs. Well, that didn't quite work very well, and the kids said, is this the message we want to really send, right? So this started out as a really good idea, but very quickly figured, it's kind of like OOP, right? It was a great idea to begin with, and then after a while we realized, did we really mean that, right? Or this particular example. I'm a huge fan of Starbucks. I mostly spend time in Starbucks, and not only in their coffee, but working over there. In fact, I have a niece, and one day my sister-in-law went to my niece and said, where does Uncle Menkett work? And she, without any suspicions, she said, well, of course, he works in Starbucks, right? Because she actually thinks I work in Starbucks, because I'm most of the time in Starbucks, sitting there encoding in the corner, so she thinks I'm working in Starbucks. But somebody decided a great idea to paint Starbucks on their truck, and this really ended up being a disaster. And so, we got to kind of know where we placed things as well, right? Again, great ideas kind of turn out to be a little suckish after a while. Or this was a campaign that Coca-Cola wanted to do. They were selling in the Middle East, and their market was kind of becoming a little low, and so they decided to have a nice campaign to increase the sale of Coke. They put this campaign, and all of a sudden, they couldn't sell Coke anymore. Eventually, they figured out what was wrong. These guys read from right to left. So there was a guy who was really good at running, drinks Coke, and he's almost dead. Why would you want to buy Coke anyways? Again, context matters, right? So how do we really know whether something is right? So what do we do every day? So you said you're involved in programming. I'm sure you work with programmers. What do programmers do? They program. So we write code, okay, great. So we write code, right? What happens after we write code? We fix bugs. Yeah, definitely writes apps, absolutely, that's what they do. And then what happens when you fix bugs? We write more code. This is called courage, right? And then what happens when you write more code? We fix more bugs. And then what happens? We come back and write more code. And then what do we do? We fix more bugs. Isn't that what we do? Every day we go to work and do this, right? Programmers are the most resilient in the world because the compiler spits at you, the computer curses you, your boss tortures you, everybody around you asks you, are you done? And then, you know, if you ever wanna know what programmers are like, you should see people use software. I mean, my wife, for example, right, she is the most generous person I know, but you never wanna be near her when she uses a program. Man, the way she curses, right, the programmers, do they ever know how to write code, right? So, we do, right, we get cursed every single corner we do. And then what do we do after we fix all these bugs? We come and write more code. What is this called? What was that? Desperation. That is, again, mainstream, right? I can't tell you how many times programmers come to me and say, yeah, this optional programming stuff, yeah, how do you debug that? I wanna cry when I hear that. Why don't we, for a change, say, how do you test that? That would be a really different viewpoint, isn't it, rather than how do you debug that? So, functional programming, let's talk about it. Where did that come from? Where does it go? What does it work? I'm sure everybody in this room knows about one person, Alan Turing, right? Well, this was Alan Turing's professor, Alonzo Church, and this was, well, let me ask you this question. What year, I'm not gonna ask you the mainstream question, we're not there yet, but what year do you think the first object-oriented programming language was created? I heard it hurt 70s, earlier than that 50s. Well, even better than that question. What year do you think Lambda Calculus was introduced? 1929, now think about that for a minute. This is 2014, and we are just about getting excited about what these guys created in 1930. How many years is that? 84 years, that's what one or two generations of that, right? Now, 84 years later, so when somebody comes to me and tells me that things change very fast in computer programming field, I ask them, what are you smoking? Just said 22 years for, oh, Peter, become mainstream. Now we are saying 84 years for something to be even recognized, and then we say, oh, things change very fast. We have a different definition of fast altogether, right? So things change very, very slowly in our field, apparently. So Alonzo Church was interested in computability. What is computability? What are they talking about in here? Well, back then they didn't have computers, at least the way that we know of computers. And they were curious about whether things would actually run, things would actually halt if you ever were to be able to run them on machines. And so they were interested in computability. Now, if somebody comes to you and says, give a name for a, let me, all right. So if somebody asked to name a function, what would you call it? You'd give a name like X, Y and Z, right? Well, these guys were not very different. They give it a lambda. There's purely a named lambda expression, right? That's what they give. Well, it turns out they were interested in the halting problem, and of course, the first thing that they were very interested in was that back then, and they were very interested in a way to represent functionality, things that can be expressed as something to be computed. And then, of course, John McCarthy created LISP. This was back in the 1950s, one of the very first languages that actually implemented a lot of these wonderful concepts. In fact, I'm gonna make the claim that most languages today are working so hard several times over, and we are still failing really. But wonderful language that had the power. But we're gonna talk about pure functions, and I need your help right here. So what is a pure function, and why do we care about a pure function? So I'm gonna give you a little quiz. Are you ready for it? All right, so what is two plus three? She said it's always gonna be five, even better than the answer I expected. Why did she say always gonna be five? Well, that's because it's gonna be the same, right? No matter how many times you call it with the same import. So plus is an example of a pure function. But let me ask you a different question. How much more time is there for this talk to be over, right? You can look at your watch and tell me how much time it's gonna take. If I ask you the same question two minutes from now, the answer is not gonna be the same. That's not a pure function, why? Well, think of a pure function, let's say for a minute, let's say what does it mean to be a pure function? Let's think about a little function. Let's say this is a function, and as long as you call this function with exactly the same import, it's gonna give you exactly the same output, which means this particular function is pure. What does that mean? It is not going to be affected by anything outside, and it's not gonna affect anything outside. So when you call this function, it doesn't say, oh, I'm gonna quietly sneak around and modify a state, it's not gonna do that, right? So a pure function doesn't change anything outside, and it's not affected by anything from the outside. Now let's say we got two pure functions. Well, if these functions were not pure, meaning they start a changing state, what would a compiler, poor compiler do? A poor compiler will come across this function which is impure, and it would touch it with a nine-foot pole, right? It's like, I don't wanna mess with this, because if I try to optimize this, something will go wrong, and I don't wanna create a program that's buggy more than what the programmer has done, so as a result, a compiler would not do much optimization, but if this is a pure function, what's gonna happen? Let's say these two functions are pure. They don't really affect anything, they're not affected by anything. I don't really need the result of one to use the other, independent of each other. I just need the result of those two elsewhere. Well, guess what a compiler could do? A compiler says, I'm gonna run function one first, and then I'm gonna run function two, right? Or the compiler says, you know what? It looks like my registers have some data. Performance-wise, it's much better to run function two first, then I'm gonna run function one. Is that okay? Absolutely right, because it doesn't matter in which order you execute these two functions, because they are independent of each other. They don't need result of one on the other, and guess what, when you're running one, it doesn't change any global state, they are pure. Now, in fact, a compiler which has knowledge of the hardware, we call them the JIT compiler, remember Java for example has two compilers, Java C and the JIT compiler, and the JIT compiler says, oh, look what I found. I got multiple cores, which means I can run these two functions concurrently on two separate cores. So this kind of optimization, where it can move things around is really called referential transparency, and referential transparency means no matter how you order the functions, the result is exactly the same, and as a result, you don't have to worry about introducing errors in the code. Here's a very daily example of referential transparency. Well, I looked around this room and I found something really nice. Everybody is decent, everybody has clothes on them, that's a great thing, right? I can't say this in every city I visit. Well, that's great, but here's the deal, and you know who I'm talking about, right? Some of you here put on your shirts before you put on your pants today. You know who you are. There are other people in the room who put on their pants first before they put on their shirts. You also know who you are, Nareesha, I know. Don't be, no, we don't want to know this, but you know it, it's your little secret. But the beauty is this, does it matter? It doesn't at all. You are decent, and we're talking to you, and in fact, tomorrow morning you can decide, okay, this is a fascinating thought, I'm gonna change my ways. I'm gonna put my shirt on first before I put my pants on. Don't worry, the world will still be a safe place, right? That's referential transparency. It doesn't matter which order you put your shirts and pants on as long as you show out in a decent way, right? And exactly the same thing compilers can do. Compilers can optimize code, they can rearrange them, or run them in parallel if they want to, and why, because such optimization can only be done when a function is pure. If a function is not pure, it becomes extremely hard for compilers to perform such optimizations. So given this, when we talk about programming, if you look at Java, C, C++, most of the mainstream languages, they got a distinction between two things. They got statements, and they got expressions. I wanted to say the word statement. They feel grim, they feel sad, they feel like something was taken away from you. That is a statement, right? What does a statement mean? Think about this for a minute. Statement, by definition, causes mutability. Because what does a statement say? Do some work, but I will never return a result to you. So when you call a statement, what does a statement do? It does some work, leaves stuff and says, I'm done. Hey, what was the result? I won't tell you. Go get it for yourself if you want to, right? So statements are evil by, see, talk about statements, bad things happen. Statements are evil, right? Because if you use statements, you are condemned to face mutability. On the other hand, expressions, just say the word expression, do you feel light? You feel, I see people smiling already, right? So expressions are like that. What does an expression do? It returns a result to you when it's done, right? That's what an expression is. So really powerful functional language has no statements. It's a little hard for us to imagine if we only programmed in mainstream languages. But truly functional programming languages don't have statements, they only have expressions. What if a language has no statements at all? You only have expressions, you can compose very nicely. Let's take some examples here to play with. Well, here is an example to get a feel for how this programming is gonna feel. We are used to one way of programming for a long time, right? So I got a little code here. I got a list of some names. And I wanna know if our good friend Nemo is in the list. So what do we do? First, we say boolean found equals false. Anyone who has written code like that? Everybody in this room, right? What do you call this? A flag, isn't that true? But this is called smell. It's a real bad smell. You should feel that your nose should twinge and say, that's ugly. Anytime we use flags, it should feel like that. And then what do we normally do? Then we say far, and then we say string name in names, right? And then we painstakingly say if name dot equals, and then we are looking for our good friend Nemo, obviously. Then what do we do? Then we say found is equal to true, and then we break out of it, and then what do we do when we are done with this? We output found, right? Nemo, and then we ask the question, and then we could of course say found, and we could display the result. And it says found Nemo true. We can see the result being displayed up at the top. Anybody who has written code like this before? No, everybody, I know you're reluctant. You feel really ashamed, right? This is, writing this flag is a way to lose self-confidence, right? You're like, really? I don't, that's, this is why programmers are like, the way programmers are, right? We don't look at people. We don't talk to them. We are quiet mostly. The other day I was at the dentist. The dentist was happily talking to me, and suddenly the dentist said, what are you doing for a living? I said, I'm a programmer. And then there was a quietness in the room. And a few minutes later she said, what are you for a living? I told you I'm a programmer. She said, really? I said, yes. She said, no, you talk too much for being a programmer, right? So you're supposed to be like grim and quiet and not talk to people, right? Well, we do this because that's what we do, right? Code, code, code, and we do low level code like this. It kind of gets into us. But if you look at this code, this is called primitive obsession. We gotta rewire our brains. It turns out there's a trivial way to do this. And oftentimes we don't think of it. So rather than doing this, how about saying found Nemo one more time? But this time all I'm gonna do is simply say names.contains, and I'm gonna simply say Nemo one more time. And we can see all it took was that one line of code. Of course we use the contains method on the collection. Now, this is a very trivial example. So what if we can do very similar to this for every single thing we do? What will happen? How would coding change that? What's the biggest difference between these two? Syntactically it's not a big deal. Semantically it's a world of difference. What's the difference here? The difference is rather than being primitive, we are being more communicative. We are expressive. We are communicating our intention a lot better in this case. So in other words, we could go off and start coding in the imperative style, and that's what mainstream is. Mainstream programming today is imperative programming. This is what people do. I teach at the University of Houston. I teach remotely. I don't live there, but I teach remotely. And one of the things I did about two, three years ago, maybe a little longer, is the department said, do whatever you wanna do. I said, I wanna offer a course where students will learn eight different languages in one semester. And they said, why would you do that? And I said, when they finish the course, they should know there is no one way to do things. I wanna shake their faith. I want them to come out and say, there is no one way to do things. We gotta go figure out what's a better way, depending on the context. And most people come into the class, have done programming in mainstream languages, C++, Java, languages like that. And the very first week, they start programming in Haskell. They start programming in Erlang. They start programming in Clojure and Scala. And you should see the way their faith changes rapidly within the first two, three weeks of the course, right? Because they begin to say, oh, there is actually a different way. They're not saying better yet, but there's a different way to do this. And then you could see light bulbs go in their phases. They're like, ah, what a difference. We could actually do this very differently, right? And it's a very different way than they're used to. So one of the things to think about is, when you write code in imperative style, what do we do? We tell what to do, but we tell how to do it. That is called a waste of effort. Because when we say what to do, well, we still need to say what to do, because we are the programmers. But if you tell how to do it, there's a pain here. If you say how to do it, and if you wanna change how you do it, what's gonna happen? You gotta change the code. So the more work you put, the more change you have to make. And as a result, this becomes a burden. It's very low level and primitive. And how does that feel when you write code in imperative style? Well, this is the way it actually feels, right? It feels like that. Every day that's how programming feels to us, right? But it doesn't have to be. We could program in a declarative style, and when you program in a declarative style, it becomes very expressive. This is a very trivial example. Nevertheless, every bit of it we should try and see if we can do it better, and we can definitely code in an imperative style versus a declarative style. That becomes a lot better. So in declarative style, we tell what to do, not how to do it. We use library of functions to decide how to do it. I'll come back to this in a minute. Let's say I wanna double the elements in a list. How would I double the elements in a particular list? Let's think about that for a second. So if I wanna double the elements in a list, I would say something along these lines, right? So let's take a list of values first of all. Let's say integer, and I have a list of numbers. We'll call it numbers here. And let's say this values are, let's just take simple values for a minute. One, two, three, and a bunch of values. And I wanna double these values. So how would you double the values in a list? I'm sure everybody has done this, right? So list integer doubled equals new array list of an empty array list, right? We do this first. Very painstakingly. Then we say for int element in, and we say numbers. And then what do we do? Double the dot add, and then E times two. And then we painstakingly add to it. And then once we do it, we can go ahead and display that result. Now again, look at this code. It should tell us something is wrong here. And what is wrong? Primitive one more time. We first took in on ourselves. We said, well, you first have to create an empty list to begin with. Then you gotta loop through every element, multiply the element, add it to the collection, right? So there's a very low level detail, right? Anybody who has done this ever, all the time, right? That's what we do. But the question is how do you feel? If that's what you do for eight hours a day, how do you feel dirty? Don't you feel dirty? You go home, the kids come running towards you. You say, don't touch me. I gotta go shower first, right? It's even worse than that for those of us who work from home. You gotta be very careful. You're busy coding, the kid runs in, you got 10 seconds to close the monitor. Otherwise the kid looks at them and says, that's what you do for a living, right? No wonder they don't wanna take after our profession after that, right? Absolutely, that's very low level, primitive obsession. But we can do a lot better than that. So what can we do instead? Well, how about simply saying, given the numbers, I wanna go ahead and perform a very high level operation. And what is that operation? A map operation. So a mapping of, given an element, I wanna double the element. So notice how expressive we are rather than messing with every single element, we focus on the whole. Given a list of numbers, map each of the elements by multiplying the value of by two, and then we can collect it back into a list if we wanted to, that is. And then this becomes the list we wanted to collect into, and we can of course print the result here if we wanted to, absolutely. So notice both of those code accomplish the same thing. Let's go ahead and run this code for a second. This comes from Java, of course, I'm using the new Java 8 here. So I'm gonna say in this case, a collectors, so we'll say collectors, which is part of the stream. And I'm gonna use a little function called the to list function to do the mapping into and collecting the result into the resulting collection. So in this case, notice what we just did. We said, given the stream of data, I wanna perform a mapping operation. What's a mapping operation do? It applies this operation on every single element. The number of output is exactly the same as the number of input, but the transformation has happened, the function has been applied on each of the values. So once again, rather than primitive obsession and low level of detail, what's the difference? The difference is two things. In imperative style, you say what to do and how to do it. In declarative style, functional style, you say what to do and let the library do it for you. Now in the imperative style, you constantly mutate your variables. If you look at this, we first created double, then on line 11, constantly modified the variable. If I turn up the volume of the computer, you'll hear the variable double say ouch ouch ouch here because you're constantly mutating it. But in the case of the bottom code, no variable was tortured in the making of the result. If the code is humane, you're not being brutal to this variable, right? So it's a very humane code and you are very expressive. If you notice this, think of this for a minute. You all have used a for loop. What do you do with the for? You iterate. Within a for what do you do? You put a if statement. Then what do you do? Put a break, put a continue. Now everything becomes a for loop. This is like you hear the door bell ring. You open the door, there's a guy. He says, I'm here to fix your kitchen. You say, well, thanks for coming and look at him. He's got a hammer in his hand. And you say, well, thanks for coming, but what's that? It's the hammer. I don't need any more stinking tools. This is enough for me, right? You're gonna be very, very nervous because this guy says he can solve all your problem with the hammer. Well, the for loop is that hammer. We're used for way too long. But what does professional do? Walks him with a little bag, put it on the floor, takes a little device in a little tools. You say, are you gonna use all of it? Of course not. I'm gonna figure out what I need. I'm gonna use it. There's a little chisel, a little screwdriver, a little hammer and various other devices, right? So in this case, the map is a little device and so are things like filter and other methods that are available as well. So how does it feel to write code like this? The imperative style is like talking to a toddler. You are your little baby, right? Sweetie, walk very carefully. Don't run away. Look where you're going. Hold it with both hands, please. Don't drop it on the floor. No, no, not the time to look over. You're talking to a toddler, right? You've got babies at every step of the way as you write this code. On the other hand, when you write code with a declarative style, functional style, how does it feel? It feels like talking to an adult. Well, actually, I'll rephrase it knowing some adults I know. I'm going to say it feels like talking to a responsible adult, right? So you are simply saying, I want this result and that's delivered to you. That's the benefit here. So in other words, what you're doing is you're seeding control. You're not taking care of every single step of what you need to do. You are simply focusing on some very high level and giving the rest of the details to the libraries to take it out. So it's a very small change in syntax but a very big change in semantics of what we do. And rather than asking the objects to do things, you just simply tell it what to do and we actually become better at making use of polymorphism in this case. So imperative style is opaque. It is waiting to hurt us. It doesn't reveal the intent. Declarative style, on the other hand, is very transparent. It tells us what we are doing and gives us the clue what's going on. So another one, when you look at a piece of code, when you look at the declarative code, it begins to read like the problem statement. On the other hand, when you look at an imperative code, it becomes like a puzzle. You're trying to decipher what the code is doing. To me, a good code should read like a story, not like a puzzle. And mostly when you look at functional style code, it stacks up to read more like the problem statement. We'll take a look at one example here real quick. But what about efficiency of such a code? Well, one of the beauties of functional programming is lazy evaluation. And lazy evaluation simply means that an evaluation doesn't happen until the result actually is needed. Let's take a look at an example here. If you look at this code, you would notice pretty shockingly that when I create the result here and print it, you can see it produced that result. But rather than doing this, let's go back to this code and we'll call it as sample double it for a second. Where I'm gonna create a method here, which is going to be returning a double, we'll call it double it, I'll call it a number. And within here, I'm gonna return number times two. So all I did was I just moved things around a little bit. Now let's get back to this code for a second. And I'm not gonna print this result, but I'm gonna simply print out done over here. So you can see that it printed done. But right here on the double it method, I'm gonna say output. And in this case, I'm gonna output double it called four. And I'm gonna say the number that we are interested in. Well, it should be obvious what's gonna happen here, right? Double it, every number is being doubled. So double it should be called four, one, two, three, up to six. And then the result should be collected back. So when I run this, you can see double it was called for all those methods, all those functions. But here comes a little secret. What if I don't wanna double all the values? I wanna only double even numbers. Well, I can simply say over here, a filter given a number E, only do this if it's an even number. Now notice the double it in this particular case is going to be called only for the even numbers. You can see it's for fewer things. But here comes a secret sauce. Notice in this example, we filtered and then we doubled it and then we put into a list. However, these functions are extremely efficient. If you remove this last part, I remove the collect, what happens? This is something we can relate very nicely at work, right? I'm sure you have people like that at work. You go to work, people come to work in the morning, they look around, they say, hey, where's the boss? Well, the boss is not at work today. No need to do any work today, right? That's exactly how lazy these guys are. So if you notice, when I run the code, it says done. Even though we call filter and map, no work was really done because they are lazy. They postpone their work until the very last responsible moment. If that result was never needed, notice it never expended any effort. Of course, on the other hand, if I call the collect and I put the result into a collection of some sort, you can see that work. Or there are other terminal operations like this, like for example, find a first. In this example, notice, it's even better. It is so lazy, it did only work for one value, even though there were other values. It completely avoids the work it doesn't have to do. And that is laziness. To me, the real core of functional programming is in the lazy evaluation. Take away lazy evaluation. There's not as much fun in functional programming after that. So efficiency is very important, and functional programming makes it almost trivial to get that kind of efficiency and code. So did we do any real extra work at all? Absolutely not. We don't because it's very optimized. It knows exactly when to run and what to run. So lazy evaluation is extremely important. So efficiency is attained not by doing tasks faster or better, but it is by avoiding the work that shouldn't be done in the first place. So if you want real efficiency and real scalability, you don't get that by doing things faster, but you do that by eliminating work you shouldn't be doing otherwise. That is where the real power is, and that's already baked into functional programming, as you can see. So the word lazy here is actually really a word for efficiency, as you can see here. But functional programming is really about this laziness and functional composition, but what about speed? I'm going to give you an example here about speed and how we can attain speed, but also we can see how the problem begins to read, the code begins to read like the problem statement. Let's define a problem first. Find the highest stock price among some stocks. Well, we have some stocks where the price is no greater than $500, right? So I want to find the highest stock price among stock symbols. What are the symbols? I've got tickers dot symbols on my hand that I want to work with. So the tickers basically are just a group of symbols. I've got about 20 of them in the symbols. Now, we know how to write code in imperative style. What do we normally do? We go to the stock price, we get the stock price, then we compare, we mutate variables, we loop through. We know exactly how to do it. I won't go back and do the way we are used to. But let's see how expressive the code really becomes. Notice what I'm going to do at this point. I'm going to time the code. So I'm going to say time at dot code. And the code I want to time is going to be, let's call it as find highest, right? And to this, I'm going to pass in a tickers dot symbols over here. And I'm going to send in a little stream for it to work with. So given this code, let's go ahead and define the function find highest. So public static, let's say void find highest. And this is going to take a stream of string. And I'm going to say in this case, let's call it as symbols, right? Look at how trivial it is to write this code. I need a stream to begin with. So I'm going to say it's a stream which is really where to nicely compose these methods. Now look at what I'm going to do in this code. All I'm going to do is output. And this is going to simply say simple start over here. And I'm going to perform a map operation because I want the stock prices. So I'm going to say stock util. And I'm going to get the prices for the stocks. So I got a little function already in the background. Then I'm going to filter. And I'm going to say in this case, is price less than $500 because that's the problem that we are working with. I want the prices to be less than $500. And I'm going to reduce this. And I want to reduce this to a single value from a new stock info, which is going to be an empty and a 0.0 as an initial price. But I'm going to reduce this based on a stock utils. I got a pick high method, which will find the highest price of stock out of the values that we have. If you look at this code and look at how the code actually is going to do the work, you can see in this particular case, it is very simple to read the code. Look at the way the code reads. Given a list of ticker symbols, get me all the prices. Pick the ones that are less than $500 and reduce it to the highest price. So the code begins to read like the problem statement. It removes all the confusion around the code that we normally get into. So given this, you can see how the declarative code begins to fall in place. It becomes easier to see, easier to read. But if you run this code, it takes a while to run. Why? Because it's going to get the stock price, bring back the code, it takes a few minutes to run. But the performance is not good for us. How do you improve the performance? And well, it took about 20 seconds and it says Amazon at $3.22 and 70 cents. Okay, great. But how do you speed this up? Well, as you're thinking about speeding this up, one of your colleagues says, I got a great idea. We can speed this up by using multiple threads. How do you feel? Immediately your brain rushes to the last job you had. Remember the last job? You had a sequential code. Everybody was smiling at each other at work. Life was good. And then one day you decided to put threads in it. And that was the last day anybody smiled at each other, right? Because the code turned into a monster in front of you. Nothing worked. It was too buggy. You were late at night trying to fix bugs. And while you were fixing bugs, you applied for the other job. That's called concurrency, right? You're like, oh, no, I don't want to do it. Well, what if we can rely on purity of functions and notice what I'm going to do here? I'm going to turn into a parallel stream. The only change I made here was go from a stream to a parallel stream. The result is exactly the same as before. But the structure is exactly the way it was as before. Except we said I want to use a stream instead of a parallel stream, right? So the idea really is this. We can have the code speed up by applying threads, but often we fear why, because it becomes really hard to maintain the code. So let's think again about the word mainstream. Just because something is popular doesn't mean it's the right thing to do. And this is the battle we have to fight every single day because people around us want to do what is mainstream. So as Abraham Lincoln said, taverning genius stay in a beaten path. It seeks regions of hitherto unexplored, and we have to. But this has been around for a very long time. It's not something we discovered last night and want to try it. It's been around for a very long time. It's just not mainstream. So imperative code is very familiar, but declarative code is a lot simpler once we get used to the syntax. So benefits, the code is concise, very expressive. It becomes easy to stay focused on what we are trying to do. It reads like the problem statement, so we don't have to really discover a puzzle. It becomes very obvious. It's very transparent rather than being opaque, and it's easier to test the code because of the purity of functions as well, less debugging to do, and of course it's very easy to optimize this code as well. So as you discover functional programming and whatever language you choose, it doesn't have to be purely functional language, but it's something we can actually work towards making it a lot better. So the biggest change, of course, is not in the languages. As almost every single language now has lambda expression, I can't think of language that doesn't, but the biggest change is gonna be in the minds of programmers. We have to rewire ourselves. And honestly, that is exciting to me because it makes me feel like I'm young every single day because I can do what I do before, but I can do it better. It is something we can learn, we can get better, and to me that's what makes it really exciting to be in this field. I hope you found that useful. Thank you. Functional programming, baddit. Well, one of the challenges with functional programming is it is definitely a better way of expressing things, better way to code. However, if you look at very pure functional language like Haskell, Erlang is really not that pure, but if you bring it on, they are very opinionated. And when a language is so opinionated, something that is very trivial to do with mutability can become really hard in some special cases. So to me, this is where we gotta be careful not to become dogmatic, and this is where a hybrid language has its benefits. And the benefit really is that you can choose when it is a better solution and you can decide that for yourself, right? So as much as I love functional programming and the purity, there are maybe about 10% of cases where imperative style actually is a better way. And so when it is a better way, obviously the functional programming principles don't apply too much to it, especially mutability. To me, mutability is not a bad thing. Shared mutability is the bad thing, right? So if we can avoid shared mutability, then we are fine. But the problem comes in when mutability creeps in and suddenly it becomes everywhere. So that's a balance we have to strike. So control to mutability is actually better. This is where languages like Java also has done a really good job in that they do mutability under the hood to give you good efficiency. In a way, to me, go-to's architecture programming like assignment is to functional programming. So it doesn't mean assignments don't happen, but assignments happen in a controlled fashion. So in a controlled mutability, controlled imperativeness is fine as long as we can actually keep our code hygienic. So that's where there's a gray area where imperative actually is better and functional is not. And then we should have the freedom to choose at that point, I think. Any other questions? Don't be shy. I'm sure you have a thousand questions in your mind. Bring it out. Yes, please. Ah! So, my good friend Scott Davis who's actually across town speaking in another conference, he wanted to interview me one day and he really surprised me with this question. He turns on the camera. I had no clue what he was gonna ask. And he said, well, you've written books on different languages. You've written a book on Groovy. Now you wrote a book on Scala. Does Groovy know you're seeing other languages? And I was shocked at this question. And I immediately said, I'll be in trouble if languages were my girlfriends, but they're really friends. And I really mean that. So to me, a language is like a vehicle. And while I'm here today and I had to take flights to get here, but once I had to take a car to get here and I would really like to take a bicycle to go around. And to me, all of those are extremely important. And I love my bicycle. I do love my Jeep. And I do take airplanes. And different languages give different speed at times, but I also give different conveniences. For a very crowded streets in Bangalore, it's probably a bicycle better than anything else. And that's exactly how I view languages as. I view languages as vehicles. And for that very reason, I work very hard not to have a favorite. I actually program very comfortably in about 10 different languages. And to me, my strength is not in becoming a specialist in one, but to be a gentlest in several. And this happened to me in my consulting practice because when I go to work with clients, it doesn't matter what language they are using, I rarely try to preach and convert languages on them, but I show them how they can get better in the language they program. So as a result, I don't really have a favorite. But I do have things that I may do, depending on the job, I may pick one versus the other. I've written production systems in multiple languages and wouldn't really mind at all switching languages. I kind of want to have the flexibility to switch languages. I think that's really our power, I think. Well, there you go. Thank you. Thank you.