Rambling about programming

The two major forms of programming, Procedural and Object Oriented, approach the problem of programming from opposite directions; those directions being a code centric view (“verb oriented” if you will) and a data type centric view (“noun oriented”).

Procedural, being the older of the two, is code centric, since that's the primary view of computers when they were first built—how do we get this expensive box of electronics to do something? Procedural is more concerned with the steps of solving a problem—step one, step two, step three. Actions. Verbs. When you have very few data types, it's easier to program the nouns to the verbs (if you will). That is, a program will tend to look like:

>
```
add(one,two)
if one and two are ints, then do the add this way
if one and two are floats, then do the add this way
if one and two are strings, then do the add this way
sub(one,two)
if one and two are ints, then do the sub this way
if one and two are floats, then do the sub this way
if one and two are strings, then it's an error, bub!
```

Adding a new verb is easy, given the limited number of nouns present. But, as the number of nouns (remember, in this rather twisted metaphore, a noun is a data type) increases in a program, this starts to get unwieldy, which leads us to—

Object Oriented, developed in the 70s and gained industry wide acceptance during the 80s, is a more data-type centric view of programming. If you have lots of data types, but relatively few verbs, it then becomes more convenient to program the verbs to the nouns, something like:

>
```
int(op)
if op is add, do this
if op is sub, do this
float(op)
if op is add, do this
if op is sub, do this
string(op)
if op is add, do this
if op is sub, then it's an error, bub!
```

Sure, there's still a sequence of steps done to do anything, but it's the nouns that do the work themselves (if you care to view it that way). You simply tell the datatype, “do this.” And if it can, it does.

But as the number of verbs increase, then this too become unwieldly which leads us to—

Nothing that I know of.

Granted, if the number of verbs is significantly large to the number of nouns, then a Procedural method works well, while the opposite, if the number of nouns is significantly large to the number of verbs, then Object Oriented is the way to go. But what if both nouns and verbs are significantly large? What if you have a hundred different data types and a hundred different actions that can be applied? (One hundred of each ever after you tried reducing the number of both?)

Either approach will lead to a mess.

And when will you even have a large number of nouns and verbs in a program?

Well, think of the Massively-Multiuser Online Role Playing Games, like EverQuest [1] or Star Wars Galaxies [2]. Thousands of objects, and possibly thousands of different actions. A player can walk, run, skip, jump, jog, crawl, skulk, stumble, dance, turn, parry, dodge, spin, thrust (thwack! ouch!). That's just movement, and I'm sure I'm leaving out plenty of other movement actions. They can also carry, throw, chuck, up-chuck, heave, shoot, fling, place and lay items.

Sure, you can cut the number of actions down by making some of them more abstract, like “use” an object (the “use” of an object like a camera being different than the “use” of an object like a key) but we humans are creative (or stupid, take your pick) and while you can't use a key to take a picture, you can attempt to use a camera to open a lock (although you may end up with a mangled camera and a still locked lock) and it would be nice if the program would allow us to attempt this (even if it is stupid).

It'd be nice if there was a way to manage both a large number of nouns and verbs within a program, but as of yet, there doesn't seem to be a way to do this.

But even with this limitation, I think one can still build programs with tons of objects with tons of actions [3].

Or it may end up being one large mess.

I'd be interesting to see.

[1] http://www.everquest.com/

[2] http://starwarsgalaxies.station.sony.com/

[3] /boston/2004/10/19.2

Gemini Mention this post

Contact the author