George Rudolph wrote:
George Rudolph wrote:
I am no longer convinced that object-orientation is really a separate
paradigm from imperative programming.
A very useful design pattern yes, but not necessarily a separate
paradigm.
You could arrived to this conclusion if you just consider Java and C++
as object-oriented programming languages. There you can write programs
without a single object. But, if you want to conclude something about
OOP, at least you have to consider languages like SmallTalk, where the
paradigm is very simple and well defined: Everything is an object, and
objects send message to each other.
I agree with what you say about Java and C++, but that is not the basis of
my statement. Rather, consider what makes a language imperative:
1. Turing Completeness
2. Control Structures
3. I/O
4. Error & Exception Handling
5. Procedural Abstraction
6. Expressions and Assignment Statements
7. Library Support for Data Structures
with emphasis perhaps on Procedural Abstraction, Assignment Statements and
Control Structures.
If OO adds anything to this, it would be to formalize Data Abstraction--but
is that enough to make it a separate paradigm? Because, fundamentally,
including Smalltalk, assigning methods to objects and writing methods is
procedural abstraction, nothing more. And method bodies are implemented
algorithmically using imperative control structures and assignments.
Hi George
I agree with the fact that OOP can be built on top of imperative
programming, but it could also be built on top plain functional
programming as an abstraction where every object is represented as a
closure with encapsulated state. My argument to consider it as a
programming paradigm, it's that you can take the simple foundations and
conceive your programs in a different way.
For instance, 5 + 8 can be seen as an arithmetic function, but a
SmallTalk programmer would tell you that 5 + 8 is a message + sent to
the object 5, having 8 as an argument. If 5 is an object representing an
integer, the result of this message will be 13, but if 5 represents an
hexadecimal number, then + would have been implemented in a different
way, and would result into the C object.
Another example is the 'if' statement. In imperative programming, that
would be a control flow operation. In OOP, 'if' is a message sent to a
boolean object. If the object happens to be true, it will execute the
first argument. If it is false, it will execute the second one. That's
because the paradigm says that "everything is an object, and they just
send messages between them". You can have several implementation of this
paradigm, but I think OOP deserves to be a paradigm on his own.
It is known that passing a message between objects or calling a
method/function are functionally equivalent. And if a person only looks at
Java or C++ or Smalltalk, or any number of OO languages, it could give the
impression that message-passing is always implemented as a method/procedure
call.
This thinking is what led to my statement.
That's really a programming paradigm, not just a design pattern. In
fact, you can build imperative programming on top OOP.
cheers
Boriss
I do not exclude Smalltalk
OK. The reason why I mention SmallTalk is because they are really close
to the definition of the paradigm, and I think that the body of their
methods can really be considered OOP and not just imperative. That's
what I tried to show with the example of 5+8 and the if message.
cheers
Boriss
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On
Behalf Of Peter Van Roy
Sent: Wednesday, March 28, 2007 10:51 AM
To: Mark Miller
Cc: Mozart users
Subject: Re: Overview of principal programming paradigms
Mark Miller wrote:
Peter VAN ROY wrote:
Dear all,
I've made a diagram showing all major programming paradigms
and their relationships:
- http://www.info.ucl.ac.be/people/PVR/paradigmsDIAGRAM.pdf
Unfortunately it's in French and I don't have time right now
to translate it into English. I made it for a keynote talk
I will be giving in June at IRCAM, the computer music institute
in Paris. I hope the diagram will still be interesting for you
(and if someone wants to translate it into English, feel free!).
All comments are welcome of course.
Is the object-capability paradigm represented?
Yes, I think so. According to the diagram, E supports two paradigms:
secure functional programming (using seal/unseal actually, which allows
building secure ADTs) and programming with active objects. E actually
is more serious about multi-agent programming than other systems, which
leads to its good security. The degree of "seriousness" is not shown
on
the diagram.
Do you think that "object-capability" deserves its own box? If so, how
does
it link to existing boxes?
Peter
__________________________________________________________________________
_______
mozart-users mailing list mozart-
[EMAIL PROTECTED]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
__________________________________________________________________________
_______
mozart-users mailing list mozart-
[EMAIL PROTECTED]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
__________________________________________________________________________
_______
mozart-users mailing list mozart-
[EMAIL PROTECTED]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
