I'm still seething over a lecture I had last week, which proclaimed that Java is "the example of an object-oriented language". Perhaps, if your only experience of programming is BASIC and C, and are completely ignorant of the history of the term 'object-oriented' or even its true meaning. Then again, what do I expect? We were taught UML the week before - nothing says "mediocre creativity-devoid engineer" more than a codified system for drawing stick figures and circles in the right places.
There's a pretty good example of an object-oriented language that existed 20 years before the development of 'Oak' (which, incidentally, was a far more descriptive name than Java - it grows incredibly slowly into a huge behemoth of source code, it's barely pliable, and has many branches making up the 'standard library', several of them very rotten a.k.a. 'deprecated'). Some might even call it the canonical example.
That object-oriented language is called Smalltalk. You may have heard of it. It came from the great computer idea factory called Xerox PARC, and is notable for being one of the few concepts Apple didn't steal outright. Its designer, Alan Kay, coined the term 'object-oriented programming'. In this language, everything is an object, and there is no concept of integral types (not strictly an issue in Java due to boxing, but this only serves to increase the confusion in that language). An object's state is completely private to the object, and all communication is done via message-passing - you might know this as a 'method call'. OK, not a big difference, right?
There was one odious example given in our lecture, that of a 'Money' class, and summing several amounts of Money. One wrong approach was to implement a 'getAmount' method and use that to sum, which breaks if you change the type used to represent amounts, say, from double to int. This is a problem with explicit typing, in fact - any language that features generic programming concepts like Lisp, Haskell, even C++ if you are careful, wouldn't give a damn about that. The 'correct' solution to this problem, at least in the backwards world of Java, is to create an 'add' method of the Money class and use that instead. Congratulations, you've just created a competing and incompatible solution to the already-well-known semantics of adding two things, namely the + operator, because operator overloading was made impossible. Then again, the semantics of + were already broken by string concatenation, so even a generic 'sum' function would be flawed.
It's not as if the alternatives are a bed of roses, though. Alan Kay himself has said that Smalltalk was not the language he had intended it to be, instead longing for a more organic approach to software.
The problem with object-oriented design in its current incarnation is a problem with how we reason with the world. We think of verbs and nouns, not of the processes involved, and when placed in a system like Java - a system that insists, nay, demands that everything you do belongs to a class (or an XML file, if you're unlucky) - that's all you think of. Nouns. Nouns that contain other nouns and verbs which let you interact with the nouns so that other nouns aren't tightly coupled with your nouns and verbs that kinda don't belong to the noun but you haven't got a better noun to put it and oh god now we need a VisitorMediatorFactory because the type system and single dispatch won't let us do things in an obvious way.
The question is, what is the right way to do this? Going back to Alan Kay, and after watching his keynote speech at OOPSLA '97 we can see his idea for a more biological approach. What is crazy from my perspective is that earlier Smalltalk versions are far truer to his idea of independently-operating, self-contained biological agents, or actors, than Smalltalk-80's thinly-veiled subroutine calls. Why the change?
One thing I can be grateful to Java for is that its takeup by industry has provided us with a rather robust, widely-available and well-tested VM, and one that other people can design their own languages for. Having examined a lot of the emerging languages, Scala seems to be an interesting mix of object-orientedness, functional programming and the actor model, and looking at the examples provided, I am sorely tempted to give it a go for my next games project. Alternatively, I could just say 'screw it' and use Lisp/Clojure instead, saving me the trouble of Greenspunning further down the road.
However, the only way to see if an approach really works in practice is to try it for yourself. Computer science would benefit so much more from analyses of large-scale projects, their design weaknesses, potential solutions for these problems and the impact it would have on the other parts of the design. Maybe this has been done already. But unfortunately, in the real world we have to deal with mediocre programmers on large projects somehow, and I fear that all the will in the world won't improve that particular problem. Just ladlefuls of Java and UML, and weird cultish methodologies designed to prod drones into working well rather than improving the field outright. Sighhhhhhhh.
Anyway, the point is, this is not the kind of thing a top-ten university should teach. It is quite telling that process is described in far more detail than how to create a good design, although what it tells me I don't yet know. One day...
There's a pretty good example of an object-oriented language that existed 20 years before the development of 'Oak' (which, incidentally, was a far more descriptive name than Java - it grows incredibly slowly into a huge behemoth of source code, it's barely pliable, and has many branches making up the 'standard library', several of them very rotten a.k.a. 'deprecated'). Some might even call it the canonical example.
That object-oriented language is called Smalltalk. You may have heard of it. It came from the great computer idea factory called Xerox PARC, and is notable for being one of the few concepts Apple didn't steal outright. Its designer, Alan Kay, coined the term 'object-oriented programming'. In this language, everything is an object, and there is no concept of integral types (not strictly an issue in Java due to boxing, but this only serves to increase the confusion in that language). An object's state is completely private to the object, and all communication is done via message-passing - you might know this as a 'method call'. OK, not a big difference, right?
There was one odious example given in our lecture, that of a 'Money' class, and summing several amounts of Money. One wrong approach was to implement a 'getAmount' method and use that to sum, which breaks if you change the type used to represent amounts, say, from double to int. This is a problem with explicit typing, in fact - any language that features generic programming concepts like Lisp, Haskell, even C++ if you are careful, wouldn't give a damn about that. The 'correct' solution to this problem, at least in the backwards world of Java, is to create an 'add' method of the Money class and use that instead. Congratulations, you've just created a competing and incompatible solution to the already-well-known semantics of adding two things, namely the + operator, because operator overloading was made impossible. Then again, the semantics of + were already broken by string concatenation, so even a generic 'sum' function would be flawed.
It's not as if the alternatives are a bed of roses, though. Alan Kay himself has said that Smalltalk was not the language he had intended it to be, instead longing for a more organic approach to software.
The problem with object-oriented design in its current incarnation is a problem with how we reason with the world. We think of verbs and nouns, not of the processes involved, and when placed in a system like Java - a system that insists, nay, demands that everything you do belongs to a class (or an XML file, if you're unlucky) - that's all you think of. Nouns. Nouns that contain other nouns and verbs which let you interact with the nouns so that other nouns aren't tightly coupled with your nouns and verbs that kinda don't belong to the noun but you haven't got a better noun to put it and oh god now we need a VisitorMediatorFactory because the type system and single dispatch won't let us do things in an obvious way.
The question is, what is the right way to do this? Going back to Alan Kay, and after watching his keynote speech at OOPSLA '97 we can see his idea for a more biological approach. What is crazy from my perspective is that earlier Smalltalk versions are far truer to his idea of independently-operating, self-contained biological agents, or actors, than Smalltalk-80's thinly-veiled subroutine calls. Why the change?
One thing I can be grateful to Java for is that its takeup by industry has provided us with a rather robust, widely-available and well-tested VM, and one that other people can design their own languages for. Having examined a lot of the emerging languages, Scala seems to be an interesting mix of object-orientedness, functional programming and the actor model, and looking at the examples provided, I am sorely tempted to give it a go for my next games project. Alternatively, I could just say 'screw it' and use Lisp/Clojure instead, saving me the trouble of Greenspunning further down the road.
However, the only way to see if an approach really works in practice is to try it for yourself. Computer science would benefit so much more from analyses of large-scale projects, their design weaknesses, potential solutions for these problems and the impact it would have on the other parts of the design. Maybe this has been done already. But unfortunately, in the real world we have to deal with mediocre programmers on large projects somehow, and I fear that all the will in the world won't improve that particular problem. Just ladlefuls of Java and UML, and weird cultish methodologies designed to prod drones into working well rather than improving the field outright. Sighhhhhhhh.
Anyway, the point is, this is not the kind of thing a top-ten university should teach. It is quite telling that process is described in far more detail than how to create a good design, although what it tells me I don't yet know. One day...
Leave a comment