What is OO? Where did it come from? Where is it going?
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Martin, Robert Cecil
It's been over fifty years since OO was invented. What it is? Do we know? Can we define it? Or is it just a phrase we used to mean "good". Are objects dead? Or will they live on as an important software paradigm? And how do objects fit into Functional Programming? In this talk Uncle Bob goes back over the history of how and why OO was invented, the claims that were made about it and the reality of what we finally realized. He'll discuss how OO is beneficial today, and why it will continue to be important into the future. In the end, he'll present an unambiguous definition that will likely surprise you, and show you why objects will be a primary organizing principle of software for the next several decades at least.
 Hello. How are you? Good. So it's Thursday and it's after lunch and we're not going to do any kind of heavyweight technical thing here because after lunch, you know what happens. Your digestive system needs blood and the only organ that it can steal blood from is your brain. You know your brain requires about 30 to 40 percent of the calories you consume. If you only thought harder, you could lose weight. When you eat, your digestive system needs some of that blood and so it emits hormones into your bloodstream that cause capillaries in your brain to clamp down. And you kind of feel like that. And then you kind of feel like that. So we're going to take this a little bit lower key. The title of this talk is What Is OO? Before I get into that though, did anybody attend Goiko's talk in the last session? Goiko Adzik said, if you ever get a chance to listen to Goiko talk, he's a terrific speaker. He's passionate. He's intense. He's very funny and he's got some good stuff to say. He used an example in his talk which I found fascinating. It was the example out of the 70's where people were curing epilepsy by splitting your brain in half. Now it turns out that there's a bundle of neurons that connects your right brain to your left brain. This is called the corpus callosum. It is just a very simple little cable that runs between the two hemispheres of your brain. Other than that little cable, the two hemispheres are utterly distinct from each other. They're independent. They just communicate across that bundle of neurons. They found that if they severed that bundle of neurons, right down the center line of the brain, for patients with extreme cases of epilepsy, it would cure them. Then they wondered, well okay, but what happened to them after that? They apparently led normal lives. They didn't notice any horrible ill effects. What was the purpose of this corpus callosum? They did some interesting experiments. The experiments are fascinating. They would put your head into a rig so that they could shine images on either the right side or the left side of your eyes. It turns out that the left half of your retinas will go to the right side of your brain. The right half of your retinas go to the left side of your brain, oddly enough. We are strangely constructed, we humans. They would shine an image of a square on one side of your brain. Then they would ask you to draw a picture with the other hand, the opposite hand. They would shine a square into the side of your brain that controlled your right hand. With your left hand, they would ask you to draw the image, a square. The subjects were generally able to do this. They would draw a square. They would put a picture of a triangle up. The subject would be able to draw a triangle. Oddly enough, though, it wasn't the same triangle. It was a triangle, just different shape. If they put a right triangle up, the subject might have drawn an isosceles triangle or some other kind of triangle. They tried this with rectangles. They put a rectangle up and the subject would draw a rectangle but a different rectangle. As they proceeded doing more and more experiments, they noticed that the subject was subvocalizing. They were saying what they were drawing. They would look at it and they would say a square. Then they would draw the square. They asked the subject to stop saying. Don't subvocalize. This was very difficult because the subject would mouth it anyway. They'd ask them to stop doing that. Don't move any muscle in your mouth. They became unable to draw the image. The side of the brain that had to draw it was listening to the words coming out of their mouth and informing them what the other side of the brain was seeing. They found that they could start someone drawing an image. They'd put a picture of a bird up and they would say go ahead and subvocalize all you want. They'd put a picture of a bird up and the guy would say bird. The guy would start drawing the bird. It wasn't the same bird. The guy could see the image that he was drawing. He would shake his head because the side that was looking at the bird he was supposed to draw could see the bird he was drawing and knew it was wrong. He'd shake his head and the other side of the brain would feel that head shake, know what it meant and adjust the drawing. It took them a very long time to draw the bird because it was this yes-no game. The subjects didn't know they were doing it. They just found another way to connect the wiring across the sides of the brain. Fascinating. It has nothing to do with the topic at hand, but interesting nonetheless. What is OO? Okay, what is OO? Now, we've been doing object orientation for 40 years. Started in 1966. We'll talk about that. 76, 86, 96, 06, 46 years. How many of you are younger than that? Your entire life, there has been something called OO. What is it? Do we know what this is? Now, how many of you are programming in an object-oriented language? How do you know? Well, we were told C-sharp is an object-oriented language. Is it? What is OO? All of our modern languages nowadays are object-oriented. At least that's what they tell us. But what is this? Is there anything else like OO? For example, what is it called to be not OO? What is the opposite of object-oriented? Some people would say procedural. Is that right? Is that the opposite? What does it mean to be not OO? Have you ever pointed at someone's design and criticized it by saying, well, that's not very object-oriented. How do you know? What do you mean by that? So let's go back in time. There are three major paradigms. They are named structured, object-oriented, and functional. There are others that claim to be paradigms. There is the whole aspect thing. Anybody ever do any aspect-oriented programming? How well did that work for you? Interesting idea, but it never really went anywhere. The spring people made some use of it here and there. It really didn't go anywhere. Was it really a paradigm? Well, I'm going to come up with a definition of a paradigm, and by that definition, aspects were in fact not. But let's explore what these paradigms were. Structured. The last of the three paradigms to be invented, by the way, the first to get adopted, the last to be invented. Who was the inventor of structured programming? Not that guy. That guy. Edsger Dijkstra wrote a paper in 1968. What was the title of that paper? Go to considered harmful. Famous paper. In this paper, he said, go to is bad. Don't use it. He had a whole bunch of things. He had a whole bunch of things. He had a whole bunch of things. He had a whole bunch of things. He had a whole bunch of things. Go to is bad. Don't use it. He had a whole justification behind this. What was his justification? He showed that it was impossible to prove an algorithm correct if it contained a go to. If you restricted yourself to while loops, if else statements, and regular sequences, you could prove an algorithm correct. Not that you would, but you could. If you include an arbitrary go to, it becomes impossible to prove the algorithm correct. That has deep implications. If you can't prove it correct, you can't reason about it. That's the definition of proving something. Reason about it until you've gotten to a conclusion. If you cannot prove it correct, you cannot reason about it. So the program must be ambiguous. Does anybody here remember the late 60s, early 70s, when Dijkstra published that paper, the wars that were fought over this issue? This was before there was an internet. But the flame wars erupted on the trade journals left and right. People were writing letters to their editors. Dijkstra's a fool. You must be able to use go to's. And other people would say, no, he's a genius. You can't use go to's. And the war raged for months and years. When is the last time any of you used a go to? Anybody used one in the last year? Three by my count. And I'm not one of them. Anybody working with a language that has a go to in it? Now let's be careful. Does it have the key word in bite? Is it implemented in Java? For example, the key word is there. It's just not implemented. There is no go to in Java. Is there a go to in C sharp? Is it implemented? Well, nobody here has used it. So, well, it is. Someone says, it's implemented. Okay, fine. It's implemented. Hardly anybody uses it. It might as well not be implemented in Java. It's just plain not. The problem of structured programming was resolved by our languages. They just took it out. They took it to go to away or they made it so unpopular that no one would use it. It exists in C++, but nobody uses it except a few strange people who are writing IO drivers and we don't pay attention to them anyway. So, the structured programming paradigm succeeded wildly because now our mode of expression simply does not have this thing that Dijkstra said not to use. And by the way, this gives us a clue as to what a paradigm is. A paradigm is a restriction. A paradigm takes something away from us. It does not give us something. Structured programming gave us nothing. Structured programming took something away. Go to. It imposed discipline on direct transfer of control. You could no longer leap from one side of the program to the other. If you needed to change the flow of control, you had to use certain highly disciplined structures, while, if, then, returns, exceptions, breaks. Anybody use a break? Perfectly reasonable, not unstructured. It's not a go-to. Although I tend not to use them too much because I don't like them, but you can use them. They're not unstructured. What was the first paradigm to be designed, to be discovered? The very first. Functional. 1957, ten years before structured. The Lisp language was invented and very, very rapidly after that, the notion that assignment statements were evil became prevalent in the Lisp community. Once the last time you used an assignment statement, within the last millisecond, okay, within the last day, week, that's going to be everybody, isn't it? Because we use a language which has an assignment statement. C-sharp has an assignment statement. Java has an assignment statement. C++ has an assignment statement. They are not functional languages. If you have a language with an assignment statement in it, it's not a functional language. The languages that don't have assignment statements do allow you to change state, but only under intense discipline. You must use special structures in order to change state, equivalent to opening up a database transaction. And following all the rules that you would normally follow for updating a database record, that's how we would change the state of a variable in a functional languages. So a functional language takes away assignment. Two paradigms now. Structured programming took away go-to. Functional programming took away assignment. Who's read the structure and interpretation of computer programs? Not nearly enough of you. All right. Let me get this up on the screen. Probably structure, interpretation of computer programs. SICP, there it is. Welcome to the SICP website. You need to get this book. Better news, it's free. Download it from the net. It's an old book. It is a fantastic book. You will enjoy the fact that you started reading it. It was written by Susman and Abelson, who were two professors at MIT. Both of them are still alive, I believe. These two guys did their lectures. They videotaped their lectures from the 80s. You can watch them on the web. You can watch them drawing lists on the blackboard. Parenthesy, parenthesy, parenthesy, parenthesy, parenthesy. Fantastic to watch them. The book is lovely. It apologizes for nothing. It assumes you know very little and it will prove that to you. And then as you read it, it starts to go through basic algorithms. It does not bother to explain the language it is using. It's using scheme. Scheme is a language that requires no explanation. You open a parenthesy, use a word that happens to be a function. Everything else is an argument. You close the parenthesy. That is the end of the syntax of scheme. They use scheme. They don't even bother to define it. They just kind of use it. You get the idea immediately. The book moves at light speed. As you're reading through it, it just engages concept after concept after concept. It's like reading an adventure novel. And you're throwing the pages or clicking the button, whichever you choose to do. And you get through it. You get to about page 248. And at page 248, they stop this reckless ride that they've been taking you on. And they apologize. There's this pause. They apologize. We're about to ruin your world. We're about to disillusion you. We've painted this lovely picture of computing, but now we have to destroy it because we're introducing an assignment statement. And I remember reading that and I had to stop and go back through the previous 247 pages to prove to myself that in none of that code was there an assignment statement. None of it. They'd done symbol table searches and message passing and accounting applications. They'd done all kinds of stuff. No assignment anywhere in there. Then they say, okay, now we're going to have to introduce this assignment statement. And the assignment statement is going to ruin your world because it imposes a time break into your code. Prior to assignment, if you called a function and handed it some arguments, it would give you a value. If you later called that function and handed it the same arguments, it would give you the same value. The function was predictable. But now that we've introduced assignment, there is this break. You do an assignment statement. You call a function above the assignment statement. It may return a value called the same function below the assignment statement with the same arguments. It can return a different value. Same becomes significant. That's the damage that assignment did. Then they go on for another 50 pages and they stop again. Oh, heavens, we're going to destroy your world even more. And they introduce threads. And I found it amazing that they equated assignment with threads. They are as damaging to the software structure as each other. Threads and assignment statements are roughly equivalent because both of them interfere with time. Enough of that. Fascinating book. You should get it. You should read it. Those are the two paradigms. The third paradigm, invented in 1967, it was invented between those two, was the object oriented paradigm. And since my definition of a paradigm is that it takes something away from you, what did OO take away? Imagine these two guys. Here they are. Let me show them to you. There they are. Much later in time. When they did this amazing event, it was in the mid-60s. They were younger men at the time. This is Ole Johan Dahl and Christian Nygaard who worked at the university in Oslo. There may be people in this room who had them as professors. Oh, one right there. Oh, another one right there. Two guys goofing around with the language algal. Anybody program an algal? Don't say, oh, a little bit. Okay, yep. If you've done any Pascal, that's a pretty close equivalent to algal. Not perfect, but definitely a child of algal. These two guys were goofing around with algal. They were writing a simulator for the ships going in and out of the fjords. I don't know why they were doing this. Probably some efficiency algorithm. They were just simulating the motion of the ships. And I guess they got tired of that because they said to themselves, this language sucks, not in those words. But essentially they said that. They said, isn't there some language thing we could do? Now, you've got to understand the time. This was 1966. Fortran had been proposed in 1953. The concept of languages was younger than everyone in this room. Imagine how close the Agile manifesto seems to most of us. That was how close Fortran was to them. The concept of Fortran was to them. So languages were this new idea. And you didn't look at a languages being delivered to you from on high. You looked at a language as your domain. If you didn't like it, you fiddled with it. And you had the source code. And they did. They had the source code of algal. And they said, hmm, there must be something we can do to this language to make it easier to write this application. Algal. A little history about algal. Algal was a block structured language, much like Pascal. I'm going to do this in a see-ish syntax because that's what most of us understand. Imagine you have a function named f. We don't need a better name than that. Our function has a variable named i. It's local. Where is this local variable stored? On the stack. That's correct. It's on the stack. By the way, it was languages like this that convinced us that our hardware ought to support stacks. One of the first machines I worked on was a PDP-8. The stack was a foreign concept. We had no stack. You could call a function once. You could not recurse. Because it would store the return address in the memory location just above the function. If you called it again, you wiped out the first return address. So you never called the function more than once at a time. No recursion, please. The interesting thing about algal was that it was block structured, which means that inside the function f, you could declare another function. That was a local function to f, just like i is a local variable to f. And it could only be called by f. f could call g, but no one else could because if you returned from f, g didn't exist. It was out of scope. Better yet, g had access to i's to f's variables. So i could call g and it would increment i. Now these guys, Ole Johan Dahl, Christian Nygaard, looked at that. He said, hm, that i variable. That's on the stack. What if we moved it to the heap? f became a constructor, i became an instance variable, g became an instance method. Classes were born. We have object orientation. Because two guys goofing around with a language moved a data structure from the stack to the heap. And we have OO. Was there more to it than that? Oh, of course there was more to it than that. You know what I mean? Once they looked at that idea of taking that and moving it to the heap, they thought, well, what could we do with that? That's kind of like state that has operations associated with it. I can easily change that word right there to class. Get rid of those parentheses. Now I have what looks to us like a normal object oriented thing. Oh, I'd probably have to do this nowadays. Fine. Oh, no, there. I've already got it defined. Now what can you do with that? Well, if you have a class, and they actually called it a class, the word class came when they invented this idea. By the way, where did the word class really come from? The theory of types. And the guy who used the word first in the theory of types was Bertrand Russell, who a mathematician proposed a problem in set theory. And the problem was this. Does the set of all sets that does not contain themselves contain itself? There's a better way to say this. Your mother cooks for people who don't cook for themselves. Who cooks for your mother? A better way to say that is this statement is false. All of those statements are ambiguous. All of them can be proven neither true nor false. They are bizarre statements that have no truth value. And yet they can be stated formally. And Bertrand Russell noticed this and said, well, we can change that. We can create a mode of expression that allows things to be expressed without ambiguity if we impose classes of objects. And we impose types upon those classes. And we only allow certain operations to be performed on certain types. He was not talking about computers. This was rampant during the 30s, 40s, and 50s. This was the mathematical topic at the time. Just at the time Alan Turing was doing his work. Just at the time Bakus was doing his work on Fortran. We have types today. We have classes today because of that mathematical exploration. And so the language that Oliah Handal and Christian Nygaard created, they called it Simula, Simula 67, had classes. And those classes could have methods in them. And those methods they found, you could have more than one class with the same methods. They must be somehow related. And so they came up with the notion of inheritance and polymorphism. Many people have defined OO as encapsulation, inheritance, polymorphism. The big three. Did we have encapsulation before OO? Well, of course we did. I'll write a C program for you. We will put this in point.h. So we've got a nice little header file. Some of you have never seen a header file in your lives. Count yourself lucky. Oh heavens, my machine has decided to do something strange. Struct point. Oh, I'm going to forward declare the struct point. I will not define it. I will simply forward declare it. I'm going to say point star make point. Oh, look at that. Forward declared function. I will create a function void set point. Point point. See if I can type here. Takes a point and it takes int x and int y. An integral point. A point on the integer Cartesian coordinate plane. I could say int get x and say point star and that's all I need. And I could say int, oops, yep, get y. Point star. I could do this. Double distance from point star and point star. By the way, those of you who don't know what that star means, it means pointer. If you don't know what pointer means, it means reference. Notice that I have defined nothing. I have declared many things. Defined nothing. Now I will define it all. Well, not all. I'll just do some of it. There is the definition of my data structure point. Notice the variables x and y. They are in the struct point, but they are not in the header file. My clients do not know about point dot c. They only know about point dot h. So my clients do not know about the variables x and y inside my data structure. When you write a class in dot net in C sharp, where do you put your variables? At the top of the class. What idiot thought that was a good idea? His name was James Gosling, by the way. Almost everything that came into C sharp came out of Java. Did you know you were programming in mostly Java? James Gosling is the guy that put the variables up at the top. We have gotten used to this, but I would like you to think about that. What key word precedes most variables? Yes, private. Doesn't that mean that we shouldn't know about them? Doesn't that mean that they are not important? Doesn't that mean that they are implementation details? Why would we put them up at the top? Now in C plus plus, we did not. In C plus plus, we put all our variables down at the bottom. We had a simple rule in C plus plus. It was called the scissors rule. All public stuff went at the top. All protected stuff went in the middle. All private stuff went at the bottom. For a very simple reason, you could take a pair of scissors, cut the listing. Yes, we did print listings in those days. We cut the listing right below the private stuff and we could hand that partial listing to all of our clients. They wouldn't know about the private stuff. In C, you didn't even have to do that. There was no way for them to know about the private stuff. It wasn't even private. It was simply invisible. There was no way for anybody to look at that declaration, point.h, and know that there's an x and y variable in that class. Our encapsulation in C was better than any object-oriented language out there. The introduction of object-oriented languages weakened encapsulation. It did not strengthen it. In fact, we had to add keywords. Keywords to somehow keep those variables from being used. We didn't need those keywords in C. We just put them in some place where no one could see them. If encapsulation is one of the words that defines OO, well, they've done a piss-poor job at it because we had better encapsulation in C. Another one of the words that we had in the definition of OO was inheritance. Could we do inheritance in C? Well, of course we could. What if I had, oh, named point? Let's create a file called named point. Pint. Yes. Struct named point. Good. Yes. That's a good idea. Oh, we don't need to define it. It's forward-declared, but in our C file, we would say, now, I can take that named point. I can get a pointer to it for those of you who don't know what pointers are, a reference to it. I can cast that reference to a point and hand it to any function that takes a point. This is inheritance. This is how C++ implements inheritance, by the way. I could do inheritance in C long before there was inheritance. And by the way, most of us did. Programmers in the 60s and 70s and the early 80s would do this trick all the time. It was a common enough approach. We'd also do the encapsulation trick. Very frequently, it was the way to keep people from knowing what your variables were. So if encapsulation and inheritance are part of the definition of oh, oh, well, then C must be almost an oh, oh language. There's one more word, polymorphism. Can you do polymorphism in C? Did you hear him? You can do everything in C. This is true. You can. It's a Turing complete language. You can do everything in C. Wow. Can't solve world hunger yet. Okay. Blah, blah, blah, blah. Oh, yes. I'll get there. Get char. Put char. It's sad to me to think that many of you don't know what those functions are. Many of you have never even heard of Unix. Some of you may have heard of it, but you thought it was someone who worked in a harem who'd had an unfortunate operation or accident. Get char and put char were functions, still are functions in the Unix library, which get a character from standard input and put a character to standard output. What is standard input? Don't know. Any device that has input? What is standard output? Don't know. Any device that has output? What does this function do? It copies characters from standard input to standard output. What devices does it use? Don't know. This is polymorphic. This is polymorphism. Get char is a polymorphic function. It's a polymorphic function on a class named file, even though the language does not have a class. It is a polymorphic function on a concept, an abstraction named file. And how does it work? How is it that this get char function can somehow transfer control into the keyboard driver to read characters from the keyboard? Well, it turns out that the file data structure has five pointers to functions in it. Read, write, open, close, seek. L seek, but we won't bother with that. Five pointers to functions sit in that file data structure. And when get char executes, it goes to the file data structure, does not know what device it represents, goes to the read function pointer, calls the function pointed at by the read function pointer, which if the file is a keyboard, goes to the keyboard driver. This is exactly how C++ implements polymorphism. It uses a V table, a vector table. C was a polymorphic language. Although this was hard to do. It required us to obey conventions. You had to have these pointers. Anybody ever write a function pointer in C? Let's see if I can do it without screwing up my screen too much. Yeah, let's see. It looks something like this. Let's see. There. I think that's right. That declares a variable which points to a function that takes a void. Nobody wanted to write that. Besides, you had to initialize these pointers. And if you wanted to call a function, you had to call a function through that pointer. You could not do this. You could not say read. You had to say this. Oh, worse than that. It had to be something like this. No, not that. No. Yeah. You had to do that. And if anybody in anywhere in the code did this, it would work until something changed. And then it would break. And no one would know why it broke. And they'd have to hunt through the code to find the one guy who had called the function directly instead of through the pointer to the function. And so we typically did not do this. We did not do polymorphism in C very often because it was very dangerous. What did C plus plus give us? Safety. Safety. We could put the keyword virtual in front of a function and it would do that automatically for us. It would initialize the function pointers. It would manage them for us. If it called a function, it would automatically do it through the function pointer. We didn't have to pay attention to it. We didn't need function pointers anymore. What OO took away from us was function pointers. We can say that functional programming is discipline imposed upon assignment. We can say that structured programming is discipline imposed upon go to, direct transfer of control. We can say that OO is discipline imposed upon function pointers, indirect transfer of control. You have function pointers in C sharp? You don't need them. You've got polymorphism. That is a function pointer. That's how you do the stuff you would need to do with a function pointer. You don't need function pointers. You've got polymorphism. All three of these paradigms took something away from us. They imposed discipline upon us. They did not give us more capabilities. They gave us less capabilities. But within that less capability came better quality, better safety, better organization. We can say that the last 50 years have been an exploration in what not to do. The paradigms that have come to us have gradually taken stuff away from us. OO is discipline imposed upon function pointers. You might not like that. You might think, wait, wait, wait. OO is about modeling the real world. That's what OO is about. Software is about modeling the real world. Programs are about writing models that help you in the real world. All software is about managing the complexity of expressing things in the real world. Whether it's in C or Lisp or any other language you choose, that is the role of software. Does OO help you do it better? Only in so much as that it's a little safer when you need polymorphism. It's a little more disciplined when you need polymorphism. But it is not the way we model the real world. That's all of software. You might think OO is about putting together functions and data. It's functions and data living together. Really? Oh, sorry. Did the screen come out? Good. If that happens again, yell sooner. We call our functions like that. Is there any difference between that and that? No. There is no difference between these things. Oh, I suppose to make it very, no. There's no difference. Well, there's a dot. I don't think the dot is significant. And the position of the O, I don't think that's significant either. Does anybody know how you call a method in Python? Object-oriented language, perfectly polymorphic. You know how you call a method in Python? That way. You have to put the object in the first position of the function call. It does not have the O dot syntax. There is no difference between those two lines of code other than the dot and the position of the O. By the way, is there any difference between that and the other two? No. That's how you do it in Lisp. You want to translate from C sharp to Lisp, move the parentheses one to the left. That's it. Now you're calling functions the way you do in Lisp. That's why Lisp looks so weird. People look at that and they go, I don't understand that. Why? Well, because the parentheses in the wrong place. Does Lisp have more parentheses than C sharp or less? Less. Less parentheses. It's just that we put them in different places. And so it looks like more, especially that long tail of parentheses at the end. You know what that is? That's the long trail of braces at the end of a function. Same thing. Anybody put long trails of braces at the end of their function except we put them all on different lines, don't we? Brace, brace, brace, brace, brace, brace in a badly written function. Well, in Lisp you do that, peran, peran, peran, peran, peran, same thing. Except that there are fewer parentheses in Lisp. So what's the future? Where are we going? Oh, now I can stand up. Oh, Lordy. What's the future? Where are we going? Is there a future for OO? So now the first thing I'd like to say is why does OO need a future? We always do this. What's the future for C sharp? Why does C sharp need a future? I'm not, that's not to say that C sharp won't be used in the future. But why does it need to evolve? Why does Java need to have another release? Why does C plus plus have to evolve? Why does that happen? Because somewhere in our psyche we believe that if things are not changing, they're wrong. Now, when's the last time C got changed? About the mid-90s. I don't think the C Standards Committee has bothered to make a change to it since. If they did, I don't think anybody pay attention to them. Why change the language? It's good enough as it is. Why do we keep on changing these languages? Why do we think that Agile needs to change? That panel's coming up. Why do we think that OO needs to change or evolve in some way? So let's look at what's happening to our industry, the forces that would cause something to evolve. Who's got a laptop in this room? Good. How many cores does it have? Eight. Who's got an eight? In your laptop right now. Is that four cores and hyperthreading that gives you a virtual four cores or is that eight real cores? Probably that one. Yeah, okay. It's four cores. Four hard cores and then there's this funny thing called hyperthreading that I don't understand and they claim that that gives you more cores. But if you ever look at the usage, the system busy diagram, all the hyperthreaded cores are close to zero. It's not really. Anybody got real eight core in the room? When I come back here next year, many of you will. And the year after that, some of you will have 16 core laptops. And the year after that, one or two of you might have 32 core laptops. Why is this happening? There has been a change, a very dramatic change that we're only just starting to notice. Moore's law, the law that said that the speed of computers would double every 18 months failed and it failed in the early 2000s, 2003, 2004 time frame. Why? Well, we hit the speed of light limit. You know, light propagates at a certain speed. The chips get to a certain size. There is this limit. The chips can switch only so fast. The information can only move so fast. And we tried to push the limit and some of the processors got up to three gigahertz and a couple of them got up to three and a half gigahertz and they started boiling water on them. Anybody ever have a laptop? You could not hold in your lap because you get burned. I sat at a conference once and it was in Florida. So it was hot and sticky. And we went into the keynote and we're all wearing shorts and t-shirts because it was hot and sticky. Went into the keynote and somebody had cranked the air conditioning. Why the heck up? It was like 50 degrees in there. And we're all sitting there, listen to this guy. And it occurred to me. I've got my laptop. So I opened it up and I started my orbit simulator, which is very compute bound. And it would give me a half an hour of heat in my lap. And the other people looked at me and said, can I borrow your laptop? No. Shortly after that time frame, something weird happened. The first dual core started coming out. And did you notice that the clock rate went down back to something like two and a half gigahertz where it has remained ever since? The number of cores is replicating, but not the speed. Now, maybe you didn't know this, but this is the hardware engineers giving you all the finger. Telling the software community, look, you jerks, we've carried you guys on our backs for 40 years. Now it's your turn. We're just going to make lots of little computers. You deal with it. You know what they're doing? They're ripping out all of the neat stuff that made the computers fast. They're taking out the pipeline architectures. They're taking out all the caches. That stuff takes space. And now they want the space for cores. So even though the machine says two and a half gigahertz, those machines are running a lot slower than they used to. The only way we get them to go fast again is by taking advantage of all those cores. And how are we going to do that? We have proven remarkably inept at using one computer well with multiple threads. And now we're going to have to use 32 of them. And then the year after that, 64, what are we going to do when we have to make a system behave well? And it's got 4096 processors in it. And you know, you can say, well, you one run thread on one processor and another thread on another processor. That stops working when you've got 65,535 cores. How are we going to get our software to work well in a highly multi core environment, a massively parallel environment? The answer to that maybe is that first paradigm, the one from 1957, the functional paradigm, the functional paradigm that said assignment might not be such a good idea. If we could write our programs functionally, then vast stretches of that code would change no state. Vast stretches of that code would have the capability that you could call a function with a set of arguments and it would predictably return the same result. Once you have that, it doesn't matter what core it runs on. If you can predict the result of a function, you can run it on any core at all. Just throw it off to a core and run the function. Wouldn't it be nice if we could take our program, split it up into a gazillion little functions, identify the ones that are functional, throw them out to a million cores, gather them all up, throw them out to another million cores, gather all the data back up, throw it out to a million cores. What is that called by the way when you throw it out to a million functions, gather it all back, throw it out, gather it all back? Map reduce. It is very likely that as we move forwards, we're all going to be doing functional programming in a map reduce style so that we can take advantage of massive numbers of cores that we have to deal with. The future of OO is the future of structured, is the future of functional, those three paradigms working together in a language that allows us to not do go tos, not use pointers to functions, not use assignment statements so that we can spread our functions around through multiple cores. Are you asking a question? Oh, good. Let me finish. And then you can ask a question. Okay, I'm done. Ask your question. Ah, what a wonderful question. So the question was what is that? Are we programmers or should we depend upon the operating system people or the compiler people to do this for us? How about all those operating system people done for you so far? Now, that machine right there is actually doing a reasonable job of splitting tasks amongst four cores. Why? Well, there's more than four processes running in there. I can have one process doing IntelliJ and another process doing email and another process doing something. And those processes are actually splitting things up into threads a little bit. And the operating system is fairly good at divvying out the threads to different cores. Fine, good. Is that going to continue to work as we blow the number of cores upwards and upwards and upwards and upwards? The answer to that is probably not. Hopefully we're going to have to do something very strategic. Has anybody done any graphic processor programming? Yeah. Okay. Where you use the fact that the graphics processor is a massively parallel device and you compose data structures which you ship down to the graphics processor, tell it to turn the crank and a whole bunch of answers come back. This is a common approach now in if you need very, very fast computing. You get the graphics processor, which is weird, isn't it? Do you have a good graphics processor on your machine? Good. Then you can reduce, you know, invert matrices. You can do lots of calculation. It doesn't do any graphics. We don't use the graphics processor for graphics anymore. We use it for math, for computation. Oh, every once in a while we'll give it something to render, but that's not its job anymore. Anybody got a laptop with more than one graphics processor? And one of them is just used for sheer computation and the other one does all the rendering? That's not uncommon either. So we've already gone down this route and we're starting to develop these interesting strategies for trying to do this. Is there a generalized way? I don't know. I don't think so. Maybe. So maybe the compiler guys will figure something out. Maybe we won't have to think about it. Yeah, let's depend on that. Anybody else with questions? Well, then thank you all for your attention. Nice to have you all here. I hope now that you've digested your lunch, you'll actually be able to go someplace and learn something. Thank you.
 Hello. How are you? Good. So it's Thursday and it's after lunch and we're not going to  do any kind of heavyweight technical thing here because after lunch, you know what happens.  Your digestive system needs blood and the only organ that it can steal blood from is  your brain. You know your brain requires about 30 to 40 percent of the calories you consume.  If you only thought harder, you could lose weight. When you eat, your digestive system  needs some of that blood and so it emits hormones into your bloodstream that cause capillaries  in your brain to clamp down. And you kind of feel like that. And then you kind of feel  like that. So we're going to take this a little bit lower key. The title of this talk is What  Is OO? Before I get into that though, did anybody attend Goiko's talk in the last session?  Goiko Adzik said, if you ever get a chance to listen to Goiko talk, he's a terrific  speaker. He's passionate. He's intense. He's very funny and he's got some good stuff to  say. He used an example in his talk which I found fascinating. It was the example out  of the 70's where people were curing epilepsy by splitting your brain in half. Now it turns  out that there's a bundle of neurons that connects your right brain to your left brain.  This is called the corpus callosum. It is just a very simple little cable that runs  between the two hemispheres of your brain. Other than that little cable, the two hemispheres  are utterly distinct from each other. They're independent. They just communicate across  that bundle of neurons. They found that if they severed that bundle of neurons, right  down the center line of the brain, for patients with extreme cases of epilepsy, it would cure  them. Then they wondered, well okay, but what happened to them after that? They apparently  led normal lives. They didn't notice any horrible ill effects. What was the purpose of this  corpus callosum? They did some interesting experiments. The experiments are fascinating.  They would put your head into a rig so that they could shine images on either the right  side or the left side of your eyes. It turns out that the left half of your retinas will  go to the right side of your brain. The right half of your retinas go to the left side of  your brain, oddly enough. We are strangely constructed, we humans. They would shine an  image of a square on one side of your brain. Then they would ask you to draw a picture  with the other hand, the opposite hand. They would shine a square into the side of your  brain that controlled your right hand. With your left hand, they would ask you to draw  the image, a square. The subjects were generally able to do this. They would draw a square.  They would put a picture of a triangle up. The subject would be able to draw a triangle.  Oddly enough, though, it wasn't the same triangle. It was a triangle, just different  shape. If they put a right triangle up, the subject might have drawn an isosceles triangle  or some other kind of triangle. They tried this with rectangles. They put a rectangle  up and the subject would draw a rectangle but a different rectangle. As they proceeded  doing more and more experiments, they noticed that the subject was subvocalizing. They were  saying what they were drawing. They would look at it and they would say a square. Then  they would draw the square. They asked the subject to stop saying. Don't subvocalize.  This was very difficult because the subject would mouth it anyway. They'd ask them to  stop doing that. Don't move any muscle in your mouth. They became unable to draw the  image. The side of the brain that had to draw it was listening to the words coming out of  their mouth and informing them what the other side of the brain was seeing. They found that  they could start someone drawing an image. They'd put a picture of a bird up and they  would say go ahead and subvocalize all you want. They'd put a picture of a bird up and  the guy would say bird. The guy would start drawing the bird. It wasn't the same bird.  The guy could see the image that he was drawing. He would shake his head because the side that  was looking at the bird he was supposed to draw could see the bird he was drawing and  knew it was wrong. He'd shake his head and the other side of the brain would feel that  head shake, know what it meant and adjust the drawing. It took them a very long time  to draw the bird because it was this yes-no game. The subjects didn't know they were doing  it. They just found another way to connect the wiring across the sides of the brain.  Fascinating. It has nothing to do with the topic at hand, but interesting nonetheless.  What is OO? Okay, what is OO? Now, we've been doing object orientation for 40 years.  Started in 1966. We'll talk about that. 76, 86, 96, 06, 46 years. How many of you are  younger than that? Your entire life, there has been something called OO. What is it?  Do we know what this is? Now, how many of you are programming in an object-oriented  language? How do you know? Well, we were told C-sharp is an object-oriented language. Is  it? What is OO? All of our modern languages nowadays are object-oriented. At least that's  what they tell us. But what is this? Is there anything else like OO? For example, what is  it called to be not OO? What is the opposite of object-oriented? Some people would say  procedural. Is that right? Is that the opposite? What does it mean to be not OO? Have you ever  pointed at someone's design and criticized it by saying, well, that's not very object-oriented.  How do you know? What do you mean by that? So let's go back in time. There are three  major paradigms. They are named structured, object-oriented, and functional. There are  others that claim to be paradigms. There is the whole aspect thing. Anybody ever do any  aspect-oriented programming? How well did that work for you? Interesting idea, but it never  really went anywhere. The spring people made some use of it here and there. It really didn't  go anywhere. Was it really a paradigm? Well, I'm going to come up with a definition of  a paradigm, and by that definition, aspects were in fact not. But let's explore what  these paradigms were. Structured. The last of the three paradigms to be invented, by  the way, the first to get adopted, the last to be invented. Who was the inventor of structured  programming? Not that guy. That guy. Edsger Dijkstra wrote a paper in 1968. What was the  title of that paper? Go to considered harmful. Famous paper. In this paper, he said, go  to is bad. Don't use it. He had a whole bunch of things. He had a whole bunch of things.  He had a whole bunch of things. He had a whole bunch of things. He had a whole bunch of things.  Go to is bad. Don't use it. He had a whole justification behind this. What was his justification?  He showed that it was impossible to prove an algorithm correct if it contained a go  to. If you restricted yourself to while loops, if else statements, and regular sequences,  you could prove an algorithm correct. Not that you would, but you could. If you include  an arbitrary go to, it becomes impossible to prove the algorithm correct. That has deep  implications. If you can't prove it correct, you can't reason about it. That's the definition  of proving something. Reason about it until you've gotten to a conclusion. If you cannot  prove it correct, you cannot reason about it. So the program must be ambiguous. Does  anybody here remember the late 60s, early 70s, when Dijkstra published that paper, the wars  that were fought over this issue? This was before there was an internet. But the flame  wars erupted on the trade journals left and right. People were writing letters to their  editors. Dijkstra's a fool. You must be able to use go to's. And other people would say,  no, he's a genius. You can't use go to's. And the war raged for months and years. When  is the last time any of you used a go to? Anybody used one in the last year? Three by  my count. And I'm not one of them. Anybody working with a language that has a go to in  it? Now let's be careful. Does it have the key word in bite? Is it implemented in Java?  For example, the key word is there. It's just not implemented. There is no go to in  Java. Is there a go to in C sharp? Is it implemented? Well, nobody here has used it. So, well,  it is. Someone says, it's implemented. Okay, fine. It's implemented. Hardly anybody uses  it. It might as well not be implemented in Java. It's just plain not. The problem of  structured programming was resolved by our languages. They just took it out. They took  it to go to away or they made it so unpopular that no one would use it. It exists in C++,  but nobody uses it except a few strange people who are writing IO drivers and we don't pay  attention to them anyway. So, the structured programming paradigm succeeded wildly because  now our mode of expression simply does not have this thing that Dijkstra said not to  use. And by the way, this gives us a clue as to what a paradigm is. A paradigm is a  restriction. A paradigm takes something away from us. It does not give us something. Structured  programming gave us nothing. Structured programming took something away. Go to. It imposed discipline  on direct transfer of control. You could no longer leap from one side of the program to  the other. If you needed to change the flow of control, you had to use certain highly  disciplined structures, while, if, then, returns, exceptions, breaks. Anybody use a break?  Perfectly reasonable, not unstructured. It's not a go-to. Although I tend not to use them  too much because I don't like them, but you can use them. They're not unstructured. What  was the first paradigm to be designed, to be discovered? The very first. Functional.  1957, ten years before structured. The Lisp language was invented and very, very rapidly  after that, the notion that assignment statements were evil became prevalent in the Lisp community.  Once the last time you used an assignment statement, within the last millisecond, okay, within  the last day, week, that's going to be everybody, isn't it? Because we use a language which  has an assignment statement. C-sharp has an assignment statement. Java has an assignment  statement. C++ has an assignment statement. They are not functional languages. If you  have a language with an assignment statement in it, it's not a functional language. The  languages that don't have assignment statements do allow you to change state, but only under  intense discipline. You must use special structures in order to change state, equivalent to opening  up a database transaction. And following all the rules that you would normally follow for  updating a database record, that's how we would change the state of a variable in a functional  languages. So a functional language takes away assignment. Two paradigms now. Structured  programming took away go-to. Functional programming took away assignment. Who's read the structure  and interpretation of computer programs? Not nearly enough of you. All right. Let me  get this up on the screen. Probably structure, interpretation of computer programs. SICP,  there it is. Welcome to the SICP website. You need to get this book. Better news, it's  free. Download it from the net. It's an old book. It is a fantastic book. You will enjoy  the fact that you started reading it. It was written by Susman and Abelson, who were two  professors at MIT. Both of them are still alive, I believe. These two guys did their  lectures. They videotaped their lectures from the 80s. You can watch them on the web. You  can watch them drawing lists on the blackboard. Parenthesy, parenthesy, parenthesy, parenthesy,  parenthesy. Fantastic to watch them. The book is lovely. It apologizes for nothing.  It assumes you know very little and it will prove that to you. And then as you read it,  it starts to go through basic algorithms. It does not bother to explain the language  it is using. It's using scheme. Scheme is a language that requires no explanation. You  open a parenthesy, use a word that happens to be a function. Everything else is an argument.  You close the parenthesy. That is the end of the syntax of scheme. They use scheme.  They don't even bother to define it. They just kind of use it. You get the idea immediately.  The book moves at light speed. As you're reading through it, it just engages concept after concept  after concept. It's like reading an adventure novel. And you're throwing the pages or clicking  the button, whichever you choose to do. And you get through it. You get to about page  248. And at page 248, they stop this reckless ride that they've been taking you on. And  they apologize. There's this pause. They apologize. We're about to ruin your world. We're about  to disillusion you. We've painted this lovely picture of computing, but now we have to destroy  it because we're introducing an assignment statement. And I remember reading that and  I had to stop and go back through the previous 247 pages to prove to myself that in none  of that code was there an assignment statement. None of it. They'd done symbol table searches  and message passing and accounting applications. They'd done all kinds of stuff. No assignment  anywhere in there. Then they say, okay, now we're going to have to introduce this assignment  statement. And the assignment statement is going to ruin your world because it imposes  a time break into your code. Prior to assignment, if you called a function and handed it some  arguments, it would give you a value. If you later called that function and handed it the  same arguments, it would give you the same value. The function was predictable. But now  that we've introduced assignment, there is this break. You do an assignment statement.  You call a function above the assignment statement. It may return a value called the same function  below the assignment statement with the same arguments. It can return a different value.  Same becomes significant. That's the damage that assignment did. Then they go on for another  50 pages and they stop again. Oh, heavens, we're going to destroy your world even more.  And they introduce threads. And I found it amazing that they equated assignment with  threads. They are as damaging to the software structure as each other. Threads and assignment  statements are roughly equivalent because both of them interfere with time. Enough of  that. Fascinating book. You should get it. You should read it. Those are the two paradigms.  The third paradigm, invented in 1967, it was invented between those two, was the object  oriented paradigm. And since my definition of a paradigm is that it takes something away  from you, what did OO take away? Imagine these two guys. Here they are. Let me show  them to you. There they are. Much later in time. When they did this amazing event, it  was in the mid-60s. They were younger men at the time. This is Ole Johan Dahl and Christian  Nygaard who worked at the university in Oslo. There may be people in this room who had them  as professors. Oh, one right there. Oh, another one right there. Two guys goofing around with  the language algal. Anybody program an algal? Don't say, oh, a little bit. Okay, yep. If  you've done any Pascal, that's a pretty close equivalent to algal. Not perfect, but definitely  a child of algal. These two guys were goofing around with algal. They were writing a simulator  for the ships going in and out of the fjords. I don't know why they were doing this. Probably  some efficiency algorithm. They were just simulating the motion of the ships. And I guess they  got tired of that because they said to themselves, this language sucks, not in those words. But  essentially they said that. They said, isn't there some language thing we could do? Now,  you've got to understand the time. This was 1966. Fortran had been proposed in 1953. The  concept of languages was younger than everyone in this room. Imagine how close the Agile  manifesto seems to most of us. That was how close Fortran was to them. The concept of  Fortran was to them. So languages were this new idea. And you didn't look at a languages  being delivered to you from on high. You looked at a language as your domain. If you didn't  like it, you fiddled with it. And you had the source code. And they did. They had the  source code of algal. And they said, hmm, there must be something we can do to this language  to make it easier to write this application. Algal. A little history about algal. Algal  was a block structured language, much like Pascal. I'm going to do this in a see-ish  syntax because that's what most of us understand. Imagine you have a function named f. We don't  need a better name than that. Our function has a variable named i. It's local. Where  is this local variable stored? On the stack. That's correct. It's on the stack. By the  way, it was languages like this that convinced us that our hardware ought to support stacks.  One of the first machines I worked on was a PDP-8. The stack was a foreign concept. We  had no stack. You could call a function once. You could not recurse. Because it would store  the return address in the memory location just above the function. If you called it  again, you wiped out the first return address. So you never called the function more than  once at a time. No recursion, please. The interesting thing about algal was that it  was block structured, which means that inside the function f, you could declare another  function. That was a local function to f, just like i is a local variable to f. And  it could only be called by f. f could call g, but no one else could because if you returned  from f, g didn't exist. It was out of scope. Better yet, g had access to i's to f's variables.  So i could call g and it would increment i. Now these guys, Ole Johan Dahl, Christian  Nygaard, looked at that. He said, hm, that i variable. That's on the stack. What if  we moved it to the heap? f became a constructor, i became an instance variable, g became an  instance method. Classes were born. We have object orientation. Because two guys goofing  around with a language moved a data structure from the stack to the heap. And we have OO.  Was there more to it than that? Oh, of course there was more to it than that. You know what  I mean? Once they looked at that idea of taking that and moving it to the heap, they thought,  well, what could we do with that? That's kind of like state that has operations associated  with it. I can easily change that word right there to class. Get rid of those parentheses.  Now I have what looks to us like a normal object oriented thing. Oh, I'd probably have to do  this nowadays. Fine. Oh, no, there. I've already got it defined. Now what can you do with  that? Well, if you have a class, and they actually called it a class, the word class  came when they invented this idea. By the way, where did the word class really come  from? The theory of types. And the guy who used the word first in the theory of types  was Bertrand Russell, who a mathematician proposed a problem in set theory. And the problem  was this. Does the set of all sets that does not contain themselves contain itself? There's  a better way to say this. Your mother cooks for people who don't cook for themselves.  Who cooks for your mother? A better way to say that is this statement is false. All of  those statements are ambiguous. All of them can be proven neither true nor false. They  are bizarre statements that have no truth value. And yet they can be stated formally. And Bertrand  Russell noticed this and said, well, we can change that. We can create a mode of expression  that allows things to be expressed without ambiguity if we impose classes of objects.  And we impose types upon those classes. And we only allow certain operations to be performed  on certain types. He was not talking about computers. This was rampant during the 30s,  40s, and 50s. This was the mathematical topic at the time. Just at the time Alan Turing  was doing his work. Just at the time Bakus was doing his work on Fortran. We have types  today. We have classes today because of that mathematical exploration. And so the language  that Oliah Handal and Christian Nygaard created, they called it Simula, Simula 67, had classes.  And those classes could have methods in them. And those methods they found, you could have  more than one class with the same methods. They must be somehow related. And so they  came up with the notion of inheritance and polymorphism. Many people have defined OO  as encapsulation, inheritance, polymorphism. The big three. Did we have encapsulation before  OO? Well, of course we did. I'll write a C program for you. We will put this in point.h.  So we've got a nice little header file. Some of you have never seen a header file in your  lives. Count yourself lucky. Oh heavens, my machine has decided to do something strange.  Struct point. Oh, I'm going to forward declare the struct point. I will not define it. I  will simply forward declare it. I'm going to say point star make point. Oh, look at  that. Forward declared function. I will create a function void set point. Point point. See  if I can type here. Takes a point and it takes int x and int y. An integral point. A point  on the integer Cartesian coordinate plane. I could say int get x and say point star and  that's all I need. And I could say int, oops, yep, get y. Point star. I could do this. Double  distance from point star and point star. By the way, those of you who don't know what  that star means, it means pointer. If you don't know what pointer means, it means reference.  Notice that I have defined nothing. I have declared many things. Defined nothing. Now  I will define it all. Well, not all. I'll just do some of it. There is the definition  of my data structure point. Notice the variables x and y. They are in the struct point, but  they are not in the header file. My clients do not know about point dot c. They only know  about point dot h. So my clients do not know about the variables x and y inside my data  structure. When you write a class in dot net in C sharp, where do you put your variables?  At the top of the class. What idiot thought that was a good idea? His name was James Gosling,  by the way. Almost everything that came into C sharp came out of Java. Did you know you  were programming in mostly Java? James Gosling is the guy that put the variables up at the  top. We have gotten used to this, but I would like you to think about that. What key word  precedes most variables? Yes, private. Doesn't that mean that we shouldn't know about them?  Doesn't that mean that they are not important? Doesn't that mean that they are implementation  details? Why would we put them up at the top? Now in C plus plus, we did not. In C plus  plus, we put all our variables down at the bottom. We had a simple rule in C plus plus.  It was called the scissors rule. All public stuff went at the top. All protected stuff  went in the middle. All private stuff went at the bottom. For a very simple reason, you  could take a pair of scissors, cut the listing. Yes, we did print listings in those days.  We cut the listing right below the private stuff and we could hand that partial listing  to all of our clients. They wouldn't know about the private stuff. In C, you didn't even have  to do that. There was no way for them to know about the private stuff. It wasn't even private.  It was simply invisible. There was no way for anybody to look at that declaration, point.h,  and know that there's an x and y variable in that class. Our encapsulation in C was  better than any object-oriented language out there. The introduction of object-oriented  languages weakened encapsulation. It did not strengthen it. In fact, we had to add keywords.  Keywords to somehow keep those variables from being used. We didn't need those keywords  in C. We just put them in some place where no one could see them. If encapsulation is  one of the words that defines OO, well, they've done a piss-poor job at it because we had  better encapsulation in C. Another one of the words that we had in the definition of  OO was inheritance. Could we do inheritance in C? Well, of course we could. What if I  had, oh, named point? Let's create a file called named point. Pint. Yes. Struct named  point. Good. Yes. That's a good idea. Oh, we don't need to define it. It's forward-declared,  but in our C file, we would say, now, I can take that named point. I can get a pointer  to it for those of you who don't know what pointers are, a reference to it. I can cast  that reference to a point and hand it to any function that takes a point. This is inheritance.  This is how C++ implements inheritance, by the way. I could do inheritance in C long  before there was inheritance. And by the way, most of us did. Programmers in the 60s and  70s and the early 80s would do this trick all the time. It was a common enough approach.  We'd also do the encapsulation trick. Very frequently, it was the way to keep people  from knowing what your variables were. So if encapsulation and inheritance are part  of the definition of oh, oh, well, then C must be almost an oh, oh language. There's  one more word, polymorphism. Can you do polymorphism in C? Did you hear him? You can do everything  in C. This is true. You can. It's a Turing complete language. You can do everything in  C. Wow. Can't solve world hunger yet. Okay. Blah, blah, blah, blah. Oh, yes. I'll get  there. Get char. Put char. It's sad to me to think that many of you don't know what  those functions are. Many of you have never even heard of Unix. Some of you may have heard  of it, but you thought it was someone who worked in a harem who'd had an unfortunate  operation or accident. Get char and put char were functions, still are functions in the  Unix library, which get a character from standard input and put a character to standard output.  What is standard input? Don't know. Any device that has input? What is standard output? Don't  know. Any device that has output? What does this function do? It copies characters from  standard input to standard output. What devices does it use? Don't know. This is polymorphic.  This is polymorphism. Get char is a polymorphic function. It's a polymorphic function on a  class named file, even though the language does not have a class. It is a polymorphic  function on a concept, an abstraction named file. And how does it work? How is it that  this get char function can somehow transfer control into the keyboard driver to read characters  from the keyboard? Well, it turns out that the file data structure has five pointers to  functions in it. Read, write, open, close, seek. L seek, but we won't bother with that.  Five pointers to functions sit in that file data structure. And when get char executes,  it goes to the file data structure, does not know what device it represents, goes to the  read function pointer, calls the function pointed at by the read function pointer, which  if the file is a keyboard, goes to the keyboard driver. This is exactly how C++ implements  polymorphism. It uses a V table, a vector table. C was a polymorphic language. Although  this was hard to do. It required us to obey conventions. You had to have these pointers.  Anybody ever write a function pointer in C? Let's see if I can do it without screwing  up my screen too much. Yeah, let's see. It looks something like this. Let's see. There.  I think that's right. That declares a variable which points to a function that takes a void.  Nobody wanted to write that. Besides, you had to initialize these pointers. And if you  wanted to call a function, you had to call a function through that pointer. You could  not do this. You could not say read. You had to say this. Oh, worse than that. It had to  be something like this. No, not that. No. Yeah. You had to do that. And if anybody in  anywhere in the code did this, it would work until something changed. And then it would  break. And no one would know why it broke. And they'd have to hunt through the code to  find the one guy who had called the function directly instead of through the pointer to  the function. And so we typically did not do this. We did not do polymorphism in C very  often because it was very dangerous. What did C plus plus give us? Safety. Safety. We  could put the keyword virtual in front of a function and it would do that automatically  for us. It would initialize the function pointers. It would manage them for us. If it called  a function, it would automatically do it through the function pointer. We didn't have to pay  attention to it. We didn't need function pointers anymore. What OO took away from us was function  pointers. We can say that functional programming is discipline imposed upon assignment. We  can say that structured programming is discipline imposed upon go to, direct transfer of control.  We can say that OO is discipline imposed upon function pointers, indirect transfer of control.  You have function pointers in C sharp? You don't need them. You've got polymorphism.  That is a function pointer. That's how you do the stuff you would need to do with a function  pointer. You don't need function pointers. You've got polymorphism. All three of these  paradigms took something away from us. They imposed discipline upon us. They did not give  us more capabilities. They gave us less capabilities. But within that less capability came better  quality, better safety, better organization. We can say that the last 50 years have been  an exploration in what not to do. The paradigms that have come to us have gradually taken  stuff away from us. OO is discipline imposed upon function pointers. You might not like  that. You might think, wait, wait, wait. OO is about modeling the real world. That's  what OO is about. Software is about modeling the real world. Programs are about writing  models that help you in the real world. All software is about managing the complexity  of expressing things in the real world. Whether it's in C or Lisp or any other language you  choose, that is the role of software. Does OO help you do it better? Only in so much  as that it's a little safer when you need polymorphism. It's a little more disciplined  when you need polymorphism. But it is not the way we model the real world. That's all  of software. You might think OO is about putting together functions and data. It's functions  and data living together. Really? Oh, sorry. Did the screen come out? Good. If that happens  again, yell sooner. We call our functions like that. Is there any difference between  that and that? No. There is no difference between these things. Oh, I suppose to make  it very, no. There's no difference. Well, there's a dot. I don't think the dot is significant.  And the position of the O, I don't think that's significant either. Does anybody know how  you call a method in Python? Object-oriented language, perfectly polymorphic. You know  how you call a method in Python? That way. You have to put the object in the first position  of the function call. It does not have the O dot syntax. There is no difference between  those two lines of code other than the dot and the position of the O. By the way, is  there any difference between that and the other two? No. That's how you do it in Lisp.  You want to translate from C sharp to Lisp, move the parentheses one to the left. That's  it. Now you're calling functions the way you do in Lisp. That's why Lisp looks so weird.  People look at that and they go, I don't understand that. Why? Well, because the parentheses  in the wrong place. Does Lisp have more parentheses than C sharp or less? Less. Less parentheses.  It's just that we put them in different places. And so it looks like more, especially that  long tail of parentheses at the end. You know what that is? That's the long trail of braces  at the end of a function. Same thing. Anybody put long trails of braces at the end of their  function except we put them all on different lines, don't we? Brace, brace, brace, brace,  brace, brace in a badly written function. Well, in Lisp you do that, peran, peran, peran,  peran, peran, same thing. Except that there are fewer parentheses in Lisp. So what's  the future? Where are we going? Oh, now I can stand up. Oh, Lordy. What's the future?  Where are we going? Is there a future for OO? So now the first thing I'd like to say is  why does OO need a future? We always do this. What's the future for C sharp? Why does C  sharp need a future? I'm not, that's not to say that C sharp won't be used in the future.  But why does it need to evolve? Why does Java need to have another release? Why does C plus  plus have to evolve? Why does that happen? Because somewhere in our psyche we believe  that if things are not changing, they're wrong. Now, when's the last time C got changed? About  the mid-90s. I don't think the C Standards Committee has bothered to make a change to  it since. If they did, I don't think anybody pay attention to them. Why change the language?  It's good enough as it is. Why do we keep on changing these languages? Why do we think  that Agile needs to change? That panel's coming up. Why do we think that OO needs to change  or evolve in some way? So let's look at what's happening to our industry, the forces that  would cause something to evolve. Who's got a laptop in this room? Good. How many cores  does it have? Eight. Who's got an eight? In your laptop right now. Is that four cores  and hyperthreading that gives you a virtual four cores or is that eight real cores? Probably  that one. Yeah, okay. It's four cores. Four hard cores and then there's this funny thing  called hyperthreading that I don't understand and they claim that that gives you more cores.  But if you ever look at the usage, the system busy diagram, all the hyperthreaded cores  are close to zero. It's not really. Anybody got real eight core in the room? When I come  back here next year, many of you will. And the year after that, some of you will have  16 core laptops. And the year after that, one or two of you might have 32 core laptops.  Why is this happening? There has been a change, a very dramatic change that we're only just  starting to notice. Moore's law, the law that said that the speed of computers would double  every 18 months failed and it failed in the early 2000s, 2003, 2004 time frame. Why? Well,  we hit the speed of light limit. You know, light propagates at a certain speed. The chips  get to a certain size. There is this limit. The chips can switch only so fast. The information  can only move so fast. And we tried to push the limit and some of the processors got up  to three gigahertz and a couple of them got up to three and a half gigahertz and they  started boiling water on them. Anybody ever have a laptop? You could not hold in your  lap because you get burned. I sat at a conference once and it was in Florida. So it was hot  and sticky. And we went into the keynote and we're all wearing shorts and t-shirts because  it was hot and sticky. Went into the keynote and somebody had cranked the air conditioning.  Why the heck up? It was like 50 degrees in there. And we're all sitting there, listen  to this guy. And it occurred to me. I've got my laptop. So I opened it up and I started  my orbit simulator, which is very compute bound. And it would give me a half an hour  of heat in my lap. And the other people looked at me and said, can I borrow your laptop? No.  Shortly after that time frame, something weird happened. The first dual core started  coming out. And did you notice that the clock rate went down back to something like two  and a half gigahertz where it has remained ever since? The number of cores is replicating,  but not the speed. Now, maybe you didn't know this, but this is the hardware engineers giving  you all the finger. Telling the software community, look, you jerks, we've carried you guys on  our backs for 40 years. Now it's your turn. We're just going to make lots of little computers.  You deal with it. You know what they're doing? They're ripping out all of the neat stuff that  made the computers fast. They're taking out the pipeline architectures. They're taking  out all the caches. That stuff takes space. And now they want the space for cores. So  even though the machine says two and a half gigahertz, those machines are running a lot  slower than they used to. The only way we get them to go fast again is by taking advantage  of all those cores. And how are we going to do that? We have proven remarkably inept at  using one computer well with multiple threads. And now we're going to have to use 32 of them.  And then the year after that, 64, what are we going to do when we have to make a system  behave well? And it's got 4096 processors in it. And you know, you can say, well, you  one run thread on one processor and another thread on another processor. That stops working  when you've got 65,535 cores. How are we going to get our software to work well in a highly  multi core environment, a massively parallel environment? The answer to that maybe is that  first paradigm, the one from 1957, the functional paradigm, the functional paradigm that said  assignment might not be such a good idea. If we could write our programs functionally,  then vast stretches of that code would change no state. Vast stretches of that code would  have the capability that you could call a function with a set of arguments and it would  predictably return the same result. Once you have that, it doesn't matter what core it  runs on. If you can predict the result of a function, you can run it on any core at  all. Just throw it off to a core and run the function. Wouldn't it be nice if we could  take our program, split it up into a gazillion little functions, identify the ones that are  functional, throw them out to a million cores, gather them all up, throw them out to another  million cores, gather all the data back up, throw it out to a million cores. What is that  called by the way when you throw it out to a million functions, gather it all back, throw  it out, gather it all back? Map reduce. It is very likely that as we move forwards, we're  all going to be doing functional programming in a map reduce style so that we can take  advantage of massive numbers of cores that we have to deal with. The future of OO is  the future of structured, is the future of functional, those three paradigms working  together in a language that allows us to not do go tos, not use pointers to functions,  not use assignment statements so that we can spread our functions around through multiple  cores. Are you asking a question? Oh, good. Let me finish. And then you can ask a question.  Okay, I'm done. Ask your question. Ah, what a wonderful question. So the question was  what is that? Are we programmers or should we depend upon the operating system people  or the compiler people to do this for us? How about all those operating system people  done for you so far? Now, that machine right there is actually doing a reasonable job of  splitting tasks amongst four cores. Why? Well, there's more than four processes running  in there. I can have one process doing IntelliJ and another process doing email and another  process doing something. And those processes are actually splitting things up into threads  a little bit. And the operating system is fairly good at divvying out the threads to  different cores. Fine, good. Is that going to continue to work as we blow the number  of cores upwards and upwards and upwards and upwards? The answer to that is probably not.  Hopefully we're going to have to do something very strategic. Has anybody done any graphic  processor programming? Yeah. Okay. Where you use the fact that the graphics processor is  a massively parallel device and you compose data structures which you ship down to the  graphics processor, tell it to turn the crank and a whole bunch of answers come back. This  is a common approach now in if you need very, very fast computing. You get the graphics  processor, which is weird, isn't it? Do you have a good graphics processor on your machine?  Good. Then you can reduce, you know, invert matrices. You can do lots of calculation.  It doesn't do any graphics. We don't use the graphics processor for graphics anymore. We  use it for math, for computation. Oh, every once in a while we'll give it something to  render, but that's not its job anymore. Anybody got a laptop with more than one graphics  processor? And one of them is just used for sheer computation and the other one does all  the rendering? That's not uncommon either. So we've already gone down this route and  we're starting to develop these interesting strategies for trying to do this. Is there  a generalized way? I don't know. I don't think so. Maybe. So maybe the compiler guys will  figure something out. Maybe we won't have to think about it. Yeah, let's depend on that.  Anybody else with questions? Well, then thank you all for your attention. Nice to have you  all here. I hope now that you've digested your lunch, you'll actually be able to go  someplace and learn something.  Thank you.
Robert_C_0_13163.png Robert_C_13164_13247.png Robert_C_13248_13307.png Robert_C_13308_13391.png Robert_C_13392_13439.png Robert_C_13440_14207.png Robert_C_14208_14411.png Robert_C_14412_15731.png Robert_C_15732_16715.png Robert_C_16716_16799.png Robert_C_16800_17423.png Robert_C_17424_17975.png Robert_C_17976_18803.png Robert_C_18804_19847.png Robert_C_19848_20111.png Robert_C_20112_21095.png Robert_C_21096_22547.png Robert_C_22548_22619.png Robert_C_22620_22715.png Robert_C_22716_22799.png Robert_C_22800_29099.png Robert_C_29100_29195.png Robert_C_29196_32447.png Robert_C_32448_32615.png Robert_C_32616_32807.png Robert_C_32808_32867.png Robert_C_32868_32999.png Robert_C_33000_34007.png Robert_C_34008_34283.png Robert_C_34284_34583.png Robert_C_34584_34631.png Robert_C_34632_36851.png Robert_C_36852_36911.png Robert_C_36912_38099.png Robert_C_38100_38207.png Robert_C_38208_40919.png Robert_C_40920_41387.png Robert_C_41388_41627.png Robert_C_41628_41795.png Robert_C_41796_41843.png Robert_C_41844_41963.png Robert_C_41964_42203.png Robert_C_42204_42839.png Robert_C_42840_48311.png Robert_C_48312_48539.png Robert_C_48540_48587.png Robert_C_48588_51155.png Robert_C_51156_51659.png Robert_C_51660_51863.png Robert_C_51864_54839.png Robert_C_54840_55091.png Robert_C_55092_56483.png Robert_C_56484_57371.png Robert_C_57372_57431.png Robert_C_57432_63203.png Robert_C_63204_63383.png Robert_C_63384_66899.png Robert_C_66900_83778.png