18 December 2005

another "OO" fad language

recent wikipedia featured article. not bad, though i think the article as structured will be confusing to non-specialists. seems they might have split it up into several articles, though i think they do a reasonable job of at least raising the many, many points that should be discussed in a comprehensive discourse on the language / platform / marketing machine that is java.

i didn't know that java was originally designed to run embedded in cable set-top boxes and microwaves, with the "web thing" being mostly a crime of opportunity.

7 comments:

Drew said...


i didn't know that java was originally designed to run embedded in cable set-top boxes and microwaves, with the "web thing" being mostly a crime of opportunity.


Yeah, and it was also going to be called "oak". (Did the article say that? I didn't read it yet.)

I recall a Software Engineering class I took at CWRU with Dr. Lee White in which small groups of students had to do special projects. One group did their project on this new-fangled language called "Java", and they concluded that it had the potential to come into widespread use.

But that was a decade ago.

I am old.

tormp said...

it does mention the "oak" thing (which i did know). i think i also spotted a few minor inaccuracies, though i can't recall any off the top of my head right now.

you're not too old to go see king kong.

Drew said...

Well, dogg, if you think the article is confusing to non-specialists or that it has inaccuracies, it is in your power to edit the article and make it rock like hurra torpedo.

Yeah, I gotta make it out there to see King Kong.

dcass: please photoshop us a picture of "Rodney King Kong".

Drew said...

Objects don't map well to RDBMS's.

In my experience, RDBMS's are great if you can think of your data in terms of set theory: decide which records to select or not based on some criteria.

Objects are more of a one-at-a-time kind of thing. And while it is possible to bring the two ideas together, it sure seems like you usually end up losing a bit on each end, but gaining some kludgy bridge code in between.

Yet this seems to be a popular pattern, and it actually seems to work pretty good most of the time, so that just proves that I don't know much.

Also, I am old.

tormp said...

another way of looking at it, is RDBMS is nice if you want to select a bunch of the same kinds of things (rows from the same table), but in objects you usually want to select a bunch of different kinds of things (navigate an object graph).

it seems like the trick with an object graph is laying it out on a disk so you can get to it quickly, or from different roots (whereas this problem is more obvious with an RDBMS).

maybe someday we'll have a physical storage medium that isn't just a big stream (or N streams) and a whole bunch of crazy new programming paradigms / storage metaphors will result.

tormp said...

"oop is oversold" also exemplifies kofno's observation that cranks like the <center> tag.

Drew said...


another way of looking at it, is RDBMS is nice if you want to select a bunch of the same kinds of things


So true. Even if the things were different to begin with (say "employees" and "departments", stored in separate tables), then they'll be the same when you get ahold of them (whatever subset of columns you select from the joined tables).


maybe someday we'll have a physical storage medium that isn't just a big stream (or N streams) and a whole bunch of crazy new programming paradigms / storage metaphors will result.


Yeah, foshizzle. Data streams are conveniently close to the physical storage medium of a disk, but flash memory offers at least the possibility of random access to persisted data.

Why, I remember the old shacky days, when the diskless Apple Newton stored data in a soup of objects (yeah, that's actually the technical term) that were all alike. You could swim around freely in the soup from object to object. Mmm, soup-swimming!

I'm afraid I don't have deep enough experience with Newton programming to be more detailed than that, but talk about new programming paradigms / storage metaphors!