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

Question

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?

Answer 1

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.

Answer 2

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.)

Answer 3

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).

Answer 4

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).

Answer 5

I still firmly believe that object-orientation is an inherently imperative concept. However, as a recent question made me think some more about programming paradigms in general, I put together a more comprehensive answer, which is somewhat off-topic, but incidentally also answers your question:

The 2 major programming paradigms are the declarative paradigm, where the programmer writes down abstract relations (thus telling the compiler what he wants), and the imperative paradigm, where the programmer writes down algorithms (thus telling the computer how to get what he wants).

The paradigms are a priori language-agnostic - it's more of a way on how you think about and structure your program. However, there are differences in how easy a language makes it to use a paradigm: Language semantics and syntax lead to an idiomatic way of writing code.

An example for a declarative language would be Prolog, an example for an imperative language would be Fortran (and Real Programmer can write FORTRAN programs in any language).

As an example for code which is imperative and declarative at the same time, consider this implementation of the Fibonnaci-sequence in Perl6:

my @fibonacci-sequence := 0, 1, * + * ... *;

This is clearly a declarative description of the sequence. However, as * and ... are valid Perl6 operators - the whatever-star can be used to create lambda-expressions, the sequence-operator to create lazy lists - it's also an imperative statement invoking runtime-intrinsic code.

Let's consider some other programming paradigms, in particular functional and object-oriented programming.

The functional paradigm is inherently declarative, as it models computation as a relation between sets.

The object-oriented paradigm is inherently imperative, as it models computation as communication between stateful objects, called message passing.

Some languages are pure, meaning all computation conforms to the paradigm. For example, Haskell is a purely functional language, and Smalltalk is a purely object-oriented language.

However, this doesn't mean that that functional languages resp. object-oriented languages prevent imperative resp. declarative programming. In practice, you often use functions imperatively - you put in an input value to get out an output value. The converse holds true for object-oriented programming: the set of messages an object accepts declares its interface.

Answer 6

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

Object-orientation essentials:

1. objects hold state (ie references to other objects)
2. objects receive (and process) messages
3. 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.

Answer 7

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:

1. Identity: the property of an object that distinguishes it from other objects
2. State: describes the data stored in the object
3. 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.