Object Oriented

One the first page of my Web Site on sff.net, there are a couple of moving images, courtesy of Java applets. I yammer at length about the image manipulation part of the project in “Color Cycling with Java.”

As noted in the write-up, I undertook the color cycling project because of a long standing love for that particular effect in computer graphic art. It’s a simple trick; it can look spectacular; what’s not to like? Well, there is the part about how web browsers won’t do it without some sort of add-on, hence my Java applets.

What I don’t go into much is the Java part. Having the color cycling applets to point to allows me to claim some familiarity with Java, which is a useful thing for a technical writer these days. So there’s that. Moreover, Java is an Object-Oriented programming language. OOPLs used to be the flavor of the month; now they’re more like boilerplate. You have to claim familiarity in order to even interview for many jobs.

So let’s pause for a heavy sigh. (Sigh). I’ve complained many times about how the use of an ordinary word in a technical context can cause problems when the technical meaning differs significantly from ordinary usage. Jeez, does that apply to “object-oriented.”

Programming “objects” have nigh onto nothing to do with ordinary objects. They are programs! They do not have mass, weight, substance, color, physical dimensions, or persistence. Nor, for that matter, do they have anything to do with object code, the venerable term for a program that has been compiled into machine readable form.

What program “objects” have is “properties” and “methods.” For any old computer geezers such as myself, those translate to “data structures,” and “procedures.” But calling things by previously used names is so old-fashioned.

If that was all there was to it, then one might very well ask why bother, since there were already these perfectly reasonable programming structures called “sub-routines” and “modules.” Well sure, but there were a few new(ish) notions added to the mix: “inheritance” and “instantiation.” The former lets you create new “objects” based on old ones, with some modifications to the “encapsulated” data or the procedures that act on that data. The latter lets you fire off a bunch of similar program parts, each doing its own thing in the “multi-threaded environment” of the modern operating system.

See, this is just like taking your white hat and putting it into your matter duplicator, setting the dials to “blue” and “wings” so you have a new blue hat with wings. Then the blue hat can fly around and make fun of the poor wingless white hat.

That’s why they’re called “objects.” Because objects can do that sort of thing (snark).

Anyway, the idea was to use the object-oriented model to create re-usable program components that can be bolted together with minimal effort to create larger programs. This would have worked if it hadn’t been for those meddling kids and their stupid dog, I mean, if they had managed to get a variable typing system that was both consistent and comprehensible.

Unfortunately, the two major object-oriented languages, C++ and Java, based their variable typing conventions (as well as their syntax) on the C language, and that’s pretty much where the blue hat died and fluttered to the ground. C had so many exceptions and so much arcane weirdness in its variable typing that the whole thing was pretty much doomed from the start. It’s a simple fact that communication among “objects” can cause terrible headaches, because the variables they pass to each other get slippery.

Joke from the 1970s: C is Assembly Language in a clown suit.

Update to the 1990s: And C++ carries an Uzi.

Now realize, very little of this has anything to do with what someone is asking about when they ask you if you are “familiar with object-oriented programming principles.” What that translates to is, “Are you experienced with C++ and Java?”

I will say that the Object-Oriented project/marketing campaign succeeded brilliantly at making a lot more work for programmers. It also set the barriers to entry much higher and it resulted in the situation that programming now absolutely requires computerized programming tools. I wrote my Java applets more-or-less by hand, but I was hacking, just modifying previously written programs and sort of jamming them together. To do a similar project from scratch would have absolutely required a full bore Java programming tool set.

And it all would have been a lot easier to do in Pascal or even Fortran. But web browsers don’t support those, more’s the pity.

This Year’s Model II

I don’t believe that any SF writer or futurist in the 50s or 60s gets any credit for writing about how computer would be the Next Big Thing. For that matter, no one who had seen the first transistor radios replace the tubed giants could have missed that computers were also going to be the Next Little Thing, either. The increase in computing power and miniaturization of electronics were part of the “log-log paper and a straight edge” view of the future, and the only errors in that area were the slope of the line that got drawn.

Nevertheless, there was not all that good a foresight as to what those computers would be for. The (possibly apocryphal) story of the fellow who estimated that the world would need about six computers apparently comes from John Mauchly, co-developer of Eniac, which did numerical calculations for the Defense Department. Given that Mauchly eventually designed the Univac I, which ultimately sold about 40 machines, his estimate wasn’t that far off, if his original estimate was about economics, markets, and the near-term. Certainly no one was going to use a Univac for word processing.

The split between number crunching and number sorting was in computing from early on, with the split between “business” computers and “scientific” computers. By the time I came onto the scene, that split was exemplified by those working on IBM machines, and those working on CDC machines, with the latter sneering at the former at every opportunity. IBM was the domain of Cobol, while science used Fortran, or sometimes PL-1. Algol was Burroughs territory, and that land was too weird to rank.

Vast oversimplification, of course, since there were Fortran compilers for IBM machines, as well, and I’m sliding over Honeywell, and the rest of the “seven dwarves” of the computing world, but then, I’m not trying to write a history of computing here. Besides, mini-computers and then micro-computers soon made the previous status hierarchy obsolete.

From the science and engineering end of it, computers changed the equation, so to speak. The rapid fall of the cost of computing quickly meant that all sorts of calculations that were prohibitively expensive before computers became cheap and practical as the price/performance curve accelerated. It was the opening of a New World, not geographically, but conceptually, with unfathomable riches just strewn around on the ground. The question was, what part of the new landscape did you want to explore?

Before I get into some of the details of things that I personally know about, though, let me mention the real heartbreaker: Artificial Intelligence.

In a 1961 article in Analog, entitled “How to Think a Science Fiction Story,” G. Harry Stine did a bunch of extrapolations and made some predictions about the future. It’s worth noting that Stine was pushing something more extreme than the exponential extrapolation; in fact, what he was predicting was a lot like the Singularity that is all the rage. As a result, among other things, he predicted FTL travel for sometime in the 1980s, and human immortality for anyone born after 2000. Didn’t help Stine much; he died in 1997.

Stine’s extrapolation for computers was also a tad optimistic, predicting about 4 billion “circuits” in a computer by 1972. I’m not sure what he meant by “circuit” but we’ve only recently reached that number of transistors on a single CPU chip. Stine also thought that the human brain had that many “neural circuits.” Again, I’m not sure of what those were supposed to be, but the human brain has on the order of 100 billion neurons.

Of course a neuron is also a lot more complex in function than a transistor, so we’re still nowhere near a brain simulating device.

Nevertheless, Stine’s optimism was pretty well matched by the actual AI community, which thought that neurons and brains were really, really, inefficient, and that it would be possible to create intelligent devices that used many fewer circuit elements than the human brain required. Oops.

The result was an entire generation of computer science lost to AI. I’m overstating that, of course, partly because I knew more than one person who had his heart broken by the failure of the AI dream. I mention it as a cautionary tale. Not all the fruit in the New World is tasty. Not all of it even exists.

(For the record, based on some guesses about the complexity of neural function and assuming that Moore’s Law holds forever, I made an estimate in the mid-1980s that real machine intelligence would take from 80 to 100 years to come to fruition. Based on recent announcements by IBM of the “Blue Brain” project to simulate neural behavior in the neo-cortex, I’m currently estimating it will take 60-80 years. Unless Stine was right about the human longevity thing, I’ll not live to see that prediction proved right, although I could see it proved wrong if someone gets there first.)

Still and all, whatever happened in computer science stayed in computer science, for the most part. The only real hangover of the AI binge that I’ve ever had to deal with is the fact that the macro language of AutoCad is a version of Lisp. Besides, I was never much interested in Hal, Mike, or Robby the Robot. I wanted to be Harry Seldon, or someone like him.

I’ll write about that later.