Object-Oriented Programming: Why "Oriented"?

Question

I am most of the way through my games programming degree. This is not a computer science degree, so a lot of the theory is eschewed in favour of practical portfolio building and what I see as JIT learning, which is apparently more important in the games industry. The first subject was "Introduction to Object-Oriented Programming".

That phrase didn't bother me until I learned about the different programming paradigms (I'm getting this list from https://en.wikipedia.org/wiki/Comparison_of_programming_paradigms):

• Imperative
• Functional
• Procedural
• Structured
• Event-Driven
• Object-Oriented
• Declarative
• Automata-Based

I get that this is not an exhaustive list, and that not all of these concepts are equal, and most of them aren't even exclusive, but I don't understand why most of them get just one word - imperative; functional; declarative - but when we talk about programming with objects, we have to clarify that we are oriented around those objects. Can't we just use objects? Can't we just have objects? Why must they orient us, as our guiding star?

Looking here (https://en.wikipedia.org/wiki/Object-oriented_programming), nowhere is the use of the term "oriented" addressed as its own term. Only "object" is explained.

Also, I can see for practical reasons why Event-Driven is used, because Event Programming is already a thing that you do when you're running a conference, and Automata Programming makes it sound like you're setting up a robotic production line, so it helps to have additional clarifying words there.

What makes Object Programming, as a phrase, not enough to describe what we do when we use objects in our programming?

Obviously from my tone I'm not too fond of the word "oriented". It reminds me of my time as a court reporter, listening to lawyer after lawyer use the phrase "in relation to" as a kind of verbal tick. It didn't mean anything; it was just a term that they used to fill the air while they tried to think of what to say next. However, I'm not trying to advocate a change of language, I'm just asking why it is the way it is. If someone knows why it came to be known that way for purely historical, vestigial reasons, then that's the answer. It will be ammunition if I ever decide to waste my time advocating for a change of language.

On the other hand, if there is actually a useful reason for why a language or piece of code must point towards objects, to the exclusion of all other directions, as opposed to merely having them in its toolbelt, as tools, I would really be interested to learn about it. I like learning useful things.

Answer 1

I believe you're reading way too much into a simple grammatical construct. Take a look at your list of paradigms, sorted differently for a reason we will get to shortly:

• Imperative
• Functional
• Procedural
• Structured
• Declarative
• Event-Driven
• Automata-Based
• Object-Oriented

What do the words all have in common? They're all adjectives because they're intended to modify the word "programming". Furthermore, with the exception of "imperative" they're all not "natural" adjectives, but "adjectified" nouns - nouns that actually describe the core of the paradigm: function, structure, automata, and object.

And there are two different ways in which the nouns are adjectified: through a suffix like -al or -ed, or through creating a composite word using a hyphen. Now, as Doc Brown has pointed out, the suffixes that could be used to adjectify "object" result in a different meaning. Which leaves composition.

And I submit that it is pure coincidence or taste that Alan Kay chose to use "oriented" for his composite adjective "object-oriented". It could just as well have been "object-driven", or "object-based", and you might read too much into those as well. Doesn't "driven" sound like some sort of unhealthy obsession?

Answer 2

but when we talk about programming with objects, we have to clarify that we are oriented around those objects. Can't we just use objects? Can't we just have objects?

Frankly, it's a holdover of history. Functional programming is really function-oriented programming, declarative programming is really declaration-oriented programming... after all don't we just use functions? Can't we just have functions?

"Object oriented" rolls off the tongue better, and is historically ingrained.

The 'orientation' comes because we're not talking about programming but design. Just because we use objects, or use functions, or use events does not mean that our design methodology is done by modelling all three. By specifying the orientation of the design methodology, it helps communicate to programmers how they should interpret and extend that design - how the modelling focus colors the implementation.

Answer 3

Calling it that helps to explain that objects are a very important part of the paradigm.

Object-Oriented programming has its roots in Simula, which was essentially ALGOL plus some new object-programming features. And in keeping with that history, even today it's entirely possible in many languages (even the "pure OO languages") to code something that is essentially just a procedural program with some objects in it. But this is considered bad style by more experienced developers.

Actually doing something "the object-oriented way" is very different from "the procedural way." The most important concept is the use of inheritance and polymorphism. When you truly understand and internalize the way classes and virtual methods work, it's an eye-opening experience that changes the way you write code in a lot of cases, a true paradigm shift. (Assuming, of course, that you started out writing procedural code first. A lot of students these days go straight to Java or C# as a first language, and IMO they miss out on really understanding the benefits of OO by doing so.)

We call it object-oriented programming because a program written in OO style does not just contain objects; the structure of the whole program is based around them and around the way they work.