We are at RSCC 2008 in Orlando, Florida. We have another special guest. Would you like to introduce yourself? No. Yes, I will, of course. Sorry, it's been a really long week. I imagine so. I'm starting to feel the fatigue myself. Hi, I'm Grady. What is my title these days? So I'm an IBM fellow, which means I'm kind of a free radical. That's right. And I moved over to IBM Research, and so my official title is Chief Scientist of Software Engineering for IBM Research, which basically means I keep doing the same thing I've been doing the last multiple years anyway. Absolutely. I see why you gravitate towards more of a homegrown title like Free Radical. Free Radical, yeah. It's much faster to say. Exactly. Well, when Nick D'Onofrio told me I was to be a fellow, he said, "Grady, you've got two jobs. Invent the future and destroy bureaucracy." That's a great job. So we were just in a meeting with a bunch of analysts, which there was some exciting conversation there. And one of the things I wanted to ask you about, because you've mentioned it several times, was to, everyone seems to be sort of freaking out about multi-core stuff. And, you know, first off, I mean, what do you think, where's that freaking out coming from? Like, what's the motivation for it? I mean, it almost seems to be, it's sort of like a Y2K level of like, things are going to fall down. Like, get your water now. I think the freaking out bit, much of the fear comes from simply the fear of the unknown. People do see a cliff they're about to either jump across or fall down. And that cliff being the end of the frequency scaling wars. It's quite clear that we're getting to the point in the foreseeable generation that we really can't push our processors that much faster or make them that much smaller. As I spoke about in my keynote the other day, you know, right now you can put a transistor within about a hundred atoms by ten atoms. And we see the technology ahead of us where we can push it down to one transistor for every ten atoms. Once you start getting to that point, which is not going to be that far away, you run across quantum effects, which we're actually starting to see already, as well as problems of heat dissipation. And so when you get to that,
2:01you just can't pump these things any faster. And that means we see a tailing off of the available computational cycles. You know, Vista version 25, it's probably not going to run on our existing processors. We won't comment about the current version of Vista, but that's another story unto itself. So as you look at that cliff and say, hmm, I'm going to reach a plateau of computational cycles, yet I'm doing so many things to eat those cycles. Things like, you know, XML eats a lot of cycles. That's why we see specialized coprocessors for it. Just the fact that I have more transactions I need to push out all the time. The fact that I'm processing so much more data. I spoke of the trends in the storage of the fact that we'll see things like racetrack memory, which will push us to around perhaps 20,000 gigabytes per square inch. And once you have that amount of storage, it requires a whole lot of processing. And people are therefore fearful of saying, hmm, how do I take my applications and move them to this more intimately concurrent model? Right. We don't have the people that know how to do it. We don't have the tools to do it. We don't have the processes. There's a tremendous fear of the unknown. For a long time sort of software, sort of led hardware, if you will. Yeah. But it seems like the fear here is that the hardware people have come up with something that's way ahead of the software people's abilities, which is -- and so the machines that people will be writing software for, they're not really used to that kind of thing, and there's not -- there won't be another option. There won't be another option. Right. This is an irreversible trend. And the organizations that have been hit with this first are the gaming communities, because the current generation of game consoles, the PlayStation 3 and the current Xbox and all this, are all based upon the cell processor, which is an 8-way asymmetric processor. So this is a community that, for a variety of reasons, has been pushed in the direction. They eat a lot of cycles, and they're the first ones to face the problems of multi-core development. And there will be others who are not far behind them. Another factor that's pushing people in this direction is the sheer energy costs. That having a server farm, a data center, that has, you know, tens of thousands of servers, generates a lot of heat and
4:02eats a lot of cash in terms of energy. So there are opportunities for actually, you know, greener computing as you move to multi-core as well, and that economics will push people in that direction. Yet again, we're not, you know, well suited as an industry to know how to deal with this. Is it languages? Is it just algorithmic skills? Is it pattern libraries? Is it pushing into the middleware or compilers? Right. Probably all four of those things. You know what I mean? It makes me think of another interesting question. I mean, what's sort of the, like we were talking about people won't know how to deal with this and so forth and so on, but what do you think the baseline is of what we do know how to deal with as software developers? I mean, not to ask an impossible to answer question. The common mediocrity is we know how to bang rocks together. Right, right, right, right. Well, you're asking a question like how does one make sausage? You really don't want to know the answer to that question. You know, the web has led us to the point where a large amount of the community is really comfortable with programming in the presence of relatively loose concurrency. Right. And modest, you know, time kind of requirements. In most of the things we do, the delays of the web transactions themselves are overwhelmed or actually overwhelm the amount of computation that goes on. Yeah. So we have, you know, we have some sloppiness there. And to some degree, the amount of computational cycles we have in this abundance of bandwidth and abundance of storage has enabled us to be very sloppy. Right. And the problem is with the end of the frequency scaling war is we can't be as sloppy and that's what's scaring people. Yeah, that is interesting that there does seem to be the web introduced, like you're saying, sloppy programming. I mean, it worked, right? It works. And now it seems like there's a challenge of maybe we have to get back to more precise programming to pick some adjective that's, you know, anonym for sloppy. Right. And, well, I don't mean sloppy in a pejorative fashion either. Sure, sure. Absolutely. It just means one can be loose. Right. And in fact, if you do any studies of systems works, there's a delightful work by Herbert Simon in his book, The Science of the Artificial,
6:04in which he talks about resilient systems tend to be loosely coupled systems. And that's one of the reasons why I think the web succeeds so well, because it is a good example of those kinds of systems. And yet, as you start finding greater constraints, in this case, you know, fewer computational cycles and unit processors, then that changes the perspective for us. And that's what's scaring people. Right, right. Yeah, that makes sense. And it's not that we have to become, you know, more precise. Well, we do have to become more precise, just less loose. Google's a good example in this and they've, you know, invested a lot in intimately concurrent systems. They love multi-core systems because they have a problem that's easily optimizable to that point. That there is a tremendous amount of natural concurrency that goes on within the Google problem domain. The difficulty is that there is not so much natural concurrency that exists in your average enterprise transactional system. Right, right. So the last question I was interested in saying, and another thing that you talked about in the little conversation or the, I always think it's funny they call it a round table, but we're here at a rectangular table. We're at a rectangular table, yes. At the rectangular table discussion. Was, you were talking about how when you had done the initial work with UML, you weren't intending it for it to be a programming language. Or even if I can, like, maybe put words in your mouth, sort of a direct way of, I don't know how you would, whatever, model-driven programming. And I wonder, I mean, you didn't necessarily allude to what you're thinking of that is nowadays. And I'm curious, like, what you think of the idea of something other than typing in, you know, the language that you're doing when you're coding. Sure. Well, the notion of domain-specific languages is, I think, what you're alluding to. I believe it to be the case, and I've always felt this, that the UML is quite suitable as an execution language for certain narrow domains for which the semantics are well-defined and the platform is well-defined. That's why UML, in terms of model-driven development, has gotten traction in the embedded space where state machine semantics are very, very well understood. As you start moving toward more difficult domains like business engineering, well, there's the whole BPEL versus UML controversy.
8:08I always thought that was kind of curious because I found the UML semantics to be quite sufficient to express business rules. It was just different than what that culture normally expected. The difficulty there in using the UML as a direct execution language is we don't have control over the platform against which this runs. Those platforms are so complex and so heterogeneous. You may be able to do it for specific instances, but to have a generalized solution is very, very difficult indeed. That's why I find, and I've always found, greater power in UML simply being a language to use to reason about systems that transcend the code. The code's the truth, but it's not the whole truth, and we need to understand that truth through other means of visualization, and that's what I always intended the UML to be. Hearing you talk also always reminds me I need to say the UML. The UML. Not just UML. That's right. It's always a subtle distinction. That's right. In fact, a little quick story at the end here. The February 22nd episode 2007 of the CBS show Numbers. Did you see that clip? No, no, no. Okay, so this is a great one. So the premise of Numbers is you've got this genius mathematician, his cop brother, and the genius mathematician comes in and helps him solve crimes through scientific means. Well, the February episode then was one called 24 in which there was a kidnapper, and this kidnapper is leaving clues behind. So the genius brother says, "Oh, this is just like a state machine." So he's sitting around talking with all his interns, and somebody says, "Oh, yeah, we could model it like a state machine." And the genius guy says, "Using the unified modeling language." Blew me away to see a pop culture thing happen. Absolutely. But I was pleased to see they properly put the article V in front of it. That's right. It's even Hollywood knows. Even Hollywood knows. That's right. Absolutely. Well, great. Well, thanks for taking the time to talk with us today. I appreciate it. Thank you.