I can't think of a better place among SO siblings to pose such a question. Originally I wanted to ask "Is python a pure OO language?" but considering troubles and some sort of discomfort people experience while trying to define the term I decided to start with obtaining a clear definition for the term itself.

It would be rather fair to start with correspondence by Dr. Alan Kay, who has coined the term (note the inspiration in biological analogy to cells or other living objects).

There are following ways to approach the task:

Give a comparative analysis by listing programming languages that can exhibit (or fail to do so) certain properties unique and sufficient to define the term (although Smalltalk, Scala, Java, and so on - are possible examples but IMO this way seems neither really complete nor fruitful)

Give a formal definition (or close to it, e.g. in more academic or mathematical style).

Give a philosophical definition that would totally rely on semantical context of concrete language or a priori programming experience (there must be some chance of successful explanation by the community).

My current version: "If a certain programming (formal) language that can (grammatically) differentiate between operations and operands as well as infer about the type of each operand whether this type is an object (in sense of OOP) or not then we call such a language an OO-language as long as there is at least one type in this language which is an object. Finally, if all types of the language are also objects we define such language to be pure (strong) OO-language."

Would appreciate any possible improvement of it. As you can see I just made the definition dependent on the term "object" (often fully referenced as class of objects).

[EDIT]

In addition, I use (luckily well understood) notion of a type as in typed languages. Data type programming or type oriented programing is not only a syntactical interpretation (of the program text, i.e. how to treat certain values of literals and data variables - something that evolves into type safety) but can be attributed to language grammar and studied in formal way (using mathematical logic) as so called type systems. Notice that requiring particular type system to have a so called universal type is one of the ways defining purity of OO language (there are ways to expand this semantically).

NB

how to answer:

it helps if you specify a book or a reference that supports/explains your understanding of terminology and concepts (usually a good definition covers or references all depended concepts except elementary).

classification is important (and also because term pure-OO is included into term OO) while answering try to unmix elements of OO paradigm from other well known methodologies (and by no means confuse/overlap them, e.g. typically elements of modular programming can be covered/embodied with OO programming): try to distinguish OOP from (including or being a part of) Functional programming, Logical programming (especially strongly specialized ), Abstarct Data Types (ADT), Modular, Metaprogramming (generics and LISP's macroexpansion-time), Contracts (e.g. Eiffel), Aspect-oriented (AO), (difference between declarative and functional classification as well as historical definitions of Dijkstra's structured are clear)

on difficulty of giving a formal definition: surprisingly enough it is very easy to give a mathematical description of OOP in form of a certain logical (formal) system (most likely type based) and defining one concept after another. One can even try to do something more practical by applying that formalism to type safety checking or new language design aspects than merely abstract entertainment or exercise (also lookup formulation of OOP in Intuitionistic Type Theory, Dependent types, independently, in FOL formalisms as lambda calculus and just by using category theory). A main point here is that unsurprisingly such formulations IMO are strongly biased (flawed) by most likely initially incomplete understanding of OOP (in computer engineering) and end up being almost inaccessible afterwards (thus hardly contributing backwards to programming world - maybe except certain percentage finds applications back from formal world by being integrated into popular languages).

So yes, it is difficult to give exactly a "good" definition, not just definition. But I am positive of asking this here because of your experience and direct involvement, guys.

+1 for the nice question, but your version is a bit flawed by the problem that a type and an object are different things.
–
FrankSep 12 '12 at 5:17

5

@JoachimSauer: He said in another mail on the Squeak mailinglist that "the big idea is Messaging" and that he regrets ever having called it "Object-Oriented" and should rather have called it "Message-Oriented" instead. Erlang, for example, is a thoroughly object-oriented language which meets all of Dr. Kay's criteria without having any concept at all of "objects", "methods", "inheritance", "classes", "prototypes" or something like that.
–
Jörg W MittagSep 12 '12 at 10:03

1

This could be a nice illustration that syntaxes is not enough to define an OO language. If one can show that OOP (e.g. as a tool) is semantical only (syntaxes-independent), that changes (inverts) my question completely!
–
Yauhen YakimovichSep 13 '12 at 1:55

2

@YauhenYakimovich This is one of the root problems in discussing OOP, everyone and his dog has their own idea of what it is. In contrast, structured programming and functional programming can each be defined very simply. This leads me to question whether OO has similar properties to religion instead of science.
–
Ricky ClarksonSep 13 '12 at 5:36

5 Answers
5

OO, according to Alan Kay is all about message passing, and that's it. You will see that qualities such as polymorphism and encapsulation are actually derived from message passing.

Now that stance is in fact very extreme, because it basically means that only Smalltalk and languages alike would qualify.

I think you can define OO as building your system on entities, that fully encapsulate their state, and that are rendered exchangeable due to their inherent polymorphous qualities. One could thus argue a purely OO language ensures these two core qualities are always met. What renders OO languages "impure" would be mechanisms that allow the creation of constructs that do not meet these criteria, such as the possibilities to:

declare public fields

declare variables that can only hold instances of a specific class and its subclasses (i.e. variables should be typed against interfaces, which is what the biological objects communicate through in Kay's anology), which is rendered even narrower if the class in question is final, as that leaves even less room for polymorphism

declare primitives

Then again, IMHO language purity is more a weakness than a strength. OO is not a silver bullet. No single paradigm is.

@AndresF. Note that practical value of OOP as well as other theoretical knowledge related to programming is not really a part of a question. It is pretty obvious that one can write code in a pretty successful manner w/o any deep understanding of programming techniques or theories (and the other way around). Neither the application properties of OO languages are discussed, etc.
–
Yauhen YakimovichSep 12 '12 at 20:14

@YauhenYakimovich Oh, I know. I wouldn't have upvoted the answer if it had been off-topic. Still, I liked an assertion I agree with.
–
Andres F.Sep 12 '12 at 20:28

@AndresF. Sure :-) "OO is not a silver bullet" is most likely true as well as us lacking a perfect programming language. But what exactly makes OOP not a silver bullet? Just as a good bug report I think detailed and precise terminology is the way to answer this. I have invested so much time in working with it that I am just damn curious to bring it to the next level. Is OOP just a bunch of ideas copy pasted from one programing book to another?
–
Yauhen YakimovichSep 12 '12 at 21:51

@back2dos +1 for explicitly pointing out the role of "message passing" according to Kay (Smalltalk, Objective-C). Apparently he never intended to see OOP developed towards directions it has today. But I really liked that Kay had those ideas to make objects NOT data (types). He really pushed to attribute them biological qualities, but ended up in "messaging".
–
Yauhen YakimovichSep 13 '12 at 0:27

I would approach this by defining it as a language which uses OOP constructs and nothing else (in the same way that a pure FP language uses pure functions with immutable data and nothing else).

In particular:

Every entity that your program operates on is a first class Object - i.e. no primitives, no pointers, no arrays etc.

The only thing you can do with an object is call a (potentially polymorphic) method on it (== sending a message). No other operations exist.

All data is encapsulated - i.e. no public field access, you must go via methods on an object

If you have first class functions then they must also be objects - so you would need to do something like functionObject.call(param1,param2)

No global variables - if you want something like this you would need to use an object to represent the current global environment, e.g. environment.getValue("myThing") or put the variable in a class object

Note that this still leaves quite a few options open:

Class-based vs. prototype-based object models

How inheritance is implemented (if at all)

Whether you have single or multiple dispatch on methods

Whether your objects are statically or dynamically typed

The exact syntax used for method calls (e.g. you could have some syntactic sugar for getters / setters etc.)

these are good definitions, but don't confuse object reality with mere syntax. Just because functions and global variables have a friendly syntax, they may actually be objects at heart.
–
ddyerSep 12 '12 at 5:51

@ddyer - that's correct if it is truly just syntax, but I think that if the syntax also introduces different semantics then it can break the "pureness". For example, w.r.t. global variables the use of globalVariableName to access a global variable is a different semantic from a method call on an object, which would be the only way to access a non-local value in pure OOP.
–
mikeraSep 12 '12 at 7:09

I think "Everything" needs to be qualified. If a language has no reflective ability at all (for example, it can't reference a method of an object by an abstract name, or store it in a variable), then do methods need to be objects as well? Are references objects? Are references and objects even different things?
–
Joachim SauerSep 12 '12 at 8:31

@Joachim - good point. I qualified it as "every entity that your program operates on" in order to distinguish objects from meta-objects in the language like variable names and syntactic constructs. Obviously if your program actually operates on such things via reflection then they would need to be reified as real objects but that is not always going to be a requirement. Anyway, if you can think of a better qualification though then feel free to edit it in!
–
mikeraSep 12 '12 at 8:52

"Class-based vs. prototype-based object models": but I would say that in both cases you have some sort of classification, i.e. you group together objects with a common structure and behaviour.
–
GiorgioSep 12 '12 at 9:59

The discussion about so-called OO languages has always been a bit on the brain-washed side. Ie:

"Someone has told me that language X is OO, so therefore language X equals OO then every language that lacks the features of language X cannot possibly be OO. And because I'm writing my code in language X, everything I do is OO."

The term object-oriented design boils down to 3 things:

Modular design with autonomous objects that don't know needless information about the rest of the program, aka as loose coupling as possible.

Encapsulation of data inside objects to prevent external access, both intentional and accidental.

Clearly specified dependencies between objects. To achieve loose coupling, but also to make the program easier to maintain and expand.

1) is pure program design, it can be achieved in any programming language. However, some languages have helpful features such as class/struct and private keywords.

2) is mainly program design, though cannot be fully achieved without language support, since you need language mechanisms like private/static to protect against accidental use.

3) is mainly program design. There are typically three different dependencies: "object X contains object Y", "object X is a kind of Y" and "object X interacts with object Y". There are plenty of language features to help with these dependencies: inheritance/polymorphism, abstract base classes and so on.

Now, if we look at the above we can see that you barely need any language features to write OO programs. The features just make it far easier.

The above goals cannot be achieved by using some muddy backwards-logic: just because you use the class keyword, your program does not automatically get a modular design. Just because you use inheritance, it doesn't automatically mean that your object dependencies make sense. A language with OO features would still allow things like class TheWholeBloodyProgram or "Animal inherits Cat".

Sadly, the topic of good object-oriented program design is rarely mentioned in these kind of discussions. Brainwashed programmers only look at the syntax and yap things like for example "C++ has primitive data types so your C++ program isn't OO", then they go off to write a downright horrible program in their own favourite language, without using any hint of program design what-so-ever.

To answer the question: very few, if any languages have support for proper OO program design. To find out which languages that has certain OO-related features is irrelevant as long as the programmer doesn't know what object-oriented design means. A programmer claiming that certain languages are object-oriented has most likely not grasped the concept of OO as whole. Ask the would-be OO programmer how they design OO programs. If the first thing they do is to start yelling language keywords, then you can safely assume they don't know OO design.

Perhaps there exists some fancy high-level UML-ish tool far above the raw source code, which enforces the programmer to only write programs with good object-oriented design, but I doubt it. The best design tools for OO programming is most likely still the human brain and common sense.

Can you clarify how your definition differs from, e.g. modular programming with abstract data types? I think you are on the right track, but I cannot see the train yet!
–
Jörg W MittagSep 12 '12 at 14:24

@JörgWMittag It isn't necessarily different, traditional ADT:s can be written using object-oriented design, with proper encapsulation, setters/getters, ways to inherit it etc etc. But they can also be written without regards to OO design. -->
–
user29079Sep 12 '12 at 15:43

2

@JörgWMittag If you have a language like C for example, with limited language support for OO, then it is tricky to write ADT:s in an object-oriented manner. The most common mistake is to leave the allocation of the ADT to the caller, ie give them a public struct with all of the internals exposed, breaking encapsulation. The proper way to do this in C is through so-called "opaque types" (incomplete types), though not many C programmers know to use them.
–
user29079Sep 12 '12 at 15:44

@Lundin: In the paper posted by JörgWMittag as a comment to another answer there is an (IMO) interesting comparison between ADT and OO.
–
GiorgioSep 12 '12 at 18:55

No, there is no formal or even useful definition, and there never will be. To some people, OOP means "Universal base class" and "Must use reference semantics, best with a garbage collector"- and you can even get quibbles about syntax, one of the least relevant things ever invented.

Ultimately, first, you have to answer the question "What is an object?". The more narrow-minded will insist on inheriting from some pointless universal base class and needlessly being allocated on a garbage collector to qualify. But I prefer a much more useful definition. The purpose of OOP is to have some data, and some functions you can call on that data. So

An object holds some state and offers some functions on that state.

In this case, even int qualifies. After all, when you write template code in C++ which can accept either primitives or objects, then it becomes difficult to argue that primitives are different in any substantial way. There's nothing meaningfully different about Vector v1, v2; v1 + v2; instead of int v1, v2; v1 + v2; (except the crappy initialization semantics, one must admit). Also, this permits lambdas and such things to be objects, as they hold state- their captures- and offer a function on that state, to call the lambda.

Fortunately, we can also classify pointers to free functions as objects, since they both hold state (an address) and a function on that state (to call it). So a free function should be allowed- even if you were to say that all free functions are in fact global function pointers.

I see no need for such a distinction. But secondly, they have the same identity that any other object has- address/reference comparison. The fact that you cannot tell apart two objects with the same state, except by comparing addresses, is far from new and applies to all objects.
–
DeadMGSep 12 '12 at 9:57

"I see no need for such a distinction.": But this distinction is among the commonly-accepted features of objects. Of course, you can develop your own notion of an object which is different from what is commonly accepted. You are totally free to do it.
–
GiorgioSep 12 '12 at 10:03

2

@Jörg I beg to differ. I don’t agree entirely with this post but calling the caveat in the first paragraph “useless” or a “rant” is disingenuous. There is no universally agreed on definition for OOP. That is a simple, and widely acknowledged, fact. The rest of the post is a definition of OOP. Certainly not the most widely used, nor the one I’d give, but, as DeadMG said, actually quite a useful one.
–
Konrad RudolphSep 12 '12 at 11:57

2

@KonradRudolph: that paragraph read very different when I wrote my comment, including comparing programmers who care about syntax to racists, even mentioning a specific user of this site by name.
–
Jörg W MittagSep 12 '12 at 14:09

You can think of it by negative example. Java is not a pure object oriented language because there are also primitive types that are not objects. These are integers, doubles, arrays and so on. In a pure object language, the semantics of objects are available for everything.

There's also the question of how much of the language is closed to modification, even within the object framework. In java you can't define new subclasses for some classes, such as
String or Class.

Which languages are pure? The only candidate that comes to mind is smalltalk.