This is the reason why I've come to agree that languages like C++, Java, etc. are not OO. When I've really looked at them I've come to the conclusion that they institutionalize the notion of abstract data types, as that concept is understood in CS. It's the idea that data should be in a structure, and the only way that structure gets modified is by a set of routines that will take that structure as input, but it's all a gentleman's agreement, though these languages try to make it less so, but they don't entirely succeed, because they allow the developer to insert "holes" into the structure, where it can be directly manipulated, or read, and it's possible to compromise the compiler's protections of objects, which compromises the object's design integrity. To get around some of that, to enable more flexibility in design, more abstraction, they introduced the idea of interfaces as a separate concept, and its adherents admonish programmers to "program to the interface." It's a "camel" of a concept ("an animal designed by committee") filled with compromises, and it's not as powerful as the idea Kay has.

What I discovered after programming for a while in Smalltalk is that it's a lot simpler, and more powerful, because you don't have all this junk that other languages require you to put in your code, cluttering up your design, and it's not based on the idea of abstract data types. Even though I'm using Smalltalk as an example, and I'm sometimes known for Smalltalk advocacy ( ), I am really making a language design argument. There's no such thing as an "interface" construct in Smalltalk, because you don't need it. The idea is built into how objects work in it. When you're dealing with an object, you're programming to the interface, not its implementation, because it won't allow you to get to an object's implementation!

Another thing that some so-called OO languages allow (maybe this is just in C++) is for the invoker of an object to control how the object behaves via. the type of the variable that holds the object instance. This also violates one of the principles that Kay has outlined, that an object must be totally in control of its own environment.

Even so, figuring out Smalltalk code that other people have written can be pretty challenging, because the functionality is not monolithic as it is in those other languages, but is spread all over the place in little bits and pieces. Methods are often very small, maybe 10 lines of code at most. People have expressed frustration about this, which I understand. Trying to do things in a Smalltalk system can be daunting, because it's difficult to know even where to begin to look. Getting to know a Smalltalk system might be like getting to know different services on the web, to make an analogy, getting to know who can do what for you, and there are LOTS of places to look. That's the one thing the web has that Smalltalk doesn't, an easy to comprehend search engine.