Nygaard Classification

In the presence of much bickering for what is or is not ObjectOriented, some people might use the wisdom of the computing pioneer KristenNygaard, father together with OleJohanDahl of object orientation itself.

He classifies the major paradigms of programming (in existence at that time) as follows:

ProceduralProgramming. A program execution is regarded as a (partially ordered) sequence of procedure calls manipulating variables.
FunctionalProgramming. A program is regarded as a mathematical function, describing a relation between input and output.
ConstraintProgramming. A program is regarded as a set of equations describing relations between input and output.
ObjectOrientedProgramming. A program execution is regarded as a physical model, simulating the behavior of either a real or imaginary part of the world.

Interestingly he goes on to say:

: "The notion of a physical model should be taken literally. Most people can imagine the construction of physical models by means of, for example, Lego bricks. In the same way, a program execution may be viewed as a physical model. Other perspectives on programming are made precise by some underlying model defining equations, relations, predicates, etc. For object-oriented programming, however, we have to elaborate on the concept of physical models."

From Object-Oriented Programming in the Beta Programming Language (ftp://ftp.daimi.au.dk/pub/beta/betabook/betabook.pdf).

Some folks disagree that NygaardClassification is the right way to define OO. See NygaardClassificationContested

Many don't agree with the "physical" definition of OO. See OoBestFeaturePoll.

Well, "many" is nowhere near comparable with KristenNygaard, he invented the damn thing, so his definition of what he invented must have some weight. It's not argument by authority, but I guess definition by the authority of the inventor. It's similar to TopMind getting to define TableOrientedProgramming.

I think NygaardClassification gives the proper definition of ObjectOriented because it goes to the heart of the matter. Object Orientation is essentially about a how one goes to construct object oriented systems and what one should recognize in an object oriented system.

It also properly distinguishes "object oriented" from other paradigms, otherwise, given the power of many languages it's easy to write procedural code in Smalltalk, functional code in Python, or object oriented code in Scheme. Some people claimed polymorphism and encapsulation as the distinguishing features of object orientation but that falls on its face since both are supported by all major functional languages.

However given the above definition, it is fairly easy to distinguish object oriented from functional or logic programming.

... if you think that this is a useful thing to do.

If the design focuses on describing autonomous entities that react to messages by updating their state and/or sending other messages ( thus simulating a physical model ), then it is object oriented. If the design focuses on describing a system of constraints that will be solved by a inference engine, then it is logic programming. If the design focuses on creating functions through functional means (lambda abstraction, recursion, higher order functions, currying, etc) then it is functional programming. It is thus very hard to confuse one for the other.

Somebody added arguably to "the father of object orientation itself". Nygaard and and Dahl are widely recognized as "fathers of object oriented programming" because of having invented the core notion of objects and classes in SimulaLanguage, and nobody of any authority in computing contested that.

Contested and refuted above.

What happened to the description of "object" as an entity exhibiting state and behavior? Does that figure into the model, the programming language, or somewhere else in the paradigm?

It's there in the book, chapter 2.2.2. Of course physical models are composed of objects that have state and behavior (react to stimuli <=> respond to messages ). The book is definitely worth at least a cursory read.

Object-oriented programming. A program execution is regarded as a physical model, simulating the behavior of either a real or imaginary part of the world.

Help me understand what this means. Couldn't I regard the execution of my OO code as a physical model of that imaginary part of the world that is "a (partially ordered) sequence of procedure calls manipulating variables"? If we should "elaborate on the concept of physical models", but those physcial models represent imaginary things, can't they be any model we can imagine? What makes them more "physical" than other models?

Intuitively, just think of modern GUIs, which are, with preponderence OO, even if some of them are programmed in C. All the widgets on the screen act like "objects", and the code is organized for them to act like object, the organization of the code mirror the organization of an imaginary physical model.

[I can't grasp what's more "physical" about that imaginary model than any other imaginary model. Perhaps I'm not intuitive enough.]

In the ideal case (rarely seen in implementation), objects exist in space and time and obey rules similar to that of physical objects rather than magically appearing/disappearing, whereas values are timeless and locationless (have no unique location, can be copied or destroyed invisibly). LinearLogic is a pure version of this view of objects.

Pure functional programming is a pure version of non-object, value-based programming, and hence is amenable to traditional mathematical treatment.

Most math concerns values which are treated as if they always exist in some Platonic realm even without being constructed (constructive mathematics is a rather small subset of all of mathematics), although it is not literally necessary to believe in a dualistic Platonic philosophy, only to use the word "exists" alone as if it referred to such a thing.

Most OO language and practice strays from this extreme, and most functional/procedural programming strays from the other extreme.

None of this is to say that OO programming cannot be analyzed mathematically, it's just that it tends to stray quickly into newer areas of math, such as TemporalLogic/SpatioTemporalLogic?.

-- DougMerritt

[What is ideal about objects obeying rules similar to that of physical objects? We build imaginary software machines precisely because it's impossible or too expensive to build real machines that have to obey the laws of physics.]

Because we have 650 million years of evolution worth of neural power that understands the behavior of physical objects intuitively. The same is not true of mathematical magical values, which is one major reason why only a tiny fraction of the population does well in math. --dm

Also, according Abelson and Sussman in their lectures on StructureAndInterpretationOfComputerPrograms, the idea behind the organization of code to simulate physical objects, is that objects in the real world have good modularity, so the good effect is to have better modularity in the code. That was the main idea behind Simula and how ObjectOrientation came about, whether you like it or agree with it or not. Other technical details like encapsulation, polymorphism are trivially available in good functional/procedural languages and also in logic programming. --Costin

Yep. Also, if you think about it, this (physical objects having good modularity) ends up being the same thing as my evolutionary point, ultimately: we understand and prize modularity because of the environment we evolved in.

Your other point, that encapsulation/polymorphism/etc are available outside of OO languages, is very important and often neglected. The good practices that are valued in OO did not develop in a vacuum. In recent years it seems that, since everyone is talking about OO now, people have stopped talking about good practice in non-OO languages; for instance, discussions here reveal that even old-timers have forgotten some of the definition of structured programming (like single-entry/single-exit), and why that used to be considered very important. Other things that have been partly forgotten include coupling strength and degree of cohesion; I was thinking about putting up a page on the subject. Top might find it of interest. :-) But those issues still apply even in purely OO languages, I just don't hear people talking about them. --dm

[I agree that we should play to our mental strengths (see OoFitsOurMentalAbilities), but I'm wary of placing too much value on physical reality while coding. Programs are designs for imaginary machines. It's beneficial to make those machines modular. It isn't beneficial to make them heavy, slow, brittle, 2 or 3 dimensional, or many of the other properties we're familiar with from the world of molecules. I often think of a program as if the methods and fields were connected by n-dimensional springs. Use increases tension on the springs, pulling the methods and fields that use each other the most closer together, revealing practical component boundaries at different scales of abstraction. That's all well and good, but I don't have to worry about the springs interfering with each other in 3 dimensional space like I would with a physical machine. And I don't have to worry if the springs pull my imaginary machine into components that aren't identical to a physical machine or system it may be replacing or interacting with.]

For what it is worth a key point that has always formed the core of my personal operational definition of OO ( for which I make no grand claim ) is that behavior and state are combined into a single representation. One model that has behavior and state in one abstraction. This does not mean that every object must have state, but if it does that state lives in the same abstraction.

--MarcGrundfest

Measuring World-ness?

There is no way to measure "fitness to the real world". Thus, even if we did agree on such a definition, there is still a second hurdle. And, what about modeling things that have no real-world counterpart, such as intellectual property and electronic money transfers?

If we think of the real world in terms of "things", then perhaps something that groups code by nouns may be an indicator. (But "things" is mostly a perceptual issue, not something the universe "knows" about outside of an intelligent observer.) OO tends to group by "nouns" more than procedural, which tends to group by verbs, but RDBMS group by nouns because tables (entities) tend to correspond to domain nouns. Thus, NygaardClassification would suggest that RDBMS are "object oriented". But most would reject this.

Looking at the classification one clearly sees that ProceduralProgramming, FunctionalProgramming and ConstraintProgramming are different paradigms, they are mutually exclusive. ObjectOrientedProgramming however is compatible with each of the three major paradigms, a program can be procedural and object-oriented at the same time, or it can be functional and object-oriented.

Obviously OOP is not a new programming paradigm, contrary to common belief. It's just a set of conventions layer over procedural or functional programming. One really has to wonder why it is so oversold.

The big problem here is that NobodyAgreesOnWhatOoIs.

CategoryObjectOrientation