Confused. Is OO inherently imperative or is is it multi-paradigm?

views:

393

answers:

+2 Q:

Confused. Is OO inherently imperative or is is it multi-paradigm?

As I have read through stackoverflow answers and questions I am getting the impression that OO is compartmentalized to to be inherently imperative.

But isn't OO just a way to compartmentalize code and data into real world Objects?

If so, why would that forgo other lower level paradigm to work in such a platform?

IOW, an Object Based generic type system that is immutable by default would be the way a functional first language would work, an object based generic type system that is mutable by default would be the world of imperative languages.

Or am I missing something altogether?

+5 A:

Most OO languages are imperative, but you can use them in a somewhat functional style. Some functional languages sit atop an OO framework (F# on .NET being the most obvious example) trading off some "purity" in order to get a massive framework to use where appropriate.

I think there's a lot of room for "mainly OO" languages to do more to help programming in a functional style - better support for immutability being the most obvious feature, possibly followed by better type inference. (At least when talking about C#, which is probably the most significant example of a traditional language trying to get a foot in the functional door.)

Jon Skeet 2009-02-16 14:59:35

can add better support for recursion to that list also for C#.

DouglasH 2009-02-16 16:01:41

+15 A:

No. OO and imperative are two orthogonal concepts.

For example:

The Common Lisp Object System is an example of Lisp OO and maybe the most complex object system around.
OCaml is a functional language with an object system and a module system supporting object-oriented organization
Scala is a functional language with a very flexible OO system
Haskell allows you to write object-oriented code using higher-kinded polymorphism

There are lots of different ways to be object-oriented.

2009-02-16 15:07:03

That is what I was seeing in my review of Programming languages, But wasn't getting that impression when reading answers here. Haven't programmed much since the 80's and getting back into it. OO was just becoming new thing to learn then.

DouglasH 2009-02-16 15:13:00

@Doug, SO is heavily C#/.NET, Java, and C++ biased. Mostly, because that's what most people work in. Non-procedural languages are more niche and so they come up less frequently.

2009-02-16 15:24:48

objects are stateful, which is an imperative concept; pure functional languages are stateless and therefore can't have objects; monads are a workaround for languages which want to stay pure (Haskell), while (all?) the other languages you listed aren't pure functional ones - even LISP!

Christoph 2009-02-16 16:25:55

@Christoph, OP never mentioned anything about requiring functional languages to be pure-functional. Your view of OO is too narrow.

2009-02-16 16:35:09

@stbuton: my point is that oo is only possible in languages which aren't purely functional - they *have* to incorporate imperative features, and that's because - drum roll - oo is an imperative concept

Christoph 2009-02-16 17:44:16

@Christoph, Haskell allows for OO development. Have you ever even used any of these languages? Transformation of state is possible in Haskell, you just get a new object with a different state. Your view of state is overly simplistic and naive.

2009-02-16 18:31:48

@stbuton: I have programmed in LISP, but in none of the others; and I still think OO is inherently imperative (see Justice' answer and the definition of OO I posted)

Christoph 2009-02-16 18:38:10

I'd say CLOS is one of the *simplest* object systems ever (though of course it's still no Smalltalk)! AMOP implements basically all of CLOS+MOP in about 1000 LOC. Look at a C++ or C# book -- how many of them have source code and explanation for their entire OO system in the first 150 pages? :-)

Ken 2009-02-16 19:11:51

@Ken, I mean 'complex' in the sense that it allows you to provide a lot of customizations and specializations to how it works. Maybe 'complex' is the wrong word. Perhaps 'deep' is better. It allows the user to build up a lot of complexity from fairly simple concepts.

2009-02-16 21:00:19

stbuton: That's fair. I would also accept "metacircularly awesometastic". :-)

Ken 2009-02-16 21:33:18

Take the case of immutable strings in C#/Java/etc. Data hiding, polymorphism, and other OO concepts don't rely on observable side effects.

Aaron 2009-02-17 19:10:15

@Aaron: try making all classes in the C#/Java standard library immutable, see how well that works out; data hiding + polymorphism != oop

Christoph 2009-02-23 16:38:22

From the Haskell tutorial: "In contrast to OOP, it should be clear that types are not objects, and in particular there is no notion of an object's or type's internal mutable state."

Christoph 2009-02-23 16:39:00

Herb Sutter has a nice explanation of extended OOP by means of the interface principle. http://www.gotw.ca/publications/mill02.htm Your view of OOP and classes is too locked into the Java/C# version of OOP.

2009-02-23 18:09:43

Mutable state is not necesary, it is the organization of functionality by logical objects that is important. Organization of code by logical objects and mutable state are completely orthogonal.

2009-02-23 18:11:40

@stbuton: your definition is close to (but not exactly) Nygaard's ( http://c2.com/cgi/wiki?NygaardClassification ) - father of Simula; but it was Alan Kay ( http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented ) who coined the term

Christoph 2009-02-23 18:57:40

btw, the linked definition by Alan Kay is actually too restrictive - he later emphasized that the most important part is the message passing; that's why I posted my own revised version of his definition below

Christoph 2009-02-23 19:03:43

and your definition of oo - "organization of functionality by logical objects" - is already present in abstract data type programming, which is a more general concept than oo

Christoph 2009-02-23 19:34:01

see also http://community.schemewiki.org/?object-oriented-programming - most common definitions of oo are more restrictive than yours

Christoph 2009-02-23 20:04:50

For something as nebulous as OO for which the founders of the discipline cannot even decide on a concise, suitable definition, I think it is left to the community to decide its intended meaning. I think the community prefers a broader concept.Case in point, my answer has 12 up-votes, yours has -1.

2009-02-23 20:31:43

@stbuton: well, shit must be delicious: millions of flies can't be wrong ;) btw, when I asked if oo is an imperative concept on #haskell, the answer I got was: "there's many flavors of object oriented programming but yeah i think in most definitions of it, it implies an imperative world"

Christoph 2009-02-24 18:50:19

I have spoken to Haskell programmers who say they write object-oriented code. So? Are their definitions more or less valid than yours or mine? Your shit analogy is moot. And your arguments by authority are equally tiresome and empty. I don't know why you care about this so much.

2009-02-24 21:23:37

I didn't want to end this discussion by authority, but to point out that there's disagreement in the community and no single preferred definition as your comment suggested; giving an absolute yes/no answer to the original question without stating which definition of oo you use is misleading at best

Christoph 2009-02-25 11:29:24

Why? I answered the question how I think OO should be interpreted. Other people are free to disagree with me and post their answers. There's no reason for me to turn it into an essay on the meaning of OO. If people disagree with me they're free to ignore my answer.

2009-02-25 14:07:26

Trying to define it would only add more headaches as it would probably turn it into a "What is OO?" discussion rather than keeping it on topic and relevant to the author's question. It's a subjective question with a subjective answer. It doesn't mean I can't be definite about my subjective answer.

2009-02-25 14:17:12

@stbuton: "Why?" - To avoid misunderstandings? I only commented your answer because I wasn't aware of your loose definition of oo. There was a time (before C++ came along) where oo meant 'what Smalltalk does'; and Smalltalk-like oo is indeed an imperative concept (see Justice' and my answer)

Christoph 2009-02-25 15:20:05

And there is a time after Smalltalk where the concept of OO has been extended to more realms. Look at Scala. It has mutable and immutable concepts of OO that exist in parallel. Seriously, play with Scala. You'll see what I'm talking about.

2009-02-25 15:44:21

You just haven't used enough different types of languages to really grasp the full breadth of the concept. If all you've ever known is imperative OO then all OO looks imperative. Until you've used one of these languages that enables objects with immutable state I can't really take you seriously.

2009-02-25 15:47:25

You missed a critical point about OCaml: it has (purely) functional object update and, consequently, supports OOP without requiring mutation. So OCaml is a trivial counter-example to Christoph's claim.

Jon Harrop 2009-04-13 00:10:23

+2 A:

Yes. Object-oriented is a style of programming which permits the programmer to express a program as a set of stateful objects acting and interacting (typically, by means of message-passing in dynamically-typed languages and method-invoking in statically-typed languages), and doing so in a particular sequence.

State, action and sequence are concepts from procedural programming and are not present in nonmonadic functional programming (monads are used to implement state, action and sequence in the pure functional languages Haskell, which would otherwise not have these concepts).

Justice 2009-02-16 15:15:49

+1: objects have mutable state, an imperative concept

Christoph 2009-02-16 16:17:45

Objects *can* have mutable state - but equally you can come up with immutable objects too. I'm writing a benchmark framework which I hope will have *no* mutable state - but it's still OO.

Jon Skeet 2009-02-16 16:26:41

Ok I choose Functional as Just an example. Logic programming can use OO paradigm also. But What would the OO paradigm have looked like if it was built upon the Functional languages first?? Or Logic languages?

DouglasH 2009-02-16 16:26:44

@Jon: encapsulation limits state change to object-internal properties; at least *some* objects must have mutable state

Christoph 2009-02-16 17:50:52

@Jon You can certainly create a hybrid object-functional framework. But the whole idea behind object-oriented is to simplify complex stateful, sequential programs performing actions.

Justice 2009-02-16 18:03:30

+2 A:

To look at it from a different perspective, most people like to think imperatively (rather than in recursions or RPN). From this follows that most languages will be imperative.

Of course, many problems are much more simple to express (or solve) with a non-imperative approach (for example user interfaces) but most people don't really feel comfortable with this approach. Some don't like to leave the beaten path while others really have trouble to do the mental change necessary to approach problems from this side (thinking in method calls and recursion instead of variables and loops).

Aaron Digulla 2009-02-16 15:20:14

Yes that I can understand, actually getting into understanding some of the Functional language concepts is interesting. Since my background was Fortran, Pascal and C. But to be Honest Functional makes more sense to me from the outside looking in.

DouglasH 2009-02-16 16:04:11

As I said: For some problems, functional programming is much more straightforward, especially when used in an environment where you can mix functional+imperative. Functional-only environments usually ask for a new way of thinking which is hard.

Aaron Digulla 2009-02-17 08:51:21

Some people disagree on OO being an imperative concept, so here's my reasoning.

Object-orientation essentials:

objects hold state (ie references to other objects)
objects receive (and process) messages
processing a message may result in
- messages beeing sent to the object itself or other objects
- a change in the object's state

This means oo-programming requires mutable state held by the object(!). If you simulate state change by creating a series of objects, you're breaking these invariants, simple as that.

Flamebait: If you disagree with this definition of object-orientation, take it up with Alan Kay.

Christoph 2009-02-16 17:48:16

A lot of different concepts contribute to the concept of Object Oriented Programming. Wikipedia lists mosts of them.

I would characterize the essence of OOP by the use of Objects with Behaviours.

Wikipedia characterizes Objects by the following three properties:

Identity: the property of an object that distinguishes it from other objects
State: describes the data stored in the object
Behavior: describes the methods in the object's interface by which the object can be used

A lot of Object Oriented Language have a concept of classes, but actually, there are also Prototype-based languages like JavaScript.

Functional languages may also use classes (e.g. Type Classes in Haskell). But just because they have classes doesn't mean that they are object oriented or allow object oriented programming. To stay with the example of Haskell: You don't even have Objects! There is no such concept as "Identity"! All you can do is composing pure functions!

Just because someone's using a term named "classes", it doesn't mean they're doing object orientated programming!

OOP is about stateful Objects with behaviour. Though the behaviour of objects don't have to modify that object because new objects can be created instead, you'd loose the need of Objects completely. You wouldn't need Identities anymore, because it doesn't matter if the changes to one object are reflected by other references to the same object because there wouldn't be any changes anymore. All you need are Values (without identity) and Modules and/or Classes for data hiding and encapsulation.

So Yes, imperative programming is inherent to OOP.

Thomas Danecker 2009-08-21 10:01:13

Thomas, interesting statements, Considering that Alan Kay doesn't consider C++ and its derivatives (Java, C#) to be in the realm of OO programming languages. and he is the guy who coined the term.

DouglasH 2009-08-29 10:05:13

Alan Kay doesn't consider C++ et al to be in the realm of OOP, because the way the "Behavior"-Part is implemented in them. It's that "sending messages to communicate" part, that's a bit missing in these languages...

Thomas Danecker 2009-08-30 08:42:13

ansaurus

tags:

views:

answers:

Confused. Is OO inherently imperative or is is it multi-paradigm?

related questions