Bob Walker, Gemstone Systems: My name is Bob Walker, I'm from Gemstone Systems. I've been with Gemstone for about 10 years. I've been dealing with object-oriented systems for closer to 15 or so years, mostly business type systems. I was gonna start by making a joke but my dog ate my notes so I'm just gonna have to adhoc a little bit here. A lot of programmers seem to think that object-orientated programming started with Java. And that the OR impedance mismatch is something new. Guess what? It's not! I'd like to take a quick walk down memory lane, if you don't mind.
In late '80s and in the early '90s corporate systems were becoming more and more complicated. Software was starting to get very brittled, data was becoming very flawed, very inaccurate. A lot of redundancy in both the software and the data, I think we all pretty much know this litany. Enlightened information technologists had realized there is a serious problem. Waiting in the wings was object orientated analysis design and programming. What happened? Well, object-orientated programming came to the rescue by weigh of Visual Age Smalltalk, in many cases.
There are other Smalltalk dialects that had been in use of the time. I recall a 1990s something IBM putting the stamp of approval on Smalltalk for the corporate business world, and it was turning into quite a hot market. So Java isn't the first pass at OO that corporate fortune 1000 companies have taken. Visual Age thus gave the risk averse corporate IT staff a permission to start doing OO. People were talking about it as the next Cobol. Typically when the proof of concept is done it's taken on as a simple application -- this has been true of Smalltalk, this is true of Java.
The reason I talk about this, is that there is what I call a "complexity of progression." A first pass application is never taking on the most complex problems that a corporation is trying to solve. We're dealing with relatively simple data. What happens in the second pass? We start dealing with relatively complex data. The impedance mismatch problem: I'm not going to try to define it here, I think everybody here knows what it is. A search to rear its ugly head. As people were running into that, using Smalltalk in the '90s, they started using something that we liked to talk Multiuser Smalltalk or Persistence Smalltalk, which is Gemstone Smalltalk. Fundamentally this is an extension to the Smalltalk language that allows you transparent persistence. It's very, very simple: You just simply take your object, bind it into a name space, commit it and it's there for ever afterwards, the APIs are simple, programming is simple, you do it all in Smalltalk. The reason why I'm talking about this is because sometime ago Java happened. When Java happened a lot of the organizations kind of put the breaks on where they where with OO. "What's this new language? What's going on in here? Maybe we shouldn't invest so much in where we are. Let's put on the breaks and see where this is going".
I think now 10 years into the progression of Java we are at a place where mission critical, time critical applications are being implemented and have been for the last couple of years. They've reached a complexity threshold where the OR impedance mismatch problems were finally starting to show up. A lot of people who walked into going "Oh Java! It's OO! It's new! We can do lots here!" didn't realize at first that this was going to happen.
The long story short: You had expressed some interest, Bill, in languages that are extended with persistence. We've been doing that at Gemstone for practically 20 years. We know that it's possible, we know that it works. It's very simple, you don't have to have a relational database, you can use a relational database if you want to. My challenge to the team here, and to the people in the audience is to start thinking in terms of transparent persistence as a part of the language. We've been doing that. But I think that it can be improved across the board.