Object Oriented Programming (OOP) sounded like a really great idea when I first heard about
it.  The goals are lofty: to increase program reliability and decrease coding difficulty
by allowing individual elements of the program to be abstracted from each other.  Also, the
combining of code with the associated data made no little amount of sense.  This was supposed
to decrease program complexity to a manageable level.  Theoretically, all input/output
from an object could be standardised through member functions, allowing each object to
be designed independantly of the others, by different people.

<p>In practice, I don't think this really developed the way it was imagined.  Despite goals
for object reusability stemming from inheritance, many programmers prefer to re-make similar
objects rather than inheriting them.  People tend to reinvent the wheel just as often as before.
Data interfaces tend to be clunky and confusing, and it's just about impossible to diagnose 
errors in an object someone else wrote.  In general, it's quite difficult to debug object
oriented code, because program execution is not always as straightforward.  Procedures are
often called by snippets of code that don't necessarily look like they might invoke functions.

<p>For example,
<pre>
Object o = new Object(100);
</pre>
looks like a simple declaration of a data object.  It also looks like it should take a very
short amount of time, on par with the instantiation of an integer.  In truth, there could
be any number of procedures that get invoked when this command is executed.  Some arguments
may result in longer instantiation times than others.  This object may create and modify
other objects.  In short, it is not sufficient to only consider the input/output functions
of an object, you have to know what it does internally in order to effectively use it, which
invalidates the goal of object abstraction.

<p>Objects also tend to be unwieldy for smallish projects, where just setting the program
set up, say defining what member functions will be available and what arguments they will take,
etc, can take hours, if not more.  

<p>C++ is terrible.  The same program is not garunteed to compile and run under any C++ compiler,
even if using only "pure" C++ code, and no non-standard libraries.  Something that works
in Linux under GCC might not work with SparcWorks compiler on a Sun.  Sometimes you have to
insert statements which "do nothing" into C++ code to make it work.  For example, I had
C++ programs which would get "stuck" for no reason.  Inserting a
<pre>
cout << "";
</pre>
would sometimes fix everything!  The pointer/memory management available in C++ is about the
worst thing I've ever seen.  I don't think there exists a programmer who can write code
that doesn't leak memory in some way or another, or that is not prone to an occaisonal segfault
when dealing with a lot of pointers.

<p>Java is a little better than C++.  It provides transparent access to pointers, a graphical
interface (crippled though it may be), and a somewhat simplified syntax.  It also provided
a pedantically correct (and therefore alost useless) set of methods and objects. Why would
anyone want to use a statement like
<pre>
(Java Version)
Math.min(20, Math.round( im.getWidth() * 1.3 / resultCol ))); 	
</pre>
when they could use something more like
<pre>
(TCL Version)
expr min(20, round([ getWidth ] * 1.3 / resultCol))
</pre>