Object-oriented programming has had its share of ideological controversies, but I take a pragmatic approach.

Indeed, my approach to object-oriented design and programming is quite simple, even a bit vague. To me, an object is just a value.

Now that may sound pretty trivial, but when you look at the history of programming, it was a powerful, even revolutionary idea. Its power comes from its generality. Values are not restricted to passive data items that can be encoded within a 64-bit register, but can be active and arbitrarily complex things: arrays, functions, windows, web servers. To me, the basic and most important idea of object-oriented design and programming is that we can create and manipulate these arbitrarily complex things just as easily as we can create and manipulate the simplest values, such as integers.

In some programming languages, we can't do that. When we can't, it's usually because some values aren't treated the same as other values. Even Java has that problem, but the problem is easier to see in languages that have that problem even worse than Java.

C++ does not treat all objects the same. The primitive values of C++ are much easier to work with than the other values. In fact, C++ has five fundamentally different kinds of values, with five different sets of rules for how they behave. The complicated kinds of values are much trickier than primitive values.

That is why I have never regarded C++ as an object-oriented language so much as an object-disoriented language: not all values are objects, and the objects are much harder to deal with than the non-objects. That's exactly the opposite of how it should be.

Java and C# also have this problem to some extent, but they aren't anywhere near as object-disoriented as C++. In Java, for example, there are only two fundamentally different kinds of values: reference values and primitive values. With one exception, all of Java's reference values are objects. The non-objects get in the way, and you have to learn special rules for dealing with them. Java's objects are easier to deal with than the non-objects, which is hardly ideal but represents an improvement over C++.

In purely object-oriented languages, such as Smalltalk, all values are objects. Every value can be stored in lists, returned by methods, and so on. There are no special rules for non-objects, because there aren't any non-objects.

My definition of what it means for a programming language to be object-oriented would count Scheme as an object-oriented language, and hardly anyone agrees with that. To fix that, we'll need a more complicated definition. Our next few lessons will introduce some of the technical ideas that appear in more complicated definitions of object-oriented programming.