3

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?

Svante
  • 50,694
  • 11
  • 78
  • 122
DouglasH
  • 1,216
  • 9
  • 12

7 Answers7

14

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.

user21714
  • 5,781
  • 1
  • 20
  • 26
  • 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 Feb 16 '09 at 15:13
  • @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. – user21714 Feb 16 '09 at 15:24
  • 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 Feb 16 '09 at 16:25
  • @Christoph, OP never mentioned anything about requiring functional languages to be pure-functional. Your view of OO is too narrow. – user21714 Feb 16 '09 at 16:35
  • @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 Feb 16 '09 at 17:44
  • 1
    @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. – user21714 Feb 16 '09 at 18:31
  • @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 Feb 16 '09 at 18:38
  • 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 Feb 16 '09 at 19:11
  • @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. – user21714 Feb 16 '09 at 21:00
  • stbuton: That's fair. I would also accept "metacircularly awesometastic". :-) – Ken Feb 16 '09 at 21:33
  • 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 Feb 17 '09 at 19:10
  • @Aaron: try making all classes in the C#/Java standard library immutable, see how well that works out; data hiding + polymorphism != oop – Christoph Feb 23 '09 at 16:38
  • 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 Feb 23 '09 at 16:39
  • 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. – user21714 Feb 23 '09 at 18:09
  • 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. – user21714 Feb 23 '09 at 18:11
  • @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 Feb 23 '09 at 18:57
  • 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 Feb 23 '09 at 19:03
  • 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 Feb 23 '09 at 19:34
  • see also http://community.schemewiki.org/?object-oriented-programming - most common definitions of oo are more restrictive than yours – Christoph Feb 23 '09 at 20:04
  • 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. – user21714 Feb 23 '09 at 20:31
  • @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 Feb 24 '09 at 18:50
  • 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. – user21714 Feb 24 '09 at 21:23
  • 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 Feb 25 '09 at 11:29
  • 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. – user21714 Feb 25 '09 at 14:07
  • 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. – user21714 Feb 25 '09 at 14:17
  • @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 Feb 25 '09 at 15:20
  • 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. – user21714 Feb 25 '09 at 15:44
  • 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. – user21714 Feb 25 '09 at 15:47
  • 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. – J D Apr 13 '09 at 00:10
6

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
  • 1,421,763
  • 867
  • 9,128
  • 9,194
4

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

yfeldblum
  • 65,165
  • 12
  • 129
  • 169
  • 1
    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 Feb 16 '09 at 16:26
  • 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 Feb 16 '09 at 16:26
  • @Jon: encapsulation limits state change to object-internal properties; at least *some* objects must have mutable state – Christoph Feb 16 '09 at 17:50
  • @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. – yfeldblum Feb 16 '09 at 18:03
2

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.

Community
  • 1
  • 1
Christoph
  • 164,997
  • 36
  • 182
  • 240
2

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
  • 321,842
  • 108
  • 597
  • 820
  • 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 Feb 16 '09 at 16:04
  • 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 Feb 17 '09 at 08:51
0

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.

Thomas Danecker
  • 4,635
  • 4
  • 32
  • 31
  • 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 Aug 29 '09 at 10:05
  • 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 Aug 30 '09 at 08:42
0

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.

Christoph
  • 164,997
  • 36
  • 182
  • 240