Well, the meanings of terms change over time, and as my old friend Rich Gold likes to say, terms are also "colonized" for political and fad reasons. Personally, I started to regret having coined this phrase almost immediately, in part because "object-oriented" seemed too static. Simula-I used the term "process" to cover both what we mean by "object" and "instance" (since classes were not themselves objects). But this use of "process" was a little different from the already in use definition in the US.

To me, in the beginning, what seemed most important were the encapsulation, only message passing (which allows the algebraic properties of polymorphism), everything made from the basic building block, etc. Doing this right allows some of the other useful abstraction mechanisms to be built. But the abstraction ideas have always been a problem, in that nothing as "clearly sweet" as objects has yet emerged. This has led to quite a profusion of half good ideas about classes or prototypes, inheritance or not or multiple or single, etc.

Finally, my original biology inspired ideas were completely intertwined with late-binding (where I had LISP as a beautiful model of how to generally go about things).

Cheers,

Alan

P.S. Real pioneers have the arrows in their chests!

-------

At 2:10 PM -0400 4/26/02, Kevin Fisher wrote:

I have a bit of a question...I'm just sitting down to learn Python right now and I'm finding it a bit too C/C++ like for my liking. What strikes me about Python is it's claim of "object orientation"--and yet, it has atomic types like 'int' and 'char' that are not objects (shades of C++ and Java).

I've read the quote on smalltalk.org from Alan that (roughly paraphrased) says "I invented the term object-oriented, and C++ was not what I had in mind."

Is it safe to say that something like Python is not truly object-oriented? Or rather--if it's not objective right down to the smallest particle, can it be called object-oriented? I realize this could be a somewhat flameworthy question...but I don't mean it to incite flames.

(and then there's the other question about why all new languages go out of their way to be so C-like...a personal beef of mine. :)

--

If you spend enough time developing in languages like C and C++, BASIC, Pascal, FORTRAN, and COBOL, it changes the way you think. Instead of thinking about the real-world entities that you're trying to represent, you end up jamming these notions into whatever language structure will hold them. After a while, instead of seeing real-world objects when you look out your window, you start seeing data structures and pointers. Your thought processes begin to revolve around the language and its constructs rather than the objects you're trying to model. You spend an inordinate amount of time re-engineering things that are very simple in real life.

The term "object-oriented" is so simple, it amazes me how it's become so complicated to explain! I guess like so many other terms: the more it gets used, the more it gets abused. Pretty soon it's cliché. Anyway, my understanding of an object-oriented language is one where the central focus is the objects themselves, *not* the compiler or interpreter and all of its syntactic rules. Each object should define its own communication protocol. The development environment should merely facilitate your communication with these objects; it shouldn't force you to use a uniform or restrictive protocol. With true object-orientation, writing a program should merely be telling your objects what to do.

If you find yourself spending a lot of time converting your ideas into constructs that the language can work with, or if you have to buy books just to learn the syntax of the language itself, then the language isn't object-oriented. It's language-oriented! :-P :-)

Chris Becker

-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Kevin Fisher Sent: Friday, April 26, 2002 1:10 PM To: squeak-dev Subject: How do you define "object-oriented"?

I have a bit of a question...I'm just sitting down to learn Python right now and I'm finding it a bit too C/C++ like for my liking. What strikes me about Python is it's claim of "object orientation"--and yet, it has atomic types like 'int' and 'char' that are not objects (shades of C++ and Java).

I've read the quote on smalltalk.org from Alan that (roughly paraphrased) says "I invented the term object-oriented, and C++ was not what I had in mind."

Is it safe to say that something like Python is not truly object-oriented? Or rather--if it's not objective right down to the smallest particle, can it be called object-oriented? I realize this could be a somewhat flameworthy question...but I don't mean it to incite flames.

(and then there's the other question about why all new languages go out of their way to be so C-like...a personal beef of mine. :)

Hi Kevin,

I think that VisualBasic, C++, Python, Java are all Object Oriented Languages (OOL), but Smalltalk is not a language and not only Object Oriented. Let me explain...

When you use a Language (OOL), you must "imagine" the objects (you really do not have them). An object system is a powerful product of the work you do in your mind. You formalize the expertise in the destination domain building knowledge structures with the form of objects. The objects are the product of your work and a powerful specification of your system (a closed/defined system). If you work IN an Object Environment (like Smalltalk), the objects contained in the environment are the sources of your work. The environment is the space where you build your system, not its definition. The objects are NOT in your mind, they are in the virtual environment (and can be shared with full precision in abstract and concrete instances).

Why Object Orientation is powerful and very interesting for people with instruction in science? Object Orientation is widely accepted because let people apply all the methods they learned in science and formal training. Most of scientific methods are based on reductionism techniques that treat any "problem" as an object of interest. The reduction of the problem let you define the laws of nature of the problem.

Any system can be treated/defined as an object. (See Bertalanffy laws of information systems) All the techniques related with reductionism and modularization can be applied to OO Systems.

But. You can have more than Object Orientation. More than Object Orientation? What can we have if not an object?

Most people try to mark the differences of Smalltalk saying that smalltalk is "pure objects", and that ALL in smalltalk are objects. I think that when we use these arguments we are not focusing on the most powerful attributes of smalltalk.

Smalltalk is more than Object Oriented. Smalltalk is: 1. - A place full of objects (then you can apply all the reductionism techniques) 2. - It is an ENVIRONMENT.

What I want to say with an "environment"? An environment (as in biology and ecology) is NOT an object; it can not be "solved" with reductionism techniques. An environment is not a container (not an object, not aCollection), because an environment is an open system.

Remember the first law of Information Systems: "A system is more than it parts"

The law enounces that a system are not only its parts, then it is not only objects.

Using an evolving environment as an open medium to develop information systems let's you work with reductionism (with objects) and in a holistic way (with non-objects, or. not only with objects).

Object Oriented Languages let you work only with objects, and when the system is DEFINED it will not evolve. It can change, but not evolve, because it defines a closed system. It is the product of formalism.

Object Environments (OE) like smalltalk have a syntax (language) because we use text panes. (but they are not just the syntax, each object have a language) OE have "classes", but they are really species. See paper "Who put the class into classification" J. Wilkins or an email of smalltalking mailing list [http://groups.yahoo.com/group/smalltalking] of topic "[objetos] Conjuntos - Clases - Especies - etc." if you can read Spanish L They have objects but the instances can change shape and behavior at any time, because they are not fixed to formalization laws (some Smalltalks lets you attach methods to objects -not only to classes-).

Building a system in an open environment is not the same as defining a system with reductionism techniques (cut the real system in parts and look for "relations"). When you work with reductionism you must be formal, strict, and define all the alternatives you can see (learn the domain first, then talk in the language to express the rules). When you use an environment, your main activities are in the building of the system. While building you will work on the undefined/unknown part of the system, you build the system using it. Your activities are different and are not only based on reductionism and formalization.

Using Smalltalk you work in an environment. The main goal is to maintain the environment stable (system correctness is not necessary). As in ecology, your activities are guided by the open parts of the system. All actions done in a reductionism way may produce lateral effects and indeterminism. Accidental emergence can be used to know more on the system while it works. The building of object engines (and in its abstract form: a framework) are emergencies of the advances in the destination domain. As a product of instantiating experience, you build classes (prototypes evolves to a more formal specification in the form of classification schema) and objects. As classes changes with time, they are not "classes" like in OOL. When you work in an evolving environments classes are formalizations (abstractions) but with the possibility to change (more like species in nature).

You can find more on this topics on www.smalltalking.net (sorry but most material is in Spanish and our email list is in Spanish also) and http://smalltalking.swiki.net

I find that focusing on this topics more people are interested in learn and use Smalltalk, and let us learn to work in an environment (open system) and use more than formal methods.

cheers, Ale.

----- Original Message ----- From: "Kevin Fisher" kgf@golden.net To: "squeak-dev" squeak-dev@lists.squeakfoundation.org Sent: Friday, April 26, 2002 3:10 PM Subject: How do you define "object-oriented"?

I have a bit of a question...I'm just sitting down to learn Python right now and I'm finding it a bit too C/C++ like for my liking. What strikes me about Python is it's claim of "object orientation"--and yet, it has atomic types like 'int' and 'char' that are not objects (shades of C++ and Java).

I've read the quote on smalltalk.org from Alan that (roughly paraphrased) says "I invented the term object-oriented, and C++ was not what I had in mind."

Is it safe to say that something like Python is not truly object-oriented? Or rather--if it's not objective right down to the smallest particle, can it be called object-oriented? I realize this could be a somewhat flameworthy question...but I don't mean it to incite flames.

(and then there's the other question about why all new languages go out of their way to be so C-like...a personal beef of mine. :)