 All right. Good morning everyone. All right. Without taking too much of your time, I would like to welcome Mr. Venkat Subramaniam, my mentor, my friend. It's an honor to have him over here. All right. I'll leave the stage to Venkat. You have one answer. Excellent. Thank you. Thank you very much. It's definitely a great pleasure to be here with you to talk about certain things that I care about the most. And I'm certain that you care about the most as well. It would be nice to get the slides on the screen. Great. So I want to talk about something that has been in my mind for quite a while. One of the things that I love the most is developing software programming. That's my passion. I am a programmer. I love being a programmer. And I can't imagine a day when I don't code is like a day with no sunshine. That's how I feel about it. And I like to really code. And the reason I really like to code is it is a really a fantastic form of expression. It is a way that we can express our thoughts, our ideas. And then we can go back and refine it, change it and evolve it. So as a result, I would like to go pick up different ways to do that. And so along the way, I realized that there's a lot of fun doing it. But there's also a certain treacherous path we have to take. So the title of my talk today is it could be heaven or it could be hell. The pleasure and pedals of being a polyglot programmer. We'll talk about what that means along the way. But let's talk about why we should do. And the entire talk is going to focus on just one thing about you. Why should you care to do any of these? But before we do that, a quick show of your hands. How many of you are programmers here? That's great. I'm in the right place. How many of you are testers by any chance? A few of us, great. How many of you do other things in software development? Quite a few of us. How many of you will not raise your hand no matter what I ask? Okay, good. Excellent. That is one. Yeah, Neil, thank you. So absolutely, that's basically we are in the right place. We are among programmers who are passionate to learn. And of course, there are several programmers out there. But what makes you different is you care about your craft. You took the time away from your rigor and what you do so you can actually learn and get better. But the reason why this is important to us is, after all, it is so true that we really are what we eat. And we have to really keep out for what we eat. And of course, I'm talking about eating as food, but it is not just food that goes through our mouth, but the knowledge, the content, the things we hear constantly, we absorb, we see, this makes a huge difference. Why am I so worried about it? And that's because there are so many companies out there trying to sell us all kinds of things like this one. Kind of scary, isn't it? Because of course, if you know, Angus Burger is a type of meat from a special type of cow. And of course, the person who wrote this didn't know how to spell it. And so it could be pretty dangerous to eat a kind of food like this, right? So we have to be careful what we are looking at. But think about these for a little bit. What do you read? Now, we, most of you, you know, you ask people what do they do? They say I'm a programmer. Even worse, people would say I'm a Java programmer or I'm a C shop programmer. And what do you do? I write code. Well, yeah, we do write code, but what's more important is what do we read? And one of the best ways to write better code is to read better code, but it's not just the code. It's reading books, reading blogs, reading articles. And one of the things I have the benefit of, which is very important to me, is not only reading, but hanging out with people, right? Spending the evening with geeks. You know, people are in the field. We differ in opinion. We argue with each other. We have different bunch of opinionated people. And all these are the things we read. Again, reading not as reading a text, but read into ourselves. That makes a huge difference. So what do we read as something we want to think about? What language do you program in? How many of you program in Java here? Quite a few. How many of you program in C sharp? Excellent. Well, most of this talk, I'm going to be using Java, but you can relate to C sharp very easily. Other languages, Ruby, I know, Prakash is over here. All right, raise your hand. Anybody else Ruby program is okay? What about Groovy? There's a narration over there. Excellent. What other language? Python. There always is one Python. Absolutely, right? One Python user in the world. Thank you. Just kidding. What about Perl? That's okay. You're among friends. Be bold. Raise your hand. Okay. So there's different languages, absolutely, right? But more important than that, how many languages do you program in? Now, when I say how many languages you program in, you want to be able to program in at least, I would say, three or four different languages. And you say, why would I want to program in different languages? I go to work. I get my work done really well. Why am I really interested in programming in different languages? And the reason is there is a controversial theory called the Cypherwurf hypothesis. And this hypothesis is based on natural languages, obviously. It's not about programming languages. But this hypothesis says that the languages mold our thoughts. It was kind of a shock for me because until then, I really thought that whatever I think I express using the language as I speak, this is right, the opposite. What this says is that whatever I'm thinking is really influenced by the language I speak, the opposite of what we normally kind of, you know, it's kind of intuitive, right? And I didn't believe this for a while and I said, how could it be? I know what I'm thinking and I'm expressing what I'm thinking in the language that I'm speaking in and how could this become the other way around? And it says it turns out languages are deeply tied with cultures as well and cultures usually lead you to something else even more fantastic and wonderful, which is the idioms. Now, you could go learn any language. You could pick up English, you could pick up, you know, I could try to pick up Hindi, for example, or I could try to pick up French. You could read books, you could read articles, you could read the dictionary if you want to, but what really trips you off in those languages is not the language of the grammar per se, but it's the idioms because the idioms are very tricky because you could take an idiom, you could look up the words in the dictionary, put the meaning of the words together and say that makes no sense because idioms are formed by connotations, by history, by culture, and by some story in the past. And when you work with the people speaking in that particular language, they have an idiomatic style of using that language. That happens to be true for programming languages as well. When I was writing the Scala book, I had the wonderful opportunity of having Martin Odorski, the author of Scala, to read my book, and he would come back to me and say, Venkat, your code is right, but it's not idiomatic Scala and you would correct me in places, right? And that is one of the things is how is it idiomatic? The only way you can learn about idiomatic programming is by reading idiomatic code, working with programmers who can do idiomatic code, and that is important. But what's really clear in this is the way we think is influenced by the language of programming. When I used to program in C++, I was a phonetic programmer in C++, of course, but the best language ever, right? And as was programming in C++, and we could use multiple inheritance, of course it gave a lot of trouble, but when I came into Java, I was kind of amazed at this concept called interface-based inheritance. I was like, how would you do that? What does it mean by interface-based inheritance? That was kind of very perplexing to me. And once I understood what that was, I went back to C++ and said, I can do that still here as long as they make my classes pure abstract, it gives me an interface. And then I go into language like Ruby where there are no interfaces, period. And you're like, how could you program them with no interfaces? It bends your mind. But the beauty of this is that when I program in multiple languages, not because I can switch languages. I want to program in multiple languages because when I have to program in the language I program in, I can program better. I can program differently. And I can bet you my Java code or my C sharp code is no longer the same as it used to be years ago. I was on a project not too long ago. And I was pairing up with the programmer. And the programmer said, I want to implement this particular logic where we go clear out this database connection. I said, you know what, I've not done this before. This was a C sharp project. I said, I've not done this before. But if you would entertain this thought, let's write a test for this and then let's go write a code in a way that I think we could do this. And then I wrote a code using a certain pattern which doesn't exist quite easily in C sharp. And the minute it worked, we kind of were looking at this code and this programmer obviously was kind of surprised. He said, oh my goodness, I've never seen C sharp code like this. And I said, yes, I've never written one like this either. And as soon as I said that, one of the lead developers came over, looked at this and he gave me a pat on the back and said, are you trying to write Ruby code in C sharp? And I kind of winked at him and said, isn't that cool? And I was using anonymous delegates at the time to implement a certain pattern. And that is the beauty. It changes the way you program in the language you program because you took the time to learn another language. And that is extremely important for us professionals because what are we doing in our profession? We are trying to create wonderful software really fast. And if you find that your language is slowing you down, it doesn't mean you have to switch your language. You may have to switch the way you program in the language. So let's talk about why these are important. I said it influences our thought. It completely changes the way we think. And as a result, if you program in multiple languages, you end up thinking and perceiving things very differently. And your thought process is very different. You no longer think the way you did. You could think for the better. It doesn't mean all the time, but at least we think differently. That is a great first step in my opinion. And the design we create is heavily influenced by the language that we know, not the language you program in. The design is influenced by the language we know. You could be sitting there and programming in Java, programming in C-sharp, and your thought process goes through and says, I could try this idea. I know this works. I'm just getting exploring and working with Java 8 right now. And I'm going into Java 8 and I'm pulling in stuff I know from language like Groovy into Scala and I'm like, how can I do this in Java? And it's exciting to see that you can push the boundaries of the language a little bit beyond what it's designed for and then make it work to do certain interesting things. So learning a different language changes the way we code in our primary language. Now, this is extremely important. You cannot say, I know Java, so I'm going to learn C-sharp. No, that doesn't count. It's got to be a language which is different. It's got to be a language that hurts your head, makes you cry. And then you say, all right, I've learned something very different and I can deal with it. So learning a language that really makes us think differently, that is very important. And that's what influences the way we can design software and have the design influence from it as well. So that is very critical. So given this, if you know and only program in one language all the time, you are putting yourselves at an extreme disadvantage in your development. So if you are programming in a language that you only use that language, I recommend that you do not walk away from here. I recommend you run because it's important to go grasp various different ways to do these things and get better. We don't want to be at that disadvantage. Now, why should we really care about any of these? There are projects out there, there are companies out there, there are people out there and we're all focused on something and we're all focused on a certain way to do things. And then comes along something we never expected, something that we never even dreamt of. These are called black swans. There are bad black swans and good black swans. We'll ignore the bad ones. But good black swans. What are some of the black swans we have seen at least in our lifetime? Assuming that everybody here is at least 20 years or older. I would say Google. Remember the day that you saw Google, right? And you never want to go back and do anything else for searching. It changes the way you think. This is a black swan, right? These guys did something remarkable. They changed. They made every phone out there look like a high school project overnight. And it's amazing how things can change overnight. And what do other companies do when they recognize black swans? So, one thing I think we need to keep in mind is we don't think we can predict black swans. That's why they're black swans. But my concern is not about predicting black swans. My concern is what are you going to do about it when you find it? How quickly can you respond to it? How quickly can you change the way you do things? That is critical. And the guys that are the most threat to us in what we can do, and the guys that we want to aspire to be are the outliers. Because the outliers are not sitting there and doing the things that everybody else is doing. When you go out to ask people, they ask you, hey, you are programming in this language. Is that language mainstream? Mainstream means I don't want to take risk. Mainstream means I don't want to put my foot in there. I want to see this other guy jump and I want to see if he comes out alive. Then maybe I'll test the waters, right? And in our field, we cannot afford to just wait for mainstream. Is there a risk in trying new things? Absolutely. There is risk in getting out on the streets every day. We live that life all the time. But if we don't take the risk, who else is going to take the risk? And we have to be careful about it. So the people that we need to watch out for are the outliers because these are the people who can change the direction, the trend, where things are going. And of course, don't be blindsided by disruptive technologies. If you're waiting for a language or a platform or a paradigm to become mainstream, that is too late. Because other guys have benefited. What you're picking up is what they have left behind. And that is too late. There's a difference between a leader and a follower. A follower asks, has everybody done this? A leader doesn't ask that question, right? So we got to ask ourselves, who do we aspire to be? Do we want to be the leaders or do we want to be the last followers, right? That's the question to ask. So why isn't just one language enough? Because our code is no longer general purpose anymore. We do collections of data. We program big data now these days, right? And then we have to do system-level operations. What is general purpose anymore? There's so many things we have to do. We have to work with files, of course. And of course, we have to use XML. I mean, can you imagine doing anything without XML today? Right? I have this theory about XML. XML is really cute when it's small, but it becomes very annoying when it becomes bigger, right? And that is basically what XML is all about, right? But we have to deal with that content with it all the time. And of course, we have to deal with data access differently. And of course, I'm a big fan of metaprogramming. We want to be able to write program that can take things and change and evolve, and that becomes very critical as well. And then, of course, we have to deal with concurrency. Concurrency is a real huge burden. Most programmers have not been exposed to concurrency. Why? Because we didn't have the power of using it for a long time. But things changed. Today, it's incredibly difficult with the platforms on which we don't have multi-cores. This is not a war that you ask for, but you've been drawn into. And you have these multi-core processes on your hand, and you have to be able to utilize these processors. And if you don't use these processors, it goes waste. And your organization, your customers, your clients, everybody's going to come and say, I want this application to be more responsive. So whether you like it or not, you want to make your code concurrent. Now, how do we program concurrency now? Think about what we do in Java and C++ and C sharp. All these mainstream languages have something very much in common. What do we do? We create objects. And what are objects? Objects are not what Alan Kay thought this was. We kind of went on in our direction. And objects have state, and they have behavior. And we call these behavior, they're encapsulated, and we constantly mutate it. Now, what is wrong with that? That's such a bad idea. We look at things around and say, look, we are mutable, we change, and we can justify that. But what about sharing? Sharing is a good thing, right? Remember what mom told you, share kid, right? So sharing is good. So sharing is good, mutability is all right. But what about shared mutability? Shared mutability is devil's work. And the minute you bring in shared mutability, it becomes enormously complex to build applications. The minute you have a shared mutable variable, you're saying, oh my gosh, what happens if multiple threads come in? And you say, what's the first thing you learn in multi-thread programming? How do you start a thread? What's the second thing you do? How to control it? How to tame it? We can handle that kind of parallelism, right? And we control it, and we say, hey, you threads wait until this thread can get through. So shared mutability is evil. And you are writing a program, the other day I wrote a code in Java. And I had a synchronized code. And I was driving home, I know now not to do this, thinking about code while driving. And I asked myself, is this code thread safe, by the way? And a panic goes through my head. As soon as I went home, I run to my computer, log in, I look at my code. Yes, there is synchronized, but totally broken. And I'm looking at this, I'm confused. And then eventually I find the problem, I fix it. Now I am thinking, where else it's broken, and I don't know about it. Think about this for a minute. You did not put synchronize. Or you put synchronize in the wrong place. This is the lock in C sharp, right? And same way in Java. You forgot to put it, or you put it in the wrong place. The compiler gives you a error, correct? Yes or no? No, it doesn't. Okay, it gives you a warning. True or false? No, what does it do? Actually, it doesn't do nothing. It's worse than that. It sits there and watches you. And it says, here's a victim. I'm going to see what he does today. And you run the code what happens. It first behaves, and it misbehaves. And it misbehaves in unpredictable ways. The code runs once and it fails once. You say it failed. How did it fail? You run it again, it doesn't fail anymore. Frustrating, isn't it? So this is what I realized the other day. Programming concurrency with Java is like working with a mother-in-law. She's just waiting for you to fail. And this is not the way I want to program enterprise applications, right? This becomes painful. We can sit there and say, you know, I wrote this code. That's evil. I want more predictability. So let's revisit problems we have to look at. But then you always hear the corporate programmers say, but the language I use can do all of that. You always hear that. You explain all this. The programmer says, but why? The language I do can do all of that. I can do synchronize and suffer. It still works. This is one thing I love about programmers. They all share unrelenting hope. Every one of them is hopeful. Programmers are really an optimistic breed. It's just like they took the gene pool and took all the optimist people and made them programmers. I mean, think about it. We are the most optimistic people in the world, in the universe. If not, the first compiler error would have closed our field. And we get up back on our feet and say, I'm going to fix it. And we work hours and hours and hours fighting that compiler. Like nobody who is not a programmer will ever understand it. And they would look at you and say, why are you fighting that machine so bad? I'd like to do that. And it's so much pleasure when you finally see the program working, isn't it? That's what we are. But let's give credit where it's due. Where did Java come from? And similarly C sharp, of course, darknet really took on based on that. Every Java book you read, what did it say? Java is simple. Liars. What it really is, it's simpler than C++. They didn't want to tell you that. What did C++ have? It had pointers. They were scared of pointers. When Java came out, they said, Java has no pointers. I was panicking. How could you have a language with no pointers in it? So I started reading Java and I found out they don't call it pointers. They call it reference. Clever guys, right? They said, don't call it a pointer because they are scared. Call it something else. This is pure marketing, right? It crashes like a pointer. In fact, true, right? You take a reference, set it to null, and what exception do you get? Now, pointer exception. Rascals, they called it references, right? So they all kind of fooled us. And you're like, is it a pointer? No, honey, this is a reference. I can handle that, right? So what they removed was not pointers. They removed pointer arithmetic. How did Java become simple? They looked at C++ and said, oh, that hurts. We're going to fix it. How? Remove it. No templates for you. No overloading for you. So it was not Java simple than C++. Java was C++ minus minus. Right? They removed a lot of stuff. The real contribution of Java, of course, was really bringing garbage collection to the limelight. Not a new concept in Java. But it really made that. And that is one of the beauties, right? That's where the real merit is. It is right once run anywhere or as a pessimist would call it, right once debug everywhere. But it was still good. We could get the transportation. Powerful virtual machine, a major contribution on the JVM. And, of course, automatic garbage collection and a very powerful ubiquitous library of classes and API. So what happened since 1995? The platform only became stronger and stronger over time. And, of course, so strong that other platforms like .NET picked up on it. And so JVM is one of the most significant contributions that's around. The class library can more ubiquitous and stronger. But what about the Java language? The Java language, unfortunately, turned to be the weakest link. And it turned out to be a real weak link. And, of course, this is one of the biggest concerns in the Java community. We have a major language which is not powerful enough. And, of course, Java 8 is working really hard to fix it. So quite a number of things I'm going to talk about later on around and fix. But you don't have to wait for that, right? It is just around the corner, but you can get ready for it. We deserve better. There are over explosion of 200 languages on the JVM. A lot of languages out there. Which one should we pick? Which one should we use? We cannot, obviously, pick and use all of them, right? We cannot do that. So we have to pick and choose languages that make sense, but why? But if you do, I can bet you this is a pathway to heaven. It is a wonderful world. I've seen it. My friends have seen it. We all get together and have fun in this heaven. It's a great place to be. Why? It gives us flexibility, productivity, expressiveness. It's fun. How is it fun? Let's look at a few examples of it. You all write C++ program. You all write Java programs, right? You all do that. Let's talk about Java for a minute. Productivity is important for me. I want to... Somebody said simplicity is eliminating the work that you don't have to do. You all write C++ and Java and C sharp, right? You know the syntax. I want to write a class called car. How do you write it? Public class car, right? You say public class car. And then you say private int miles. I want a miles in this. And you say private int ear. Oh, dear. I forgot to put final in front of it. I'd better put that. Are you done? No. Public int get miles. And you have to return the miles. Absolutely. You also have to write a method for getting the ear, isn't it? Okay. The phoneme in the meantime, right? It says don't do this. Okay. Get ear. And you have to return the ear, right? And of course you have to have a method to set the miles. So what would you do? You would say void, set miles. Of course, you have to name this variable miles, right? Because there's no other variable in the world. And then you have to say this start miles equals miles. I always want to strangle the person who writes code like this. And then of course are we done? No. We need a constructor. What is this called? This is cerimony, right? What is cerimony? Cerimony is things you have to do before you get to do the stuff you really want to do. What do you really want to do? Write code quickly and run the program and go home. What does this say? No, you got to write that. I know you're kind of grim looking at me. And you're saying, Venkat, no, that's not true. We never do this. Seriously, we never do this. You're telling me what I do is I write the class car. I write the variable miles. Then I gently right click on it. And before I could blink my eyes, my ID vomits the rest of the code for me. So what you're saying is normally in the language it's complex, but it has chip with an ID that constantly vomits for us. But why have those complexities baked in? We could do this really differently, right? For example, if I were to program in Scala, how would I be programming in Scala? I would say, for example, in Scala class car. Well, I want to specify that there's a year, val, miles, and a year, right? And I want this to be an integer. Hey, I want this to be a value which cannot change. Sure, that's why I called it val. VAR miles, which is an integer as well. I don't want to change the value of the miles or then I can declare it val. In this case, I can change it. You say, all right, that's great. You have a class, but I want a getter for it. Done. I want a setter for the miles. Done. I want a constructor for the car. Done. Now you're getting worried. What do I do with my free time? Go home. You shouldn't spend time writing stupid code, right? So absolutely we are done. It works. So you could create instances. You could say, for example, VAR car one equals new car. Internationally I'm not giving the constructor values. The compiler should complain to me and say, why didn't you give me the constructor values, right? There it complains. I tell him the year is 2013 with zero miles and then I can ask him to print out the car and say, give me the value of this car, right? So we don't have to spend our effort writing code. Simple things must be simple and more complicated things should be approachable, somebody said, right? Absolutely. You want that kind of benefit, but this is just scratching the surface. You could go a lot further than this. Let's talk about common things we do in our programming. Now what is the benefit of going across multiple languages? If you know only one language I said, we are very restricted, what happens when you program in multiple languages? Neil Ford coined the term polyglot programmer. And basically the idea of a polyglot programmer is that you use the sharpest tool that's available. How would you feel if somebody comes to your house and says, this is the only tool I would use for everything I do? Your confidence goes low, isn't it? So you want to use the sharpest tool for doing what you do. We are free to move around this language landscape and use the best tool we can. Why would we want to use different tools? Olabini talks about this. I call this the Olabini pyramid. He talks about using different languages for different levels of programs to achieve different results. In a very low level where you need infrastructure code, a lot of verification. If you're writing a server, for example, or you're writing a service which requires very tight coupling and integration and authentication, you want languages that are statically typed. You are in the middle layer. You want a bit of malleability in your layers. Dynamic languages are better choice. And then of course if you want to create DSLs or domain specific languages, you definitely want languages that can give you that power and invariably static type languages don't give you that. So it is to the benefit of your organization to really hire the smartest people, developers and let them use the sharpest tool. If what you're trying to do is to maintain a large organization, then this is very difficult to do. But sometimes you can be more productive with smartest people that you can hire and give them the sharpest tool to get your work done rather than saying we're going to standardize on this and everybody should slow down this particular thing that's available. Why? Because while the other guys are still trying to get their IDEs up, you can finish your project and go eat their lunch. That is the benefit you get from the productivity you can gain. So what are some of the things we can do to boost our productivity? Let's look at a few examples here. The first one is delegation. Let's talk about delegation for a minute. Now, let's look at something you do. You all have read books. You all have read good design books. And what do good design books say? Inheritance is a bad idea. We've read that right? And they say delegation is better, inheritance is bad. You read the book and say totally agree with you. You put the book away, open your IDE and what do you do? Inheritance. Now, why are you using inheritance? You say, you know, that's a great theory this book has. But my language doesn't give me anything better. Inheritance is a choice I have, right? In fact, you just write this class, you say extents or implements or a colon depending on the language you use, and then it brings all those methods for you, right? But what's the problem? It really makes tight coupling. It becomes very hard to maintain code over time. Delegation is superior. But why don't we use delegation? You say, because I got to write all that code in this class, that takes time. Or you can find a fast type, right? But it's really hard to do it. But what if a language can support it for you? Let's look at an example. Class worker. And the class worker has a method called work. And the work method basically says working. So I'm going to say working, right? Very simple method. I'm going to have a method write document, right? So evil things we have to do from time to time. So document. So we have a worker class. Great. Now what do I have? I have a class now. The next class I'm going to create here. Let's call this class a manager. As you would expect, the manager does nothing. Right? And this class says, but I want to get my work done, but I don't want to do anything. But this is a very smart manager, right? So he says, how could I get things done without doing anything? So he says worker, worker equals new worker, right? I've got a worker instance. And then I'm going to define over here. Let's say Bob equals new manager. And I'm going to say hey, Bob.Work. And then I could say Bob.Document, for example, right? That fails. Why? Because the manager doesn't have any useful things in here. But I can simply come here and say delegate. Why don't you just delegate to the worker? And I don't have to put effort. This is groovy delegation, for example. This is also available in language like groovy. So by delegating, you can simply say I have certain methods over here in these classes. I don't want to reimplement these methods. I simply want to delegate my responsibility to this other object. You can overwrite those methods if you want to. It doesn't stop you from doing it. But you don't have to do it. You don't want to copy and paste code in here. You don't want to write duplicate code that routes calls to this method. Why? Because that gets into other problems, like violating the open-closed principle. And you don't want to get into poor software design. But this favors really those principles and gives us very nice way to do things. And of course, we all have to read files. How many of you have ever written code to read files before? How do you feel about it? Yeah, not good. Right? If you're hiring people and you're interviewing somebody and you don't like this person, just tell this person the entire job is to write file I.O. code. This person runs screaming, right? I don't want to work here in this company. That is how bad it is. What is wrong about it? It's not the code you have to write. It's the stupid things you have to do that thousands of try-catch blocks you have to do. But what happens? Java says you will handle the exception. And the programmer says, let me show you who is in power here and puts an empty cash block. Right? You can never tell programmers what to do. They always figure out a way to get around it, right? So you can look around this and say, why are we fighting with the programmers? They're mature people. Let them take care of doing the stuff, the right things. So how do I read a file? We could do this much better. So here I am. Let's say I want to read this file itself. What is the file name? New file. It's called sample.groovy, right? There's sample.groovy. I want to read the content. I want to print it. Right there is a code that's reading and printing the code itself. I don't have to put a lot of effort to do that, right? And you can see the productivity gain we can get from doing something like that. What else can we do with this? With this kind of productivity? Of course, which one would you prefer, by the way? The top one or the bottom one? The top one, of course. If you're a consultant getting paid by the number of lines of code, you're right. The bottom, if you care about your profession, you want to go home on time, right? Absolutely. You want to process XML, right? How many of you have written code to process XML? Almost everybody in the room. How many of you are eager to go do more of that tonight? Not a single person. You see that? Okay, one person. There's always this one person, right? We'll deal with her separately, right? After doing this, don't argue with me right now. So the point really is XML dances several times. In fact, if you do it enough, you'll realize the process, the task of processing XML should be given to people in the prison. No free men or women should ever be forced to do that in my opinion, right? That is how severe it is. But not so if you have good libraries, right? So how do we do this? So let's go ahead and try this. Let's give it a try. I have a little language maps. I want to know who all wrote these languages. I don't want to be able to print this out. I want to display this. I want to write an XML. How do you do this? Well, of course, the minute you are told this, what kind of dual do I need? What kind of library do we need? This is one thing that bothers me to no end. We want, we write, most of us are kind of in a prison in a way. You go to programmers and say, what do you do? I write code. What do you write code? They write code in a framework. If you are only writing code within a framework, you lose free thinking. Once in a while you got to kind of get out and see what it is. So I got an observation here. I think most programmers have a follow-up methodology. I would like to call it as the FED methodology. Have you heard of the FED methodology? It is this. Framework enslaved development. And a lot of people do this. They are kind of pigeonholed in a framework. They only know how to write code in that framework. What's wrong with that? Well, you are productive, but you don't realize how much less productivity you have in what you think is productive. There could be other simple ways to do things if you walk around and look. So for example in this case, I have a map of these languages. I want to print it. How do I do this? So I'm going to say builder and I'm going to say builder equals new groovy.xml. markupbuilder and this is basically just a library class I'm using here, right? And I say builder. And what am I going to ask him? Languages. That's all I did. That's all I wrote. Nothing else. Notice a little xml baby popped out. How simple it is to write this. But of course I want to put real content in it, isn't it? So how do I do that? I'm going to say langs.each and I'm going to have a key and a value in this collection. And at this point I'm going to simply say language. So what am I writing here? This is a dsl, a domain-specific language. This is a dsl to spit out xml, the dirty job you don't want to do. And of course in this case I'm going to say author and in this case I'm going to say author is what? The key value. You can see that comes up as an attribute of this. And then I could of course say here is the name which is the value and you can construct your xml fairly easily. You don't have to do non-productive code to get through these things. It becomes extremely simple. What about running system process? I had a code that needs to go receive SVN subversion commits. And based on that it should do a lot of different things behind the scenes. I wrote this code version C sharp by the way. And it was about 150 lines of code. And it was working fine. I made it extensible, configurable. It served its purpose. And every year I would create four or five subversion repositories. I would just write a configuration tool and it just worked. But of course programmer will secretly tell you there's more fun in rewriting code than reusing code, right? So I said I'm going to rewrite this. And I decided to rewrite this in Ruby for example. And you can take a guess. There was a code to go out and look at subversion and get the commits and only just get the commits. Not even process it. It was 50 lines of code in C sharp to open the process, send the request to it, receive the response back. When I wrote this in Ruby take a quick guess how many lines of code it was. You cannot answer that Prakash. That's correct. Actually more like a one line of code pretty close enough. Let's look at an example of how we could do. In this case I'm going to show it to you in Ruby. I want to go call SVN help. So I'm just creating a string SVN help. That's all I did. And I'm going to call it execute on it. And once I call execute I'm simply calling the text on it and I'm going to just print it. It is extremely simple to go out and talk to system processes as you can see just about a line of code to get things done. Very highly productive. Working with list collections of data. We all do this all the time. How do we deal with it? Enormous amount of ceremony. I'll give you just one example. I'm sure everybody here has faced this in the past. You are told you have a list of names. So you have a list names equals. And then I'm going to say, you know, Joe here and then I have Prakash here, right? And I could have a few names here right here and I want to print them out. How do you print these names? You would write a for loop string name and then you could say names right? You could write it like this in Java for example. And how would you print it? You would say system.out .print line, right? And then what would you do? You would say print the name and it would print all the names clubbed up with no space in between. You say, don't I didn't mean that. And then you would say print and then you would put a plus and then you would say a comma. When you run this what will happen? It'll print the names and there's a comma sticking at the very end. And you look at this and say how do we get rid of that comma from there? Have you ever faced this problem? How did you feel? You felt cheated, isn't it? You said they said this is a high level language. They said this is a simple language. How do we get rid of that stupid comma? And you sat there for a minute and you said, you know what this is a civilized for loop but I cannot use it. And then you decided to fix that problem. What you have to do is to go back here and say int i equals 0. How do you feel about that now? Even worse. And then you realize you have to put a stupid if statement. If i is not the last element, remember that day? And you went that night and you said something is wrong. This cannot be this hard to just put a comma separated list of values, right? You can imagine my surprise. I was programming in Groovy and I was able to say names.join and just give a comma and it was able to print it. The day I learned about this I cried that night. I said my god, this is the way programming should be, right? By the way, you can do this in Java 8 as well because Java 8 is introducing joiners now. This is the way programming should be, productivity should be and how do we learn these things only by looking at what other smart people are doing. This is one thing I've noticed programmers suffer primitive obsession. They always want to write code at the most fundamental level. We cannot give responsibility to code but it doesn't have to be that hard to do things, right? So, we could do a lot of good stuff with this but this can be a pathway to hell as well. Why would this be hell? Look at the things you could do. I can do all of these. Why wouldn't I want to do this? Well, then comes the reality of the world we live in, isn't it? This is all great. This is all things we can do, certainly. Absolutely. But we got real problems to face. You have to contend with the enterprise. You're sitting there and saying, yeah, but the place that I work at, do you know where I work at? Then comes all those concerns, right? All these things can I do where I work at. You need to learn something new. Oh, boy. I went to college. I studied all these years. I got my degree. Now you are telling me, I've got to learn again. You know, honestly, I'll tell you, I was a very bad student. I hated being in school. Because they told me I have to study. Then I have to take that stupid exam. I sucked at it. But then I came to a stage in my life I realized, I don't need to study anymore. I only have to learn. And that was empowering. There were no exams to take. And now I start to learn every day. And it's so energetic to learn. It is so empowering to learn, right? But yes, but if we don't learn every day, we are intimidated by the fact that we have to learn. Our minds don't process things very well. And this requires discipline. How so? Let's talk about this. We have to contend with the enterprise. You go back to work and say, hey, guys, guess what I learned. I learned this new language. It is so awesome. I can do so much work in less code. And everybody around you is looking at you suspiciously. Where did you go? We'll make sure you never go there again. Right? That conference, no more that conference for you. So this is the place we have to contend with. Change is very, very, very hard. You have heard about this. Linda was here. She's the expert on this topic. She told us all about how change is really hard. It is very difficult. Change is extremely hard. But what I realized for myself is the only way to make change easy is to change every day. The biggest problem most of us have is we have drawn a comfort zone and we have settled in it. And it is so nice to be in this comfort zone. The minute we are asked to move our mind says, please don't disturb me. I don't want to do anything different. Why are you bothering me? Change is very hard, very hard. How do we make change effective? There is this guy named Jonathan Hyde. He talks about this thing called happiness hypothesis. He says you are not talking to people with one mind. There are two minds everybody has. One is the rational mind and the other is the emotional mind. He says the rational mind is the rider on the top. You see that guy? The emotional mind is the elephant which is several orders of magnitude bigger than him. But who is in control right now? The rider is. He is sitting on the top and he is happily going. But any minute the elephant decides it is in control what happens. Tough luck. I am sure you have seen this every day. You had good breakfast when you left home. Awesome breakfast. Your mom made, wife made, your husband made which is very rare in my family. But happens. You had great breakfast. You go to work and as soon as you go to work right as you sit down what is that? And there is donuts in front of you or jalebi in front of you. And as soon as you see that donut or jalebi what do you say? Your rational mind says you just had breakfast. You don't need that right now. Yes. You go down and then the emotional mind says it's okay just today. You did work out this morning and your rational mind is trying hard. It says not really. You really don't need those calories. And the next thing you know you reach out to that donut or the jalebi. But here is the problem. Have you ever been successful with that? The problem with me is the minute I touch the donut or jalebi now I pipeline donuts and jalebi. And the next thing you know I've had really a lot of them. And the emotional mind has taken full control and the rational mind shrinks down it's gone right and it's like comforting now right. And the rational mind the big guy says see what did I tell you don't listen to him. This is what happens you're in the meeting you're talking to people and you're saying here's a great idea guys look how productive we are and there are these rational minds listening to you only to be toppled by their rational minds in a few minutes and once the emotional mind takes control it didn't matter what you told them it doesn't matter how productive this is they say are you crazy do you look around the environment we work in none of this will work end of story the meeting is over right. So how do you really effect change of course you heard from Linda how you can effect change right absolutely you need to do that so you have to contend with the enterprise that's extremely important but one of the biggest problems I see is this I cannot tell you how many times programmers come to me and say oh I love doing unit testing I love using groovy I love using groovy but my boss will never allow me to do that I call that BS totally how many things we do without telling the boss honestly right we always do stuff the problem is when people tell you that what they are telling you is they are not convinced but it's so much easier to say I would do it if only they let me do it if you really really really believe it right so first convince yourself but how do you convince yourself the wrong way to convince yourself to go to tell somebody else really how cool this is don't do that the first thing we should avoid is don't be infatuated infatuation doesn't help anybody because when you're infatuated you're like oh this is all awesome first technical question comes and we can't answer it anymore so if you like something immediately go start experimenting with it do a prototype we live in a field where it is cheap to create stuff that's why it's called software create prototypes, thousands of it make it crash, make it work put it back together and that gives you the insight like nobody else can give you and then you say you know what I've seen this work I've felt it and then understand and promote the true values don't go to them and say how cool this language is they don't care, show them what the real business value is what does it do for them what does it do for the company when you sit with the boss you don't say hey I was programming with Groovy you know how cool it is I don't have to do semicolons the boss is like what is semicolon this is the problem with people you go to them and talk technical jargons and they look at you, it's bouncing off of their head and they listen to you and say alright where's the donut now so talk to them about terms they understand hey productivity how soon can we release it how maintainable the code is how fast can we get to the customer don't talk to them about technology you are responsible for technology not your boss the boss is interested in how good you can do and say I found a better tool I used it, I played with it here's the demo, I've seen it I've seen the light of it I'm not telling you what somebody else told me I've seen it, convince yourself first convince your enterprise after learn continuously the pragmatic programmers in their book, pragmatic programmers wrote that you should learn a different language every year I cannot overemphasize it I'm a slow learner honestly I'm a very slow learner you can ask me how much time I took to learn Groovy it took me two days you say really two days is short no that two days is after two years of programming in Ruby and that was hard it was easy to learn Groovy because I said how is Groovy different from Ruby you could say how much time you took to learn Scala well it took me about three days three days to learn Scala yes I've been programming in Erlang for two years by then how was it programming in Erlang, it hurt it was hard I said gee how is Scala different from Erlang so this is one thing I realized over time we cannot learn very large things what we are good at as human beings is to learn the deltas if you come to me and say I want to teach you something it's got to be from here to that step I can take that's the delta I can go if you say you're going to jump from here to that stage over there I'm going to laugh at you I cannot do that we as humans can only learn deltas so if you learn every day a little bit you are climbed so much in your learning you don't even realize and you turn around I do mountain hiking one of my passions I do a lot of mountain hiking I climb by 14,000 feet and when I go up there it's so beautiful to turn around as you are grasping for air and say what a journey it was to come here but how do they come there one step at a time with a few rest along the way of course and that is the beauty right we learn incrementally I was teaching a course in a company in the northeast of the United States and I was teaching the course over there there were two guys in the front row they were about the same age older than me of course and they were sitting there I would introduce a new concept one of the guys in the room would go through panic in his face he would look at this and the student is throwing all kinds of exceptions unhandled exceptions he's looking at these concepts and it's all alien to him he's like oh my god how do I deal with all of this the guy sitting next to him he would immediately raise the hand and say hey hey hey wait wait wait don't go forward yet can you compare this to what Okamel does can you compare this to what Eiffel does can you compare this to what Erlang does and what he was doing the entire week I was teaching very fulfilling for him because he was comparing notes to what he knows he has raised in his level up to that point the other guy I asked him what have you done for the past 15 years he said I programmed in Java every day I said what other language do you use he said why should I use any other language he was having so much trouble now right so the idea is we cannot learn something very drastically new so go out and pick a language which is absolutely useless for you but pick one that is totally different from the one you are used to learn it you will be amazed at what you can do with it when you program back in the language of programming if you took the time to go learn functional programming you can do that in Java 8 when it comes out you are ready for it you can bring and mix these concepts it's not like you are turning your passport and emigrate you could do better in your own languages by learning learning is hard only when we learn less frequently it is a mental muzzle that we have to train every day so the time you need to learn a new language is inversely proportional to the number of languages you have learned in the past 10 years if you only learned one language in the past 10 years it's probably going to take you 10 months or more to learn a new language if you learn one language every year you get through it in a week or so because you are just doing deltas right so invest in yourself every day when you say my company will not allow me to do this you are missing the point totally it is your career we are talking about not your company's career right so it is investment in yourself not your company's that's why it's important so important you say alright what's the last thing that we have to do to make all this work we are looking at languages with enormous amount of power metaprogramming capabilities dynamic capabilities very very scary when you are new to it how do we deal with these and pow gram talks about this corporate programmer club paradox the blub programmer programs in this hypothetical language called blub whatever language it is when you go to him and say hey found this language what do you think he says this language is less powerful than the language I am using why would you think I would use it and rejects it he was showing a more powerful language he doesn't know it's more powerful he would look at it and say having happy programming in the language I am programming in why would I need that stupid language that looks odd and different and he rejects it too the programmer stays with the blub programming language for a long time so pow gram talks about comparing different languages I won't go into these differences right now but if you compare different languages that are out there you would notice the mainstream languages out there are only about half powerful as some of the other languages which can really do a lot of good things of course I am missing a lot of other interesting languages here but just to kind of compare on the JVM itself here and you would see the number below is really about half the power of the other languages you can look at this in pow gram's writings very useful thing to read so it's important for us to move and powl says in business as in war surprises worth as much as force and so be ready for it again the blacks won but using these languages requires discipline and that is in short supply a lot of times discipline is hard, it takes effort it takes courage, it takes dedication and most people would say I don't have patience for it we don't have time for it we got flexibility on our hand productivity on our hand, mirror programming dynamic languages, relaxed compilers how do we contend with all of these programming without automated testing is a road kill this is one of the biggest I would call this as a software crisis of today, lack of enough automation this is the trouble we are in right now if you ask me what's one thing you want to change in the next five years I would say it's education in automation it is our effort in automation, it is where we really do automate and not talk about it anymore we're talked enough about automation time to do it and wait a minute if automation, unit testing other forms of testing is so important, come on if it's so important why are not people doing it I will answer this question without answering it I don't don't raise your hands to this question but if I were to ask you to raise your hand if you think exercising is good for health almost everybody in this room will raise their hand right, agree but if I ask you, keep your hand up if you do exercise how many hands do you think will stay up very few this is called cognitive dissonance we all know something is right but we don't do it why? I will give you a great example I know a person who I can quote myself I program, I work on a computer I spend 20 hours a day literally programming, writing code writing stuff my wonderful wife who cares a lot about me came to me and said Venkat you are working really hard I think you should exercise I looked at her and said you don't get it do you I got books to write how could you exercise when you have bugs to fix right I have bugs to fix, I got books to write I got articles to write, I got speeches to prepare for I don't have time for this exercise stuff go do your stuff, don't bother me she tried tried for years, she would say you need to exercise, how can I tell you so one day I go to home from work, I opened the door and I stumbled on it I said what's that and she said it's a treadmill I said of course I know it's a treadmill why is it here and she said I went to the store and bought it so you can be at home and exercise I said I see, I got it and the next day onwards I took the back door to come into the house that's all the problem and my wife did what any sensible woman would do ignored me and said fine I can't help you a few years went by, I travel a lot I travel about 200,000 miles in a year, nothing compared to what Neal and Rebecca do over there but absolutely a long journey that I take every year and the body takes a heading so about 4-5 years ago I remember very clearly, I was driving home about 1 am from the airport and my body was hurting I was not overweight by any means I was a little bit overweight but I was hurting, my back was hurting my hands were hurting, every part of my body was hurting and I said something is wrong something terrible is wrong I went to the doctor, I said doc, something is really wrong help me black test, urine test, name it EKG, every test possible has been done go away, here's the medicine, take it, come back in a week went back in a week and the doctor said I looked at your records this is a record of a healthy man nothing is wrong with you medically and I'm sure you came back just to tell me you're fine after I gave the medicines, right tell me, tell me what's wrong with me, I'm hurting in fact I'm hurting more well I gave you the best medicine that's available for muscular pain, if that doesn't cure it I have no medicines for you, I said I don't care how much it costs tell me what I can do, I really love what I do I want to get back, I want to be sitting home and the doctor said I'm going to tell you something but it's going to be a little hard I said I don't care how hard it is, tell me he said nothing really great but 30 minutes a day get on the treadmill and my wife was sitting there rolling her eyes more on, I told you so I said okay, I can do that so I went back home, I said honey do we have that treadmill still at home it's still where I left it you can see it if you come to the front door tomorrow so I went there, got on the treadmill the first day I went on the treadmill after about four months of pain by the way just after one walk I'm like, it doesn't seem like it's hurting next morning I get on the treadmill the third morning I get on the treadmill, absolutely no pain the fourth morning I was sitting and working on my computer my wife comes up and says hey how you doing, doing great did you finish exercising already and I got up and said look at me I don't need that stuff I'm fine, why do you think I should waste my time she said oh dear and walked away and the first day I was fine and the sixth day there was the pain and the seventh day there was the pain the eighth day I was on the treadmill, no pain and I tried this a few times and you know what, I love what I do but I don't like hurting when I do that and when I'm spending that 30 stupid minutes most painful time of the day by the way most of the tweets I do is when I'm on the treadmill I let my thoughts wander I tweet, most of my tweets are when I'm on the treadmill because being on the treadmill is so stupid, so silly but that silliness makes the rest of the day so good for me I can focus on what I love doing and guess what I love doing I love programming I hate fixing the stupid bugs I'm not going to tell you that you can write bug free software I'm only interested in those bugs not creeping back in automated tests can do that for you and I've realized that automated testing is the software equivalent of exercising most people will tell you it's good for the health of your system very few have the discipline to do it so if your company wants you to use only standard practices what they are telling you is that you should follow the path to mediocracy I'm sorry I don't want to do that I am not interested in following a standard because the standard is to be obese the standard is to be in poor health the standard is to be in debt in the society and in the software community the current standard is to fail I'm not interested I want to be different I want to do better and I'm sure you do too some people will change when they see the light others when they feel the heat so it could be something we can all do but remember the wise words of Uncle Ben with great power comes greater responsibility but if we technical people don't have the responsibility to do it nobody else will so we have a path in front of us one takes us to the hell and the other takes us to heaven we have a choice but I'm sure I know where you're going to go make your wise choices your efforts will pay thank you so much for your time do we have any questions in the room? you did mention javascript why? on 5 days I don't talk about evil things javascript is javascript is like this bad villain in the movie they kept killing him and he keeps coming back which is amazing resilience right? jokes aside I have the deepest respect for javascript the real problem with javascript is unfortunately most programmers have not taken use of prototypal inheritance inheritance is such a bad idea but prototypal inheritance is such a great mixture of delegation and the language is so intimidating for most of us most of us learn javascript by looking at javascript on the web most javascript on the web sucks so we all learn from wrong examples Douglas Crawford wrote a wonderful book called javascript the good parts I highly recommend the book it's a book that tells us a lot about what you shouldn't do somebody tweeted the other day he had two books sitting next to each other this book was javascript good parts it is this thick and this book was the definitive guide you can see this is all you can do with the language here's what you should really be doing with it that thin so it's a great language most of us have not taken the time to learn it I work with quite a number of programmers who do javascript programming and they tell me when this code works but don't ask me how it works we need to go beyond that we need to really understand the language absolutely no reason to ignore it yes please how many books do I read about programming I ask the audience you didn't ask the question well I intentionally did not ask the question because it is for them to introspect not as strategic for me to collect okay you see you didn't ask the question are you curious how many I want you to ask that question are you curious how many okay Fortran no no you wanted to ask them the question no no I want to answer the question please do you didn't ask the question I'm asking you the question how many programming languages books have you read Pascal no no Fortran then I was not satisfied and then in Brazil in 1987 nobody has heard of object oriented programming right? I had to discover it by myself 1987 okay after hard work jumping in the library with all kinds of magazines at the University of São Paulo oh I discovered that C++ existed then I told the guys at UCLA at the I'm an architect all guys I want to program in C++ said there was the leader of the group that said oh it's okay okay but then there was I didn't get scholarship because the president elected the National Council of Research focus the camera on National Council of Research okay then one more year stay in Brazil for me to go to implement my I had to finish my master's degree in architecture and I had to implement go to the PhD okay then in the meantime I discovered I feel then say there then Kamalisp object system then beta then I'm going to give you 10 more seconds to wrap up I have to find more so a small talk then finally I implemented my PhD in self where in Brazil because abroad I couldn't any other questions or comments please a little louder please groove your scale so ultimately it is actually wrapping up all those just like a framework so you have explored more what the difference you see between a framework based development and a groove so what difference does it make there are empires and there are evil empires but ultimately behind the scenes all these code are being executed right absolutely but ask yourselves in which are you productive if you only use one thing you assume you are productive when you use several things the decision you make is a wise prudent decision not one that you have been enslaved into I'm not asking you to go live in an island isolated but I'm asking you to go find what a free country is right thank you I understand I understand so when he was talking about framework what he meant is the framework that is generally prevalent inside a company not the Scala framework but the groovy framework yeah I do meant that only we have one final question please hi Venkat first of all this is very enlightening and a very interesting talk when I first saw the title about specifically the part with about perils I thought you would touch upon some of the the dark side of some of these new languages that have emerged for example Scala is infamous for a lot of garbage that it generates in memory right so what do you have to say about some of those aspects of that's a great question and so this is what I find very difficult a lot of times with programmers adapting to a lot of new languages and technology it takes so Scala as much as any language is at fault in this case because when you look at some Scala examples or people code that they put out or you look at blogs where people complain they cannot use Scala and you look at that and say why are you using features that are really not meant for application programmers to use and only for library authors to write every language has that but what happens is programmers kind of pick up some of the features and go wild with it and then they come out saying that was really hard any language this is true but Scala especially is Scala is kind of like a city there are good parts of the city you have to go through and there are certain parts of the city you should completely avoid and Scala is no exception to that there's a lot of parts of Scala that you should not go into unless you go with the cop thank you