Object Oriented Programming Language

The term ObjectOrientedLanguage is usually defined to mean a ProgrammingLanguage that supports ObjectOrientedProgramming. However, there seems to be no consensus on what "object-oriented programming" and "supports" mean.

Some programming languages, e.g. CeePlusPlus, CommonLisp, ObjectiveCaml AdaLanguage and EiffelLanguage, are object-oriented by the definition above but are really MultiParadigmProgrammingLanguages since they support other ProgrammingParadigms besides ObjectOrientedProgramming. Other languages, like SchemeLanguage and ForthLanguage, do not support object-oriented programming out of the box, but can be extended to do so in such a way that the object-oriented extension integrates seamlessly into the core language.

From IsJavaObjectOriented; a StandardDefinitions attempt.

Tentative definitions so far :

for a language to be object-oriented, all the FirstClass constructs must be object-oriented
at a minimum, an ObjectOrientedLanguage should have concepts such as encapsulation and polymorphism built-in.

For some definition of 'built-in' - A Smalltalk programmer can break encapsulation using instVarAt: any time he wants to. C++ programmers can use casts or pointer magic and Java programmers can use reflection. Eiffel may be the only language where encapsulation is strictly enforced. Does this mean Smalltalk, C++ and Java are not object oriented languages by definition?

I would tend to say that built-in does not imply enforced. The definitions above apply to the language and its inherent characteristics not to the programming style (see questions about LispLanguage and PerlLanguage below). Another page discusses ObjectOrientedProgramming. Here, we should focus on defining what attributes make a language OO (at least so we stop bickering about it on other pages).

The first requirement seems to be circular. Also, how do I tell if the FirstClass constructs (primitive data types?) are object oriented? In straight C, for example, operators are bound to the primitive data types in a manner that is almost indistinguishable from class defined operators.

Aren't we going completely overboard in saying of something that it isn't OO, and in the same sentence saying it's more OO!?

There is at least some sense in which Java is more OO than, say, PerlLanguage or LispLanguage.

Actually, Java is way less OO than Perl or Lisp.

How is LispLanguage more OO than Java (Lisp, not CLOS)? Perl?

The CommonLispObjectSystem is an integral part of CommonLisp. In Common Lisp, every value is a true blue object: an instance of some class. This is not the case in Java.

Also see HowObjectOrientedIsClos.

I think we all agree that PrototypeBasedLanguages are not OO.

I wouldn't... I can't say much about SelfLanguage, but I would assert that the LambdaMoo language, which is prototype-based, does capture some of what we intuitively mean when we say OO.

JavaScript is also prototype-based and also feels a bit OO.

I also disagree, PrototypeBasedLanguages feel like pure OO to me. They get to the heart of what OO is about, objects, composition, polymorphism, delegation. How can you think they're not OO?

Reasonable, mainstream languages allow people to write a horrible spaghetti mess, a radical and artistic OO masterpiece, and anything in between. Since OO programs and good programs, by themselves two orthogonal categories, are defined by taste and pragmatic consideration, it is futile to discuss objective criteria to say that language X is more OO than language Y. Also, someone who has a satisfying experience of OOP with some language is naturally inclined to consider less known and appreciated languages also less object-oriented.

Let's get away from types for a moment, and consider other FirstClass constructs. Consider an "if" statement. If this is not a class/object/interface, then it is not an object oriented construct. Thus we can say that Java, C++, Eiffel, etc. are not pure object oriented. However, it is possible to write programs in these languages that use an alternate mechanism based on polymorphism. So we can say that the languages are partially object oriented.

But, as this came out of JavaDesignFlaws, the point is that Java has parts that aren't OO, and there need to be constructs that tailor to those parts. Structured code requires structured constructs.

This is plainly a flight of fancy. Java could have boxed types and no second-class primitive types and still retain its C++ legacy. (See http://www.ai.mit.edu/people/shivers/javaScheme.html) Conversely, you could take a "structured" language and implement for it an equivalent of the conditional statement based on a "FirstClass" construct. Consider C with no "if" and just pointer arithmetic - perfectly feasible, in fact you and I know people who code like that, don't we? ;)

There are two points on which I think we're getting stuck here:

1) Trying to distinguish between what's "in" a language and what's "added on". For Java, there is a bright line: the language spec vs. the libraries. For Lisp, there isn't: is CLOS part of Lisp? You could argue either way. For Forth, it's even worse: very little is in Forth's core, but you can extend it easily (I think there's a 50-line extension to Forth in Forth that gives you encapsulation, polymorphism, and inheritance).

You can get around this problem simply by making some effort to be unambiguous -- e.g you might say, "Lisp with CLOS is object-oriented".

2) There are different relationships between object orientation and computer languages: support of OO, ubiquitous use of OO, and enforcement of OO.

Again, I'd recommend some effort to be unambiguous: e.g. "Java supports OO but doesn't use it everywhere", "SmallTalk uses OO everywhere, even for integers", "Java enforces OO by making you put all code into methods", etc.

Later, if there's some aspect or combination of aspects that seems especially important, we can agree to call a language OO if it fulfills those aspects. I don't think that will happen, but at least in the meantime we should stop talking past each other, and try to say more precisely what we really mean.

(See, Mom? I am using my philosophy degree!) -- GeorgePaci

WikiWritersDontGetPaid. ;-)

I propose that ProgrammingIsInTheMind, so the programmer's quality of thought is far more important than the language characteristics. However, I think that the choice of programming language is by far the second most important contributor to high-quality code. I think that it is more useful to evaluate ObjectOrientedLanguages on a spectrum of OO-ness. I also think that it would be more useful to separately evaluate OO concepts versus language support for those concepts.

Ultimately, I think the following approach would be most useful.

Given that we want high-quality automated solutions, how do we best achieve them? I submit that high-quality solutions demand high-quality thinking, so...

Given that high-quality solutions demand high-quality thinking, how do we obtain such quality in our programmer thinkers?

What constitutes high-quality programmer thinking (does it include OO, is it limited to only OO)?

Does high-quality programmer thinking have the same characteristics for every programmer (I doubt it, but I suspect that some subset is common)?

What programming language(s) best support(s) the expression of that (those) kind(s) of high-quality thinking?

To what degree can we make our tools encourage/enforce such high-quality thinking?

-- RobWilliams

See TheDumbingDownOfProgramming

A rant against class-based OO that was here has been moved to ArgumentsAgainstOop.

CategoryObjectOrientation