Moritz: I started programming in [Perl] and then some [C]. I made heavy use of multi-dimensional arrays to store large amounts of data.
Then when I came to [Python], [PHP] and [Java] I really learned to like the [OO]P approach to programming, making it more easily to handle data, not having to remember the structure of multidimensional arrays.
Now, I just had to think what disadvantages OOP has. What do you think?

Let's distinguish two sorts of disadvantages:
   * OO is often provided through such imperfect vehicles as [C++] and Java [[discuss their defects]]; and
   * OO is inapplicable because [[explain many mismatches]].

----
[Peter Newman] 24 January 2005: To me, the main problem with OO is that some implementations (eg; C++) make it way too complicated and obscure. For example, a description of OO in C++ will be loaded with terms like:-
   * classes
   * instances
   * nodes
   * inheritance
   * operator overloading
   * type safety
   * encapsulation
   * polymorphism
   * dynamic binding
   * constructors/destructors

What the hell is all that crap? And who cares? I just wanna write a program.

But there are simple OO like systems that to me work well:-

   * '''Tk''' for example:-
 label .mLabel
 .myLabel -text "Hello, World!"

where ''.myLabel'', once created can be thought of as an object with ID ''.myLabel'' and property ''-text'', etc. And:-

   * '''Javascript''', which has a simple, useful and easy to understand syntax.

It seems to me that there some important and useful things in OO. But exactly what those useful essentials are, I'm not sure. Tk and Javascript are useful (and used by lots of programmers) - because they obviously use the useful bits. Complicated systems like C++ seem to be rejected by many programmers - in my opinion because they drown the useful bits in a sea of what seems to me to be irrelevant fluff.

But it would be useful to identify exactly what the useful bits of OO were. And thus, in what situations an OO approach is likely to be better/easier than a procedural/command-oriented approach.

----
[Artur Trzewik] '''Tk''' is not object oriented

Many Tcl-er think that the main characterisitc of object orientation is only the parameter order in commands call.
So they show such examples

  # procedural
  close $filehandle
  # object oriented
  $filehandle close

Object orientation is much more (see http://en.wikipedia.org/wiki/Object-oriented_programming).
At least object oriented languages needs inheritance, polymorphism, encapsulation, abstraction and objects.

The main difference between procedural and object oriented programming is that the functional programmer
try to split function and data (data structures). But object oriented programmer think in objects that is
how to hold data und functions (methods) together in one structure.

Because Tcl is string based it also has a kinf of polymorphism.
For example Tk:

  $button -configure text "Text"
  $label -configure text "Text"

It looks like object oriented but indeed Tk does not supports inheritance (anyway Tix try it).
So button and label has no parent class and you can not derive new widget directly from button.

It is quite unproductive to compare Tcl as procedural language with C++ Java as object oriented language.
Because actually you will compare dynamic and static typed langauges.
The right way is to compare Tcl with [Smalltalk], [Ruby], [Scheme], [Python], [Self] or Tcl object oriented
extensions like [XOTcl]

Quite impresiv is to compare Tcl low level API for C und Java Tcl-Interpreter.
The Java API is much more clear and better for understand
http://tcljava.sourceforge.net/docs/TclJavaLib/contents.htm
There is for example one polymorph method Interpreter.setResult() that
accept int, String, doubel and TclObject.

Of course one can write programs without object orientation and
you can write bad object oriented programms (Antipattern: Blob, Spagheti Code, Ghost class)
especially if one comes from procedural programming.

Another interesting thing is that many systems written in procedural languages
build own object oriented systems for structure programm. for example Tix in Tcl or GTK in C.
So object orientation is not only the languages but the way how
structure programs or think about programing (mental work).
Also many Tcl programers use different methods (arrays, namespaces)
for build own pseudo object oriented systems. 
I said "pseudo" because they often does not support all object oriented charcteristic
and are "ad hoc" solutions for one application (reinvent the wheel).
That make it hard for analyse for another programmer.