James Gosling was in Australia this week to give two question-and-answer session to local developers. A rare opportunity for local developers, Builder AU was on hand to transcribe the event for those who couldn't make it.
The following transcription was taken from the Sydney event on the 2nd February. Gosling talks about the deal between Microsoft and Sun, .NET security, the future of Java and the Java community process, competing IDEs, creationism, Standard Widget Toolkit and more.
If picked as a crew member of the mission to Mars, which would you prefer to have controlling and managing the rocket -- .NET, J2SE, J2EE, or Jini, and why?
I actually have been doing a lot of work over the years in the real time world, and once upon a time, I'd get people from the real time world, particularly folks from the really spooky end, like the people who do flight avionics, and they say -I'd like to do this in Java". And I'd say -I don't really think I'd like to get on your airplane". And then they'd say, -Do you want to know how we do it today?", and it was always much, much scarier.
It's a very different world where people think about reliability a lot differently. Java has this pretty terrific reputation for reliability and security and scalability and all these things. And folks from the embedded world have, for the longest time, just used (inaudible), and they're so damn conservative that they're having a hard time getting off of it, but on the other hand, the systems are getting so complicated that they're just falling over and dying, so we're actually doing a lot of work in that direction. But a Java-controlled system, properly tested, would probably make me feel a lot better.
What is your vision for Java five years from now?
What is my vision, ah, sometimes it doesn't bloody matter what my vision is! And that's one of the nice things with Java these days -- so much of it is controlled by the Java Community Process. People always ask, -What's coming next, what's coming next?", and if I could actually answer that question, there would be a little problem, because it would mean that there was actually a man behind the project who was driving it. And the way that the JCP works, it is very much controlled by the community. The next version, Mustang, we're still in the midst of a big food fight about what goes in the next release, and any and all of you can be involved. So where Java is going is kind of wherever the community takes it.
In general, we've been on this road for the last ten years or so, and a broad sweep is carrying on, it's been the big thing over the last ten years, and still, the continuing spread of digital systems, and communication to ever more exotic and interesting ways to get people to work together and collaborate together, with digital systems, whether it's automotive control, we've done a lot of work in the automotive world, and really it's a case of what electronics, what's going on in the world of media and digital systems. The recording industry and the Motion Picture Association have got no clue what they're doing. They're taking these industries that have got hundreds of years of standard practice and trying to figure out what it means when there are no borders.
A lot of what we're about as a community of developers here is about building systems that have no borders at all. One of the labels that has been used pretty often is the notion of ubiquitous computing - systems that interact in a very smooth and seamless way. I think one of the best examples, a beautiful system that sort of integrates everything, from J2EE to the embedded stuff to mobile desktop apps, is this gigantic system that lives down in Brazil, it's the operating software for the Brazilian national medical system. They record every patient interaction, whether it's an x-ray or a colonoscopy or a prescription or an EKG or whatever, it's all loaded into the database. And being the Brazilians, they're a little on the crazy side, it's home built, and you find these little embedded Linux boards, literally glued on to the side of x-ray machines. They take a lot of these machines that were never meant to be turned into web services, and they turn them into web services. So all of these things are web services, and they've got stacks of J2EE systems that are managing all the transaction processing and all the migration of the data out through the database. So it doesn't matter where you go, you just have your ID card and the doctor can look at your complete medical history.
When you get a prescription in Brazil, you don't get a little piece of paper with stuff scrawled on it, what you get is a database entry. So you go to the drugstore and give them your card and the prescription shows up. They say that the system has paid four or five times over, just in the reduction in drug costs. You go to most countries and they can't do that, because the politics of making it right is just too hard. I mean, the United States is just screwed, because the United States has become a Third World country when it comes to a lot of these things. The things that you can do once you can exploit the specificities between all the different systems that impact our lives are just huge.
As soon as you look at all these things and start connecting them up, you can find all kinds of surprising little stuff to do.
What is your opinion of today's popular scripting languages such as Perl and PHP? Not in terms of which is better up against Java, but more around their interesting syntax and other innovations they contribute.
A lot of them, when you (inaudible) in the community, what they get out of it is how compact the program can be, and often the program density and comprehensibility are inversely related. It's always funny to talk to people who are like real Perl freaks, because they love to make these magic pieces of Perl code, and there's no detectable flaws or anything in there, it's just randomly assembled characters, or it looks pretty random. It's a sort of -write once, never look at it again". Some of them are a lot more sensible than that. The Perl community is kind of a one edge, there's an old scripting language called Pico, which was much worse than Perl, I don't know if any of you remember Pico.
But it kind of depends on what you're doing; a lot of the folks in the scripting world, a lot of the justification of scripting stuff is that people are trying to get stuff together and running really quickly, and Java was optimised for getting things together and running really quickly, but what I was really trying to optimise for was not getting the first demo to run, but to get real production software to run. So I didn't really care so much about how long it took to get the first demo to run, but how long it took you to get to something you could actually release and call a solid piece of software. So Java's got a lot more stuff in it that's about upfront testing; things like static typing and the memory model and all that sort of stuff which, if you're just trying to do something really quick, actually kind of slows you down. But when you're actually deploying this stuff, you think, -I'm glad it's actually forced me to pay attention and think to go on with the exception mechanism", or whatever. And a lot of the scripting languages, because they're trying to be so fluid, actually don't have much in the way of structuring techniques; the interface and object-oriented methodologies aren't quite as well-developed or they often have barriers that are somewhat more porous, so it's easier to write small things and harder to write large things. And they're kind of well-developed in one way, they seem kind of -mix and match", so one of the things JSP 5 has is a series of facilities for being able to plug in to different scripting engines.
One question that people sometimes ask is, -When you're scripting in Java, why don't you put a scripting language in there?". And I don't think we'll ever put a scripting language into the platform model, but what we've got is a set of interfaces to the scripting system, so as soon as we would put some scripting system in, that would mean we would have to pick one. And there are quite a few interactive scripting systems that run in the Java world really well, things like Ruby and Jython, which are my two favourites these days. You could talk to people in the different communities, and they'll say -Well, why don't we make Ruby part of the basic platform?", and then the Jython guys come out with machetes.
The different scripting methodologies have different values and different contexts. One of the things that scripting languages get a lot of power out of is being fairly specialised. There's a scripting language that I'm sure almost none of you know anything about, which is a scripting language for controlling radio telescopes. It's a cool little system that you probably wouldn't think of.
If there was one thing you regret not including in Java from day one, what would it be?
Well, there are a bunch of things that I didn't do early on that are now really difficult, because there's this whole standards process. We've had lightweight objects I wish that I had done, and like 5 percent of the community would cheer, 40 percent would go -hmm", but a large faction would come after me with knives for saying -I wish I did operator overloading".
There are so many people that I talk to that feel victimised by the fact that -left shift" is not an IL operator. People get really emotional about it, but for people doing scientific programming, it's a big deal. So there's a collection of things like that. There had actually been a more sophisticated sort of precondition/postcondition system, briefly, that eventually got replaced by the current assertion system, and I kind of wish that the more advanced thing had been in there. I was trying to figure out what was the -right" thing to do, and there were a lot of opinions on the -right" thing to do, and one of the things that I wanted to do was to have the assertion system being interceptable, so you would just have, -what are the assertions required for this?", and then there would be symbolic algebra, as opposed to just having the assertion being strings or Boolean functions that you could press but you can't reason about.
There's actually a list of things that are kind of like that which would be great to do, but that are still like (inaudible) topics.
Can you elaborate any further on the agreements between Sun and Microsoft, and more importantly, what it means for the developer community?
Well, we're still trying to figure out what that agreement means. I mean, on some level it's actually meaning less and less, for sort of an odd reason. We have, all along, put a dramatic amount of effort into interoperability with various Microsoft platforms. We've put a lot of effort into the version of Java that runs on Windows, we've put a lot of effort into interoperability with all their protocols, and all their implementations of web services and stuff. We did a dramatic amount of stuff in our releases that's about making all those things interoperable.
What the agreement between Sun and Microsoft got us was the ability to use their proprietary specifications and take information from them, and use them to build our own stuff. They didn't give us the right to disclose that proprietary information of Microsoft, so we can get all the information from them about all the deep, dark secrets of how file systems work, but we can't then turn around and be members of the open source Samba project, and make Samba actually work. Because if we did, we'd have to disclose Microsoft's secrets, and they'd come out and shoot us. Or even worse, they'd send their lawyers.
So what we can do is we can delve into patented products, but we don't open source. Typical of what we've been trying to do are things which are sort of adaptors, that sort of match between the Microsoft way of doing things and the way that everybody else does things, like mail protocolsÃÂ¢Ã¢,Â¬"like how Exchange works versus the IMAP standard. The most active stuff we've been doing is around identity management, bringing a lot of the work from the Liberty work together with what Microsoft has done.
So all that stuff is happening, but our agreement with them is becoming sort of less and less relevant because of a lot of the antitrust actions in Europe, because Europe has actually been forcing Microsoft to open up those interfaces to everyone. Just recently they opened up the specification for the Office file formats, the schemas for Word and Excel, which, if any of you have been involved in any of those things for the last decade, the secrecy around those file formats is a way of managing locking, and the fact that they've just opened that up is just fabulous for people who want to build interoperable products. Certainly for some, who've put all this work into OpenOffice, we now have a legitimate way to build true interoperability.
In the past, the way you had to do it was by reverse engineering, and we got into kind of a pickle, because for open source projects, like Samba and OpenOffice, the only way to get the information is by reverse engineering. And for pretty much all the countries in the world, reverse engineering has been a perfectly fine thing to do. In the United States, this really vile law got passed some years ago called the Digital Millennium Copyright Act. One of the little nasties in the DMCA is that reverse engineering of some Digital Rights Management software is illegal.
So reverse engineering is legal for anything except stuff concerning Digital Rights Management. So what's been happening is that folks like Microsoft put Digital Rights Management into everything, and Digital Rights Management into places where you wouldn't have thought that DRM would make a whole lot of sense. So that whole document format was getting wrapped in DRM stuff. And there are moderately plausible arguments you can make for why DRM is useful on some of these things, but under the sheets, the major justification is to make reverse engineering illegal. That's actually in the DVD case, that's a big piece of what they care about, the DTSS encryption stuff, and it's like the world's sloppiest encryption protocol, it's really stupid. Its only real purpose in life is to tie-in decoding to contracts you have to sign in order to be legal.
So Microsoft is becoming surprisingly more open about things, which is nice. So much of what Sun does is very open. We've been distributing the whole process of editing in the Java world for like the last decade, and it's meant that we've had to be extremely careful about IP rights, so that we actually have the rights to open it up and put it out there. Microsoft don't do that.
What is your opinion of Standard Widget Toolkit (SWT)?
The SWT thing was just...it pissed me off beyond words. So, if you wind back the clock a few years, the original toolkit in Java was this thing called AWT, the Abstract Window Toolkit. It's still there, and it's a fairly simple, straightforward toolkit, and it's based on using the widgets from the underlying (inaudible). It had a wide variety of really, really ugly problems, things like how to get semantics consistent from platform to platform, and some of the little fringe things like cut and paste. Trying to get cut and paste to operate correctly between text widgets, like between the Mac text widgets, the Motif text widgets and the Windows text widgets. When you're actually trying to use those text widgets in their native homes, it's just a nightmare. How do you deal with things like subcopying, how do you make a button extensible? How do you deal with the more advanced features that people want, like being able to do tables where you can control the rendering of components and cells and that kind of stuff?
A lot of those things were completely precluded by the AWT architecture. IBM in particular was really upset about the way that the AWT architecture had gone, and they were one of the leading agitators that caused Flame to be created. In fact, about half of the engineers on the Flame team were actually from IBM -- they actually got IBM pay cheques. IBM built Apple Flame, and actually then Swing was quite successful, it's been successful for quite a while. The biggest problem with Swing was that it can do so much that it's kind of become like the 747 cockpit if you like APIs. There's a lot of complexity there, and the hard part is figuring out how to use it. It's in this weird situation where pretty much anything you can want to do in Swing, you can do easily. But what's hard is to figure out the easy path through all of the different options, the different ways you can do things. Once you figure out the one true path to get what you want done, then it's pretty easy. People often say -Why don't you just make it easier by simplifying it?", and say, -so you simplify it in this way, it would make my life better". But then for the next guy it would be worse, because he wants to not go there, he wants to go on this particular path. So it's been difficult to manage the complexity right.
So, wind the clock forward a few years, and there's (inaudible) from IBM (inaudible) -Swing is too complicated, let's do AWT all over again", and if you look at the SWT architecture, it's almost exactly the same as AWT. It has all the AWT problems: it's way simple, it doesn't port very well. And its API is somewhat different, because essentially what they did was they made the Windows version really easy by making their API pretty much a clone of the Windows API. And then on Linux, they tried to make Motif look like the Windows toolkit. They've got those mapping layers that are just like, really horrible, and it only kind of works. And same thing in OS X, their porting problems from platform to platform is a nightmare, their consistency (inaudible) is a nightmare. And it's sort of like, -You were there seven or eight years ago. It was a bad place to be, don't go back!". The problem is that IBM is like three hundred and some-odd thousand people, so there's like a cluster of people. Most of the people we were working with back then were in North Carolina and New York State, like Westchester, and they actually understood things pretty well.
What's your opinion of SCO's claims to what's inside Linux?
Uh...I want some of what they're smoking. The world was so filled with really, really goofy court cases, and SCO were so strange about it, actually refusing to publicly disclose what they think is violating their stuff. Or the things that they disclose become sort of non-existent. And all of the items, the -who owns what". I think they're silly, just a bunch of lawyers collecting fees. I don't think there's actually a rational anything anywhere in there, I mean it's just really nutty.
The really significant part of that though, is that so much of the world has gotten tied up in knots over ridiculous pieces of litigation. I mean, Sun just came out of this really weird patent case with Kodak, where Kodak admitted that we did not violate their patent. They weren't accusing us of violating their patent, they were accusing us of building a system that caused other people to violate their patent. So they had an expert who wrote software that violated their patent, and he actually got up in court and said that every program ever written does the following completely stupid stuff, and therefore Java induced people to violate their patent. And the jury made up of housewives bought it. And it's like, -What is this, you know, Shakespeare with rights? It's like five hundred years later, why didn't we pay attention and just shoot all the lawyers?".
I noticed that the current development stream for 4.1, doesn't offer any OS X builds.
I run 4.1 on my Powerbook. The right people have to press the right buttons to get the builds to come out in the right script. We certainly push everything out in OS X compatible builds. And it's sort of a funny thing, where the piece of software actually runs perfectly fine on OS X, usually the thing that's weird is getting the install scripts right.
I mean, typically what I do is I take a Linux install and just run it on OS X, and that usually works just fine. And you can do that with random other things. But I think for 4.1, I actually installed that from a real OS X install, and I don't know whether that's actually pushed out to the web or not.
The final version of 4.1 will absolutely support OS X.
Most of the developer tools we have will run properly on (inaudible), which is a surprising piece of stubborn engineering, given that (inaudible) supports all of the JSP 5 features, like generics. There was a little bit of (inaudible) that happened to get all that to work on 1.4. But Apple tends to be a very difficult company to work with. On the one hand, they do lovely stuff, on the other hand, their corporate secrecy is just mind-numbing, and to have to work with them on an engineering level is very, very difficult. We don't have like a special relationship with them where we get early access versions of their (inaudible) work. In fact, the current, 1.4, is a lot shakier than it ought to be, and if you join the Apple developer program and you pay them enough money, you start getting early releases of Tiger, which I do. I'm not actually allowed to say anything about the fact that it's flaking.
What kinds of pet projects are you pursuing these days? What gets you fired up in terms of -oh yeah, I want to be involved in that kind of process"?
Well, I've been doing a lot of stuff with the tools folks, and taking some of the refactoring stuff that I was working on a couple of years ago. I've been spending an awful lot of time with people doing realtime software, and the embedded world. And the embedded world is really fascinating, like in cell phones. Java in cell phones is a little strange right now, because the Java VM kind of sits on top of the rest of the cell phone, and the guts of the rest of the cell phone. There is no kind way to express the software architecture at the moment in a cell phone, it's unbelievable when you go and talk to companies like Motorola and Nokia, and you ask them -How long does it take you to do the cell phone mode; if you develop a new cell phone, how much software engineering goes into it?". The numbers tend to hover around a thousand man years per cell phone. It's astonishing numbers, and you look at the way that they sort of layer things and it just gets unbelievable. And they know that it's stupid.
And the question earlier on about whether I'd try anything with Java software in it, when you look at the standard practice of a lot of those worlds is just scary. So we've been working with a bunch of folks, trying to build these things in a lot more intellectually defensible fashion, that cope with things like evolution and flexibility in much better ways. So we've got folks who are pushing for the Java layer all the way down to the metal. I was visiting Siemens just before Christmas -- they're the company who did the software for the BMW iDrive -- I don't know if any of you have seen the BMW iDrive, but it's this onboard electronic package that's kind of boring unless you buy like every possible BMW option. They've got this sort of knob and this screen, and most of the world's automotive experts just look at this sort of knob and they way that they hooked up this menu and go -That's way too Germanic". But the architecture for it was like 99.5 percent Java code to do all the networking stuff and all the UI stuff and all the graphics. But there's some low-level, operating system level kind of stuff that they did in C code, and the thing has been shipped for about a year now, and they've done a lot of analysis of where all these problems are, and it's all in like the bottom ten percent, and they're trying to get all that stuff out of there, because people have been building systems where you don't have boundaries, it just goes all the way down to the silicon. And the numbers that the businesspeople get are really nice in terms of how efficient they are, how reliable they are.
We've got one little project in Sun Labs, it's a Java-based OS called Squawk, and it's also tied to a special VM for like really, really tiny machines, sort of on the same scale as the Smartcard, only more intelligent. So we have these boards that we've been building in low-ish volume. We're hoping actually to have these available to distribute at JavaOne. But these boards that we have fabricated now are about a square inch. By JavaOne, we hope to have them about the size of your thumbnail. It's a board that's got a CPU, a sensor, and there's like fifteen or twenty different sensors that we can actually put on these boards and start networking. And it's got its own little OS for mesh-rubbing networking. So you can take these things and build meshes with these tiny little sensors. One of the tragedies is that they need a battery, and the battery is way bigger than this machine. One of the groups that we're doing work with, they've doing these strain gauges on these things, and they just, load them on the side of the bridge and it forms a sort of mesh net to get the data from the whole bridge. So they can measure what's happening on the bridge, how the bridge sways and moves in a really detailed way, and then get that data out and sort of integrate and analyse it. I think that's way cool.
Does Sun ever intend to become like .NET, so you can have lots of languages that can plug into Virtual Machine?
Well, we did have lots of languages that compiled on to Virtual Machine, there are literally hundreds of them out there. The comment that I made about not doing a scripting language is not that we didn't want to do a scripting language, but that we didn't want to pick one and call it -the scripting language". It's actually pretty cool that there are quite a few scripting language-like things out there that work in the Java world very nicely. I think it would be a tragedy for us to say, -Ruby is the one true way, all of you Jython guys go jump in the lake".
The issue between us and .NET about supporting multiple languages is not so much a philosophical question of supporting multiple languages. The design of the Java Virtual Machine is used to all kinds of languages. The question is, how broad is the set of all possible languages that you can implement on top of them? The Java Virtual Machine Specification has some constraints, and the constraints are mostly about the integrity of the memory model, and the integrity of interfaces.
I felt very strongly early on, and still feel very strongly. The Microsoft folks made a big deal of being able to support C and C++ on the CLR, and that, to my mind, is one of the stupidest, most offensive things they could have done. What it meant was that they had to have a Virtual Machine model that would allow arbitrary pointer arithmetic, and sort of arbitrary forging of the identity of things. So C++ allowed you to do arbitrary casting, arbitrary adding of images, pointers, and converting them back and forth between pointers in a very, very unstructured way.
If you look at the security model in Java and the reliability model, and a lot of things in the exception handling, they depend really critically on the fact that there is some integrity to the properties of objects. So if somebody gives you an object and says, -This is an image", then it is an image. It's not like a pointer to a stream, where it just casts an image.
They decided that they needed to be able to support C and C++, and they make a big deal of the fact that they support C and C++. But what they don't talk about very much is that their support of C and C++ creates a security hole big enough to drive many, many large trucks through.
Java can support a very wide range of languages, consistent with or bounded by the tight memory model integrity. Languages like C and C++ don't work.
Do you think that the JVM architecture will ever change?
The registered base Virtual Machine is far more efficient if what you're going to do is interpret, and if all of your machines have similar register structures. When your registered base Virtual Machine has a register structure that is too different from the register structure of the actual machine, you start getting into real problems.
The thing about the stack-based VM design in Java is that people tend to look at it, in fact they describe it in the documentation, as something that you interpret. It's expressed that way, as just a way to write down the semantics.
For the purpose of doing high-performance versions of the VM, a better way to think about the JVM design is that it's a (inaudible) encoded (inaudible) of the (inaudible). So you can actually construct the (inaudible) by doing a symbolic execution of the instructions.
One of the really great things that comes out of the stack base things is the fact that you can pick out a stack (inaudible) of the ways to do register assignments. But it's also coupled with a simple sort of (inaudible) analysis, because you know when something has popped up, it becomes dead.
The definition of the way stack works in the JVM set is that it has some peculiar little tricks in it that are actually deeply important. There are some parts in the stack that talk about the state of the stack around control flow operations. In particular, when you've got a join -- when two flow paths come together -- the stack state on both of them, not in terms of the values on the stack, but the depths of the stack, and the types of all the entries on the stack, must be identical, and it must be statically provable to be identical. What that means is that then the stack becomes a way to assign register numbers fairly arbitrarily.
There actually was a really early version of the Java VM that nobody but me saw, that was based on registers. But after playing with it for a while, I decided that it was like a really bad idea.
Ten years ago, when Java was first being talked about, one of the main plans was for it to run anywhere, from toasters to videotape recorders. Ten years down the track, we don't see very much Java in general consumer devices. Was that a naive vision to have at the time, or is it just still too early to be taking off?
It sort of depends on what consumer devices you look at. If you look at telephones, it's in everything. It's actually gotten hard to buy a cell phone that doesn't have a Java VM in it. The other parts, like toasters...I would be engaging in hyperbole if I talked about toasters. But those industries often move really, really, really slowly. They only do things when they discover that they actually need them and they're really cost-effective. And it's actually only been recently that with CPUs with interesting performance were cheap enough that you could actually put them in the toasters. I don't know if anybody is doing anything interesting with toasters.
There's a huge amount of fascinating stuff going on in auto fields right now. I spend a lot of time with people who do electronics for automobiles, and the next five years is going to be just fascinating. Some of the stuff is just very cool.
Do you see Java being a fundamental core component of nanotechnology?
Well, it depends on what you call nanotechnology. Some of those things are very strange. There's the kind of small robotics, and the little mesh processors that Sun Labs is building are pointed in that direction. It's one of these areas where nanotechnology and quantum computing kind of slam together, because they end up with a really different computational model.
Some of the nanotech state processing solutions have CPU-like things that are not even vaguely (inaudible) architecture. Some of them are pretty fascinating, and you try to figure out what to do with them. I can remember taking one of my developing courses an embarrassing number of years ago, and one of the assignments was to come up with an architecture where you could prove the P = MP. And nobody, of course, got the answer. The professor, it was his research field, and he had had this sort of -a-ha" moment the night before. So we spent a couple of weeks on soap bubbles, because you can use soap bubbles to compute in stack trace. So if your computational engine is soap bubbles, you can prove that P = MP. And that's pretty fascinating, if you've all of a sudden got a CPU architecture for people to see, and the encryption options get really interesting. And how do you deal with an encryption out of soap bubbles? Whether it's theoretically possible, I have no idea.
That's the kind of place where it can get really interesting -- how do you read without a computation in things that are just that different? That's a lot of the stuff that people are doing in nanotechnology. It's one of those words that gets applied to everything -- if it's small, it's nanotechnology. So Texas Instruments' digital light processor chips are these tiny little micro-mirrors on the surface of the chip, and they steer these mirrors to build video projectors, that's a DLP projector. Many people would call that an example of nanotechnology, but that's one where it's nanotechnology to accomplish an interaction in the physical world, but the actual computation that goes on behind it is completely ordinary. And a lot of stuff that people do these days is kind of like that, like people have done these nanotech gas sensors, so on the chip there's gas sensors or bio sensors.
In the next ten years, what do you think the desktop operating system should be, and what would be the role of Java in that?
If, ten years from now, the dominance of Windows desktops dipped below 90 percent, I would be shocked as hell. And I think focusing on desktops is probably the wrong question. It's more like, -Where will people do desktop-like things in the evolving world?". So if you look at your cell phones today, you've got about as much CPU horsepower as your desktop computer of like six or seven years ago. And actually, if you count the DSP, it's actually got more, it's just not usable.
If you look at what people have been doing with PDAs and so forth. More and more, what people think of as desktop... we are drifting towards these odd and unusual formats. And the big challenge is how to deal with user experience, if you don't have a big screen on a telephone. But there are phones that people have made with DLP chips in them, and they actually project a big screen -- you can put your cell phone down on the table and they actually project on the wall. People can build them like that and they work just fine, but the battery's dead in about five minutes.
A lot of these things are driven by various technology curves that have been moving so quickly, like what's happening in the networking world. But there are some things that are moving really slowly, like batteries are only improving by about five to eight percent per year.
One of the most important ones in terms of cell phones is that the end of my finger can not get that much smaller. And if you go back through the last several thousand years, people's figures are pretty much a constant size. So if you've got interaction through your fingertips, they're not going to shrink a whole lot. There is a medical term for the way your thumb gets screwed up when you use the keypad on a cell phone for the SMS messaging, when you do too much of it. There is a very specialised form of RSI, which is what happens to your thumb on a cell phone, and I don't remember what it is, it's a very bizarre name. But it shows how technology's evolved. One of the great hopes that people from the cell phone world have is all about speech technology. For something like a cell phone, the whole power of these things is that they can get CPUs in a cell phone that do a decent job of speech understanding, but they can't actually power them for very long.
Modern cars, like the current generation of Lexus, go to a Lexus dealership and just try them on, they've got a voice recognition system and it's actually pretty good. It's one of the better independent, modern vocabulary voice recognition units around. What happens when people do that on sensibly priced cars or blenders, or maybe not the toasters, but...if you could just walk up and say -margarita, please". Like in a Lexus, you can get in the car and say -go home", and the GPS system just does the right thing.
Have you used Eclipse and IntelliJ and what do you think of them? Also, on your bio page, you write about religion and evolution, could you elaborate on that?
Um, I actually put that up long ago enough that I don't remember it. In general, it is pretty cool to read lots of stuff in the sort of biological literature, at least the popular fiction versions of it.
That particular -memo from God" thing [in the Sun page bio] was all about how unbelievably braindead people can be in their attitudes towards science. I didn't actually write that, that was something that I found on the net, and thought it was just quite brilliant. But the US has become such a repulsive place to be, and shortly after the election there was this map of North America that got really popular, with the blue states and the red states.
You get people, this sort of Jesusland crowd, these creationists who have pictures of dinosaurs, and they use dinosaurs as evidence of creationism through completely bizarre arguments. The risk here is that the people writing these books don't think of it as a comedy. Trying to figure out, and trying to communicate the truth, and get people to be sensible about things is so damn hard. The fact that in one of the American states, for quite a few years, the value of pi was legislated to be three. You don't get to pick what truth is. One of the things about science is that it's about finding out what truth is. You don't get to pick the value of pi. It's about as bad as picking the story of creation.
There's another set of books that is actually a series by the guy who was the chief librarian in the library of Congress. He wrote one called The Discoverers, a big honking thick book filled with all this stuff, these really bizarre stories that you hardly believe are actually true. Like one of the Pope's commissioners did an analysis of the Bible to generate a map of the Mediterranean. So there was this map of the Mediterranean that was sanctioned by the Catholic Church, and any other map of the Mediterranean was something you could be executed for. So this turned into a big problem for sailors, because the Pope's map of the Mediterranean couldn't actually correspond with the actual Mediterranean. I don't care what you believe about the Bible; the Mediterranean is shaped the way the Mediterranean is! You don't get to choose, you can describe it; it is what it is.
So back to the real religious question, have you used Eclipse or IntelliJ?
I like to use both of them a little bit, I can't say I've used them a lot. Eclipse is sort of weird, because they created the Eclipse open source project about a year after NetBeans came out as an open source project. And I wasn't really compelled to switch. The awkward thing about Eclipse was the whole SWT thing, but otherwise, it's a reasonably decent IDE. I'm actually really glad that they're there, because a world in which there was only one IDE would be really depressing.
This is one place where sports analogies really work. On the one hand, I want to beat the crap out of the other team, but if there was only one team in the world, it would be really boring. A hockey game needs two teams. Our goal is to beat the crap out of them, but that's more a matter of entertainment.