 on refactoring your language knowledge portfolio. I want to talk a little bit about questioning what we do and how we could go up and adapt a certain different paradigm of programming. And we've been programming in a certain way for a long time. And there's been a few different paradigms. So it's a good time to kind of re-question and rethink about what we do. So that's what I want to do here. Let's talk a little bit about where we are and what we do. We work in a very exciting field. And if I kind of reflect back to my own life and what I've done over the years, I started programming when I was in school. And of course, I wanted to be an engineer. I really got drawn into a computer science and computer science and engineering. I went on to do a BS in computer engineering. I went on to do an electrical engineering masters. But then I kind of came back into get a PhD in computer science. So a lot of my work in the initial phase was definitely drawn towards science and engineering. But a few decades later, I am still a programmer. And the reason I'm a programmer is really a little different now. So if I want to kind of reflect back on my time, the science in programming is what drew me in. But it's actually the art in programming that actually kept me in. And the more I program, the more I work with software systems, I realize that it's a form of expression. As much as, yes, it is engineering. It is science. And that's kind of what really excites me, the art form of it more than the engineering form of it, even though that part is still important. And as we work through this, I want to kind of reflect back on this quote. It says, I want to stay as close to the edge as I can without going over. Out on the edge, you see all kinds of things you cannot see from the center. And I can relate to this very well on two fronts. One of the things I do when I go home mostly is I go mountain hiking. I live near Boulder, Colorado. And I have little boys. My little boy started hiking when he was four years old. And he can hike for about nearly 11 hours. He's the most avid hiker that I know personally. And he can do a lot of hiking. And one of the beautiful things about going up the mountain after struggling up there is the view that you enjoy when you're on the edge. And the other edge I'm talking about, of course, is programming. And I want to push the edges and do stuff. And I want to always try something different than what I had done before or I'm used to. And out on the edge, you can see things that you cannot quite see when you are confined with the environment that we normally work in. But programming itself, as we know, is a very nascent field. We have been doing this for a good about, what, 40, 50, 60 years, depending on how you give or take. So it's a very nascent field compared to other things we have done as human beings. Medicine, building constructions and stuff like that. So very nascent field. So I want you to think about this for a minute. Imagine I want to buy a car. And I'm going to ask you, what kind of car do you recommend that I buy? And of course I want to be a bit cautious about environment. I don't want to burn up gas and pollute the environment more. So you probably would say, Venkat, why don't you consider an electric car? That's reasonable, right? So I go buy an electric car. But of course if I buy an electric car, I need to charge my electric car, isn't it? Yeah, absolutely. So I buy electric car because you told me to. You go tell other people to buy an electric car. Bunch of people buy electric cars. Then what do we need? We need a station to charge those electric cars, don't we? That's a great idea. So we would have something like this, isn't it? And we would start charging these electric cars. And then now you would need stations and stations where you would have to have electric cars, isn't it? Seems reasonable. So we would have to build these stations of electric car charging stations. So what if a lot of us buy these electric cars? So we would kind of have something like this, right? Makes sense. So the whole of the United States will be sprinkled with electric car changing station. Hey, somebody wrote that actually in a paper. When did they write it? In 1899. Now wait a second, wait a second, that's a misprint, Venkat. Did you mean 1999? Even that is early. No, 1899. What? We're just about getting excited about electric cars. Well, most cars on the streets wear electric cars back then. They didn't have gasoline powered cars back then. They had electric cars back then. And there was a few problems with the electric cars. It took effort to charge them. And they wouldn't go too fast. And they had other problems with it. The other cars that roam the streets were steam cars. Steam cars, what's the problem with that? It took forever to heat them up. Honey, do you want to go shopping? Oh, maybe in two hours? Right, we've got to heat up this particular car, right? So eventually they found gasoline cars, and of course the technology folds wagon and Ford, all those people came about and they said, let's go mass produce these cars. And slowly as time went by, we forgot about electric cars. Until now we are all excited about, and hey, look, we can build electric cars. Well, in our field, we are going through something very similar. So back in time, steam powered cars and electric cars were the norm and then we kind of forgot all about it and gasoline powered cars were really popular until now again we are interested in electric cars and I see this exactly happening in our field except we're not dealing with electric cars. This is an evolutionary phase. It turns out in our field what was really up there was functional programming and structured programming. This is way back in time. And then came along object-oriented programming. Does anybody remember the year when OOP was introduced? Don't worry about being wrong. I'm wrong most of the time myself. Just throw a number at me. Don't say 18, please. What is it? 87. 87, 87, 87. In the 40s, no. He's not that old. 1967. You're making him a grandfather. That's what I'm saying, right? All right. What year you're saying? 67. I'm not going to have a debate with you here. How about that? No, I haven't asked for it. She refuses. I don't want to have a debate. It's okay. Whatever year you say is good enough for me. Yeah. So it was a long time ago, right? 1967, according to what I know, she can have another year. That's fine. I'm not going to argue with her. So basically the idea really is it was in 1960s or whatever it is. And then came along what? 1987 is when we were like, whoa, this is awesome. But even then, right? The small talkers were really doing OOP. But what about the rest of us doing C programming, structured programming? What changed the world? C++. Because overnight, you didn't have to do anything, but you were OOP programmers. This is awesome. How great is that? You go home as a structured programmer one day. You came back the next morning as OOP programmer. What did you do differently? I used to work for a very fine guy. He said, Venkat, we're going to interview you, but we want to make sure you understand what you're getting into before you get into this job. He said, what is it? Well, my team will tell you you're going to be programming an obturant system. Well, once you join the company, you will notice that we are programming with C++. Well, after a few months, you will come back to me and tell me that all that you can see is a code filed by the C++ compiler. There's a big difference between these, right? But that's one of the beauties of adoption. You didn't have to do a whole lot, but you could paradigm shift. How is that? Because that's the beauty of C++, right? So the idea really is that we got really got into it. I remember back in time, as I was developing software, there would be arguments on the mailing list. This was funny to watch. OOP will not work. It'll suck. It'll be poor in performance. People endlessly arguing on the mailing list, right? And then we would talk about whether you have a diamond structure, deep hierarchy versus wide hierarchy. This was fun times back then. And then suddenly everything quieted out. Nobody talked about those things anymore. And they were quietly doing OOP. And all of a sudden, people went overboard with this. And now we've got a big people. Could you stop doing objects? The other day I was pairing with somebody and that person said, oh, we've got to create a class. I said, why create a class? And then looked at it like, what do you mean why create a class? How would you do without a class? And we got into a point where we assumed that everything should be in a class, right? So it's a pendulum. And we've gone all the way to this side. And I think it's a balance we have to strike. And now, of course, we are getting excited about functional programming one more time. And as if this is like great idea, but it's been around for what, a good 50 years or more, depending on how you count it. So let's focus on Java just for a little bit. Java, of course, I'm really speaking about Java 7 and before, not referring to Java 8 here. And Java, of course, has been around for a long time. And we could look at this as this, you know, as this hierarchical thing. And right at the bottom is the JVM. On top of this is the JDK. And of course, the Java language, it's sitting on the top. And of course, we have told that Java is simple, but really, it's simple. It's more simpler than C++, right? But it's evolved over time. And as things evolved over time, the JVM became more ubiquitous, more powerful. And of course, the JDK is one of the widely used libraries, but of course, Java really kind of became the weakest link along the way. But when it comes to the emergence of technology, if you really look at it, I'm going to use the word, more of a strong word. There was a exodus back in about 2000, 2003 time frame, when a bunch of guys got together and said, you know what? We're tired of this. Java has become heavyweight. It is really hard to program in this. It takes a lot of time and effort. We're not going to put up with this. And they, what did they do? They turned in their passports. They sold their homes, gave away their pets, and emigrated to this barren land called Ruby on Rails. There was not a whole lot there. And they said, that's fine. We would much rather be in a land where we can build stuff on our own and work with all this heavyweight things. And they turned in their passports and emigrated, and they found this new found land and started building things. And they were brave. And I'm not talking about just anybody, right? I'm talking about guys like Bruce State, who wrote the Bitter Java book, Bitter EJB book, and said, that's enough. In fact, if you want to really look back in time, Bruce State is a great guy to look at. He wrote Bitter Java, Bitter EJB, better, faster, lighter Java. You look at his, you know, book titles that kind of tells you his life as a professional. And then he wrote Ruby for Java programmers, right? That's where it's in a rear-view mirror. And he's kind of emigrated to that, and he's gone. But the beauty is this, right? I would call this a period of renaissance, where we started having new languages on the JVM. And all of a sudden, this was different. You didn't have to sell your home. You didn't have to go give away your pets. You didn't have to emigrate to this foreign land. You could sit exactly where you were, comfortably in your chair, and you could reach out. And you could reach out to functional programming. You can reach out to structured programming. Reach out to objective programming. You could do concurrency the way you want it to be done. And all of a sudden, this platform really started supporting multiple paradigms. Java didn't at the time, but other languages kind of started coming in for making this happen. And this was powered to the programmers that wanted to make use of this, right? That's the beauty of this. So there were these languages, like, for example, Groovy, Scala, JRuby, Clojure. I absolutely cannot fit all the languages here. So if there's a language that you really care about and it's not here, well, you can put that in there absolutely. So the way I look at this world is now this way. There is the platform, there is the library, but on top of it, you have these languages' landscape. You got Java, Groovy, Scala, JRuby, Clojure, and you can reach out to them. And this, to me, is democracy in the programming world, right? You're not forced to say, you will use this one language. You pick and choose what you like. And you're not forced to use one. You could mix them based on what you're trying to do. That becomes the power for us. But what was old is suddenly new again. And functional programming has resurrected. In fact, Java 8 is going to be more functional than ever. But we keep talking about function languages. I always wonder, if there are functional languages, does it mean there are non-functional or dysfunctional languages? You kind of wonder, right? So yeah, there are some. But what it really comes to is this. When I introduce programmers to languages, one of the things they immediately talk about is, I don't like that syntax or I like that syntax. And I think both of those are really a wrong way to look at it. And the reason is, a syntax only plays a very small part. You know, I struggle, but I can comfortably program in maybe about eight languages and maybe a little bit more. Everybody could be looking at the same code. We all react to it differently. One person may look at this code and be scared. Another person may look at the elegance at the same time. How could two people look at the same language? One guy's screaming, other guy's like, wow, this is cool. Hey, guess why? That's an art form as well. That's why art is not a standard, right? Different people look at it, react differently as well. And that is there as well. But like I said, it is idioms that make a big difference. Idioms play a very important role. So when you hear things like, it rains cats and dogs. When has it ever rained cats and dogs, right? And you look at this and say, what does that mean? And you kind of wonder, where did these stories come from? Where did these idioms come from? Programming languages sort of like that, right? We use idioms to program. And then that is extremely important to develop things. So when we work with systems, culture is extremely important for us to understand. When you're programming in Scala, by the way, you've got to know how Scala programmers would program. When you program in Groovy, you've got to know how Groovy programs, where you get embarrassed, we get stuck into this world. So it's important for us to know these things as we develop it. But the way I see this is, is it functional programming? And I see this kind of, you know, two divisions of people forming, and that is a bit problematic. Those people who say, OP is great, it's worked so well for so long, why do we want to change it? And then this other camp that says, functional programming rocks, we should never do objects, it is wonderful, that's what we should use. And I believe neither one of them is right. I believe in more of a hybrid model now. And the hybrid model basically is to really bring those two together and utilize them a little bit. Now, of course, this requires a bit of a rethinking on our part. My good friend Stuart Halloway has a blog, I highly recommend you Google for this and read this. It's a very interesting read. He talks about the so-called essence versus ceremony. And this is something we cannot take lightly. As programmers, what do we do? Most of us soldier our way to write code. We are sitting there and writing code in Java or C-sharp, and somebody says, is that a lot of work? You take a deep breath and say, that's life in the big city, what can I do? So we kind of take it upon ourselves a lot of times to do stuff. But what do we do? We entertain ceremony. And then ceremony basically says, you got to do stuff you don't care to do, but you have to do it before you can get to do what you really want to do. And in languages, I'm not really, you know, worried about Java syntax. When I say we got to look at other languages, I'm not worried about Java syntax, I'm fine with Java syntax. Java syntax doesn't hurt me. It is a ceremony that languages like Java can impose, which Java 8 is really trying hard to at least fix partially, if not fully, right? And that is what really damses. And Stuart Holloway talks about how a high ceremony code damses twice. It takes more effort to create this code, but it also takes more effort to maintain such a code. It becomes really hard and it becomes a burden. And those programmers who realize this burden really try to flee from this and saying, I want something else. And those who don't realize this burden become the frog in a boiling pot. You know the story of the frog in the boiling pot, right? There's a water, they put frog in it, it's happy. They turn up the heat and the frog doesn't even know because the heat is slowly increasing until one point it gets boiled. And we do that sometimes because we've been doing that only that we don't even know that the ceremony has just come around us, it's grown around us, right? And we don't have the sense to realize that this has heated up too much. That is very dangerous. How do we solve the problem? Go out, program with somebody who doesn't work in your company, right? Have a group meeting. User groups are extremely important. Form a code retreat and have them challenge you. Look at some other piece of code than you have been working with and see how it bends your mind. And that can show us different ways. You don't have to accept it. I think it was Aristotle who said it's a sign of an educated mind to entertain a thought, an idea, without accepting it. What a great thought. You don't have to accept somebody's idea when you listen to them, right? We're not saying you agree, sign here in blood. Entertain the thought. Just receive it in and say, what does that mean? How would it feel? It's a sign of an educated mind to entertain a thought, an idea without having to accept it. Then you can come back and say, does this make sense? Do I want to make the change? Do I want to adapt it? Now, think about some of these things. This is the dolly, the little sheep that was cloned. Well, cloning. Let's talk about cloning for a minute, right? We all know what cloning is. How would you do cloning in Java for a minute? So I want to clone. What did Java do? Java said, hey, you know what? C++ is horrible. We're going to make Java simpler. Well, what is the problem with C++? Once again, problem with C++ was not the syntax. Problem with C++ was things that you have to know. And if you don't know what will C++ do, you forgot to write a copy constructor. Will the compiler give you an error? Any C++ programmers here? A few of us, right? Would C++ give you an error if you forget a copy constructor? No. What will it do? Potentially make a shallow copy. What will it do if you take a particular data or object and cast it to a wrong type? What will it do? Will it give you a compilation error? No. What does it do? Right? That's the international symbol for, I don't know. Right? This is the beauty, right? If you are a C++ programmer or look at C++ programmers, they get up in the morning and they are eager to go to work. You ask them, why are you so eager to go to work? Because they say, I want to know what the code does today. Because I don't have a clue, right? It is totally unpredictable. I don't know what it's going to do, right? That's what box you down in this language. Unpredictability. You're like, damn, how did that code do that? And you got to go back and fix it. So Java said, no more copy constructors for you. Yay, that's great. But I want to make a copy of an object. How do I do that? Well, you got to implement a clone method. All right, we'll do that. So public, and I'm going to say object, obviously, clone. And I want to clone this. But in this case, I could say return. And I could return maybe return member-wise clone, right? So member-wise clone. Or whatever you want to return, right? You could do that, member-wise clone. What's going to happen when you try to compile this code? You will get a compilation error, right? What does it say? Actually, in this case, I'll just say return null for a minute. Who cares what I return at this moment? I'm going to return that. What does it say? It is going to tell you, well, obviously you can't do this. You got to implement cloneable. So there's a structure to this. Yay, that's great. So I'm going to implement cloneable. Implements cloneable, right? All right, great. We can do that. And what does it tell you now when you try to implement cloneable? It is going to say, excuse me, but you need to handle the exception. What exception do I have to handle? Clone not supported exception. You say, but I am supporting clone. And Java says, but you have to handle the exception called clone not supported exception. The minute I put member-wise clone there, it will say, you got to handle clone not supported exception. But I am doing it. And you find yourselves one afternoon arguing with the Java compiler. Now you know you have hit the lowest point of programming, right? You should never argue with the compiler, right? Then at some point you realize no longer is the compiler working for you, now you're working for the compiler. And you're saying, okay, fine, fine, fine. Let me know what you want. I'll get this done. But Java programmers are clever. They said, fine. If you want that, I will invent an IDE to solve that problem. Then comes Eclipse rolling in. Now you don't have to do any of these, right? You write the code, it does all the stupid things for you. So this is where you can see how the ceremony comes to damage, right? And you finish all of this and you say, what did I spend the last 15 minutes doing? Oh, I was working for the compiler. Now I can do my own work, right? There is absolutely no reason to do this, right? But yet we face this problem quite often in what we try to do. I want to do file operation. How do you do that? Again, this is when, again, the exception handling comes to us. The API comes to us and it can really slow us down. But I want to think about, I want you to think about something else. This is something I did not realize for a long time. There are statements and there are expressions. You see, I've been programming in C++, Java, C sharp. I didn't even know that this distinction really exists in that regard. Then I started programming in language like Ruby. And language like Ruby doesn't have statements. And what does it mean? I want you to just think about this. Close your eyes for a minute and think about it and tell yourself the word statement. How do you feel? Grim, right? You feel like you're standing in front of a dictator, right? It's a statement given to you. Now who say the word expression? Feels relaxing. She's smiling now. See that? That is a beauty of expression. Expressions make you feel good. Now, I was talking about mutability, right? Mutability is evil. Especially shared mutability is evil. We want to avoid mutability. Now think about this for a minute. I want to write a if statement. What do you do with the if statement? I say, hey, I want to come into this block of code. And within this block of code, I want to say in here, do some work for me. So what am I going to do? If something, right? And then do something. Something happens here. But this is an if statement. So what does a statement do? Statement says, I will do stuff. Thank you, statement. What did you do? I won't tell you. But I need to know what you did. Well, I did something. And I put it over there. You can go get it yourself. So what does it mean? Statements automatically inject mutability in code. Think about that for a minute. Statements are not pure. They have side effects. The minute you call a statement, you said, I have to go set a value somewhere so you can come and get it. So by definition, the by behavior, statements introduce mutability. This is something I didn't realize for a while. And the minute I learned this, I'm like, whoa, look at what I've been doing so far when I program in languages which have statements, automatically I have introduced mutability in code and I know mutability is a bad thing. Why is mutability a bad thing? Mutability is a bad thing means there are moving parts. Michael Feathers. Michael Feathers tweeted one day. He said, oh, programming is about encapsulating moving parts. Functional programming is about eliminating moving parts. What a great way to think, right? You're not encapsulating moving parts anymore. You're eliminating moving parts. Why? Moving parts cause trouble. Moving parts cause bugs. How many times have you looked at a piece of code, you're scratching your head and you're like, this should work but it doesn't. The other day somebody showed me a code. He said, this is my code. I can't maintain this anymore. Please, why doesn't this work? And I'm reading this code. It's only 10 lines of code. I'm reading it, reading it, reading it. And eventually, oh my goodness, you took the input variable and you modified it. And your brain doesn't accept it at this point. You're in denial this happened. And in fact, this guy wrote the code and his brain doesn't even process that. So mutability is bad, but statements promote mutability. Actually, statements impose mutability. What are expressions? An expression says, I will do stuff and I'll give you the result back. And as a result, you can use that result, right? So if you're programming in a language like Scala or Groovy or Ruby, you could do this. You could say, for example, let's say age equals, let's say 20. I could say if age is greater than 17, I could say can vote. Otherwise what else? I could say go home kid, right? So this is, and I could simply say over here, for example, vote or not equals, I could then put the if statement through it, right? And then when I'm done with it, I could say vote or not and I can ask him vote or not, right? So basically the idea really behind this is you are able to write an expression in the code essentially in this particular case. So this is basically saying I'm going to have an age property and this is going to give us an expression of some kind and whatever this is going to return, I could put this into a function and this is going to return and that's going to return a value. And if I were to, you know, roll this into a function, for example, define this as a function and I'm going to put this into this code, notice I'm not mutating variables at this point and I could say, you know, age, let's say 20, I'll pass that as a value in this case and this is going to be the age value that's coming in. So we are asking him what's the value in this case? Notice I didn't mutate the variable, right? So why? Because if is an expression. The minute you realize it, you say, whoa, languages that only have expressions are superior because they hurt you less. Whereas languages that, you know, separate expressions from functions really begin to damn us. So when I look at a language, I don't want to look at the syntax. That's the least interesting to me. Hey, does the language have statements in it? Yes, I want to step away a little bit from it, right? Because it's going to force mutability on me. That's the view I want to have about how these things look like. Am I making sense? Right? So that is something to think about in terms of how the languages are going to influence us, what we do. But I'll complain about languages, by the way. But you know what? It's human nature to complain, would you agree? But if you complain about it in mother-in-law, you get in trouble with the wife. I figured it's safe to complain about languages, right? Only a few people really get upset at the time. And that's okay. These are professionals that can stay upset. And I complain about languages endlessly. You tell me a language. I was giving a talk in Java 1. My talk was on Scala, by the way. I was giving my talk, and I said, hey, but let me tell you something funny about Scala. And I was going to call out on something really silly in Scala. There were 300 people in the room. And my eyes locked on somebody right in the middle of the room. And I said, oh, wait a minute. Oops, I don't think I want to say it anymore. Because it was the man in the room, right? It was Martin Odorski, the guy who wrote Scala. And of course, knowing Martin, he's the most genuine guy I ever know. He says, bring it on. I would much rather hear it from you so I can go do something about it. I complain about every language. People think. And people think that I only favor one language. I wrote Book on Groovy. And then people came to me and said, oh, you like Groovy. And I wrote a book on Scala. They said, no, you don't like Groovy anymore. You like Scala. How did you know that? My good friend Scott Davis probably is the one who really has the trick. He turned on the camera and he said, Venkat, I want to interview you. I said, sure, what do you want to talk about? He said, I don't know what I want to talk about. Hey, I've got a question for you. I said, yeah, and I was totally unprepared. He said, you wrote a book on Groovy. Do you really know that you're seeing other languages? I was shocked. I said, I mean, how do we respond to it? I said, you know what? I'll be in trouble if these were girlfriends. But fortunately, they are really good friends. And I really, really believe it. I do believe we can mix and match these languages. They're not exclusive. And so why should I say I want this language and not that language, right? So after all the complaints, I would say one thing I like about these languages is I have a lot of respect for these languages. Why? Because I fundamentally believe that every language leaves a mark. Every language leaves a mark. If you ask me, do I have respect for C++, I have the utmost respect for C++. So much that I don't code it anymore. I put it on the pedestal. No, I'm just kidding here. I do like it. I code in C++ if I have to. Nothing wrong with that, right? But C++ has made a big difference. What are those? Beyond Struister, the gentleman who created C++, he created C++. He was working on his dissertation and he was trying to program his highly concurrent application and he found out that it was very hard for him to do this. And so he tried to program in Simula. And it was really slow. It was so slow, he was scared that he would never be able to graduate because the program would not complete on time. Then he wrote it in a C-like language. Boy, it ran fast. But it was all buggy and all that. Once he graduated, went to AT&T labs and they said, why don't you sit back here and think about what you want to do. And he said, wouldn't it be so cool if I can have a language that was fast and furious and provided a paradigm. You see, once you go back to the history of why things happened, then you are learning the culture of it. Now you no longer have the apathy to it. You are like, oh, I see why you had done this. When C++ was coming out, performance was a big concern. They didn't need a whole language. Small talk was there for that. Other languages were there for that. But all the languages had one thing in common. They were slow. If you study the V-table of C++, what a marvelous idea. Your polymorphic calls were just two steps away in memory calls. What a great performance. And so C++ said, performance first, accuracy later. That was a design decision. And so if you don't mark a function virtual, it was not virtual. Why? Not because beyond Stubb didn't know what he was doing. It is because that performance overhead was now acceptable. Why? If you have ever programmed a 1980 processors, you would know that, right? It was slow. Not that machines are very fast now. That's called Thomas law. And that says that no matter how fast the machines become, your operating system and other applications suck it down. But machines were really slow back then. And that was really hard. And so C++ was created. So a way to think about C++ is amazingly fast, but incredibly dangerous. But that was by design, the language design decision. Beyond Stubb says that this was a language that will give you a loaded gun to shoot yourself in the foot. And many people have done that. I have scars in my body because of that. Where I've done C++ programming and I've shot myself over. But then came along Java. Okay, so what was the contribution of C++? I said languages leave a mark. What is the mark? C++ made OOP mainstream. Hands down, right? OOP has been around for a long time. Most corporate programmers won't touch it. What did it do? It said, you don't have to learn a thing. Hey, I know C. No problems, see you tomorrow. Right? You can code this. So can I start coding in C with C++? Absolutely. Then what do I do? Gradually make the transition. And you can go towards OOP. I'm not talking about perfection here. I'm talking about what the reality was. And you could take what you do and what you know and you could do this incrementally. And that's what really helped. Programmers become mainstream. Why? You didn't go to them and say, fundamentally change your way. You said do what you do and slowly start changing what you do. And people said, I can handle that. Don't tell me that I have to come tomorrow and speak French. But I can slowly start changing things, right? Absolutely. That's powerful, right? That is great for corporate programmers. Then came along Java. What did Java do? Java said, hey, OOP is mainstream now. No longer do we have to sell OOP to the world. Great. Machine performance is not big deal anymore. Great. Then what do we want to do? We want to ease development. We will simplify this, okay? Can you believe this? Can somebody remind me why we all got excited about Java? Scary, right? No. Applets. This is silly, but we were like, woo. You could put applets on the browser. This is 1994 browsers. Browsers were new at the time, right? And what is shocking to me is we got infatuated with Java for client side. And where's the power of Java today? On the server side. Wow. What a difference. So what was Java's contribution? Intention was something, sure. But to me, the main thing that Java did was it brought garbage collection to the mainstream. Once again, OOP has been around for a long time. C++ brought it to the mainstream. Garbage collection. Hey, which language had garbage collection? Lisp did decades ago. Java brought garbage collection to the mainstream. It said it's practical. We could do this. I remember sitting in corporate offices where they said Java would suck. It would never perform. Those people said OOP sucks will never perform for years earlier. And look at what Java did. The virtual machine has just become vibrant. So it made garbage collection, automatic garbage collection, the mainstream. So the point I'm getting to is I want to see languages differently. I don't go to a language and say I hate you or I love you. To me, languages, I view them as what are called bridge languages. So what is a bridge language in my opinion? A bridge language is a language that helps me cross the chasm. It is not a destination for me. It is a pathway towards something different, something better. Most of the coders today are using OOP, not because they are programming C++, but they are doing it because there was C++ as the bridge. Today you wouldn't really entertain a language which doesn't have automatic garbage collection. Even Objective C does today. Why? Because Java did that bridging for us and said you can have automatic garbage collection and fully decent performance most of the time. So I view these as bridge languages. Bridge languages make us cross this chasm, the paradigm. And now we turn around and say look where we are. But this doesn't mean we have arrived at the destination, but we have moved. We have changed and we are moving forward, right? And when you look at languages as bridge languages, you tend to accept languages much more willingly than saying I don't like it. I don't want to touch it. It's not a destination. You're not in bondage going into it, right? That I think is the power. So the new bridge languages on the JVM for me are JRuby, Groovy, Scala, Closure. These are, but not all these are doing the same thing. That's the fun part of this. So they all share one thing in common and that is they are all concise. They're all highly expressive and they're all functional style. That is one of the key things. So what does it mean? Well, the first thing is in a functional programming, you got immutability. You have pure functions. What is a pure function? A pure function is a function that has no side effects. It has no side effects. What does it mean? It has no side effects. It doesn't go, you know, mess with something around on the other side. You may say, why is it such a bad idea to mess with things? Well, you first know that the code you write is not the code that runs, right? The code you write is compiled into bytecode. But then that's only one compiler. Then comes the jit compiler, the just in time compiler. That compiles it further. An enormous amount of optimization happens in the code. But for the compiler, the jit compiler to optimize your code, what does it need? It says, I need to make sure this is correct. And if your program, if your code, if your expression, if your function is having side effects, the compiler says, whoa, this is pretty messy. I don't think I can rearrange and optimize this so easily. And it can do less optimization. On the other hand, if your function is pure, if your expressions are pure, it can relocate them based on what it feels fit. Now you say, all right, that's cool. But what benefit does it have for us? The functional programming paradigm really came from the, you know, lambda calculus. But this has really, really huge benefits if I could borrow this from you. So the idea is this. I've got expression one here on my hand. I've got expression two on my hand. Imagine these two expressions are independent of each other. They don't relate to each other in any ways. And what you have is you're taking the result of these two and doing some operation further down in the chain. If you are the compiler and you know that these two functions are pure, you say, hey, look, this is interesting. This is expression one. This is expression two. I'm going to decide to run expression one first. And then I'm going to run expression two. Is there a problem with that? Not at all. Or I say, hmm, there is actually a benefit in terms of whatever that I'm trying to optimize for. And I think I should run expression two first. And then that was after all not so pure. And then run expression two, right? Is there a problem? Not at all. The result is exactly the same. Or I'm the JIT compiler right just in time. I'm about to optimize this code. I look around and say, oh, wait a second. Look what I found. There are two cores in front of me. Why do I have to run them sequentially? I'm going to give this to core one. And I'm going to give this to core two. And run them concurrently. Did we lose anything? No, we gained performance. Look at the optimization the compiler can do. The JIT compiler can do when it knows that these are pure. What I just explained is called referential transparency. It can relocate things really well. And it gives us a real good performance. And we got all the benefits. But all that relies on one single thing. That the code is pure. So what does it mean pure? It's like a black box. You send something in and it gives you something out. And while it's running, it doesn't sneak around and change some data elsewhere. While it's running, it doesn't pull data that keeps changing. Right? What is the benefit? I explained one benefit. Referential transparency, multi-threading concurrency can help. But there is another benefit to this. It is easy to prove the correctness of this code. Mathematicians care about it. You say, I don't care. I live on the edge. What fun is it if the program just works? Well, it's easy to unit test that code because there are fewer moving parts in this code. Look at the benefit, right? That is functional style on one hand. The first is to evaluate the risk versus the reward. Be unemotional, by the way. Don't get emotional. Be unemotional. Don't take it personal. This is purely evaluating. Right? That's what you're doing. And you're saying, I'm going to evaluate this. I'm not committing to anything, but I'm going to assess the risk and the reward. If the reward's outweigh the risk, why shouldn't I go forward? It's only for a good, greater good. Now, change is hard. By the way, here's a small thing to think about. Think about early 1900s. This, by the way, is Salt Lake City right here. And that, by the way, is Cheyenne, Wyoming. The only problem is right in between is the Rocky Mountains. Very difficult to cross. And at this time, weather changes rapidly in this area of region. Rocky Mountains can get clouded up. In the summer, you could have snow, by the way. And as a result, they were having trains and trucks and all those good stuff that was going around this place. And wouldn't it be great to fly? Now, think about back in the early 90s. They did not have the technology they did today. They didn't even have maps. In fact, you know how the airplanes took off and went? They would take off the airplane and they would follow the railway track. I'm not kidding with you. Because they deviate from the railway track, they will get lost. And there were crashes and people died. And at this time, you would say, man, think about this. We live in a safety of an office. We are programming on the compiler. The worst thing that happens is we get a compilation error. These guys are out there with their lives. And a guy named Jepsen, the Denver airport is named after this guy. And Jepsen said, I'm going to fly these airplanes. He was 19 years old. He got his pilot license from the great, I'm just blanking out. Who was the one who did the Wilbur Brothers? He got the pilot license from them completely blanking out. Absolutely. And then he said, I'm going to fly this. You know what he did? He said, I'm going to fly it. And he started taking notes. And he created the first chart. His company eventually became United Airlines, the one I fly the most. And they adopted his charts as the first. In fact, the pilots would pay him $10 to buy his charts from him. And that became the standard eventually. He created this company. Don't do anything new. I'm at a disadvantage. A smart company makes one team do stuff. And it immediately calls a bunch of people and says, hey, you go try out this. You go try out that. You go try out that. Come back in a month and tell me what you found. We can learn a great deal from the bees. What do the bees do? The bees have what's called a forage. They go out looking for honey. Not all of them are going to find honey. Some of them will find honey. But some of them may find more honey. And they come back and they give up dance. I'm not going to dance in front of you here. But they dance. They dance. And the bees that found the most honey has the most brilliant dance. And the rest of them abandon what they did and they follow it. This is exactly how corporations have to run. You send out these people. Your workers are like the bees, right? Why? We are hard-working people. That's what we do. You're sitting there day and night struggling with the compilers. What else is it? But let them say, go on. Try out these. Go off. Go off. Go off. Try it. Come back and show us what you found. Then we will decide after the dance happens and we'll compare and move on. And what's the benefit? We can pick up new technologies that will change the world for us. So, as an individual, what can you do? So, here is an interesting thing to think about. The electorate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn and relearn. If you ask me, what do I do every day? This is what I do. I learn and I unlearn and I relearn. Or I struggle to do that. Let me put it that way. But this is extremely important. And if we don't do that, that's what makes us illiterate in the modern world. Not that you cannot read, but that you cannot or more important, you're unwilling to unlearn and then relearn. We can learn something from the Pavlo's dogs. He was doing the experiment. This man, by the way, is the one known for learning about the digestive system. And he learned it by studying dogs. He found something very interesting. He was observing dogs and he noticed that when the nurses or the assistants would come into the office, these nurses were feeding the dogs. And over time, the nurses or the assistants would just come in and the dogs would start salivating automatically. But they didn't have food with them. The sight of these people coming and they were salivating. By no means am I comparing us to dogs. We are more intelligent. But we have the salivation, by the way. We like stuff. We like to play with things. So build the environment where you will reward people for salivating about trying new ideas. Look at the corporate culture we can build when we do that, right? The environment changes our behavior. Where do you work? What kind of office do you have? What's your environment? Do you geek out with your colleagues? That makes a difference. One thing we should definitely avoid is that, right? Where do you say, I don't want to talk to anybody. I don't want to look at anybody. I don't want to listen to anybody. I will sit there and code away. This is a problem for us because we don't learn. I love going to conferences. I go to user groups. I hang out with people. Why? I end up learning from you guys. I was out in the corridor this early this morning and somebody said something. I said, wait a minute. I'm intrigued by what you're saying. I did not think about it that way. I want to go play with this a little bit more. There's osmosis, right? The worst thing that will happen to us when we interact with people is we become better. That is the beauty of what we do. So go ahead and collaborate, find people, and tell them, hey, what have you done recently? What are you playing with? Do you want to come over? Do you want to sit down? Maybe this evening we can pair up and program with something. We both suck at it, but we can get better at it by trying it together, right? And then invite people to do that and see what happens. There are risks and costs to a program of action, but they are far less than the long-range risk and cost of comfortable inaction. The worst thing we can do is not do anything. We are so worried, oh, what if I fail? And this really bothers me. Why are we not trying new things? Oh, I don't want to fail. Look at a toddler. The toddler falls down 100 times a day. When my children were toddlers, my wife and I agreed on something. When my children fall down, we'll pretend we didn't see. We'll kind of take a look and make sure they're not bleeding, right? We'll pretend that we didn't see them. The first day the child falls down, looks up. If you make an eye contact, the child immediately cries. Oh, baby, did you fall down? Immediately, it cries even more. Not because of anything. It sees a six-foot figure rushing towards. It's scared to heck, right? Leave children alone. See what they do. They don't cry. My children never cried when they fell down, unless they were terribly hurt. They get up and they kind of rub off and they walk away. And then we become adults. And the minute we slip, we say, oh, my God, I'm embarrassed. I couldn't fail. Why should failure be such an embarrassment? It only means we are learning. So go ahead and try things. If they work, you learn. If they didn't work, you learn more. In fact, I get worried when things work because the days things don't work. At the end of eight hours, I come out and say, boy, there were so many things I learned because it did not work. In fact, sometimes I pray that it doesn't work when I tried the first time because I can learn so many things along the way when I'm trying it, right? So that is the benefit we get. So let's not stay put. Let's not be afraid. Let's go rock the world. Thank you.