objects = doing things twice

Java and C++ are both object-oriented languages. The first question you ask to yourself before writing a program is: "Shall I use an object-oriented language or not?". The C language, for example, is not. So C++ is a relative of Java and not of C. C is beautiful like the game of chess and for the same reason: you learn the rules in one afternoon, but with those few rules you can create endless situations.
OOP (object oriented programming) was introduced to create large programs and to make the code reusable. If you are a programmer and write a program composed by 200 objects, chances are that the next program can contain (reuse) 40 or 50 of those objects.
In practice you start from an available multi-purpose library of objects and build on that one. You have the source code of the library, so everything seems OK. What if, after two years, you are forced to switch to another operative system? You need the port the whole library to it. An impossible task for a single programmer. And what if you want to change language? Every year I hear about a new language, and every time it seems the non-plus-ultra: Perl, Java, Objective C, Python, Ruby. Strangely enough, the object libraries, like SWING, SWT, QT, MFC, TCL, OWL, are far less cited. Cocoa is cited as a set of API, but it's also a library (actually a framework, but it makes no difference into this context). A programmer learns a language in one day and a library of objects in one year. He is much more concentrated on the latter than on the former. Strangely, fame goes to the languages.
I wrote a few programs with Symantec's TCL in the 90s and they were very important to me. Today Symantec is still alive, while the Think Class Library is dead and forgotten. You can easily guess that all my code is NOT reusable and it's no consolation at all to still hear and read that OOP code is reusable. Mine is not. If had always written in ANSI-C, then all my code would really be reusable and portable. You can guess which language I am using today!
Another important feature about OOP is that it requires planning. (They all say this). Strangely enough, nobody states that planning requires expertise of the library and deep knowledge both of the problem to solve and of the future users of the program. If NMR is a vast field, there is no program to take as a model (they are generally flawed; if the existing programs were not so flawed, there would be no reason at all to write yet another one), your experience will grow while making the program. Nor you can have the expertise, because every time you start a major program, you are faced with a new operative system, a new programming language, a new library of objects. The only _honest_ planning you can start with is: let me write a program for myself. When I am finished with it I will be an expert. Then I will throw my work into the dustbin and start all over again with another program. That second program will se the market.
This time-wasting strategy is actually both the best one and the most followed one, even in procedural programming (that's how many non OOP languages are called). The good, and at the same time the bad, thing of C, in this respect, is that sometimes you can rescue the first attempt by changing, let's say, only 20 lines of code. The problem is that those 20 lines are disseminated among other 20 thousands lines, which it's better if you read again, them all.
They also says that C is unreadable. It's not necessarily so. Like hand-writing, if you write slowly, with care, you can produce a perfectly readable code. At least it will be readable for yourself, and that's the only things that matters. If you stick consistently to the same style, if you don't exceed with the macros, if you don't put #include statements into headers, if there are comments, C is the most readable of all languages. And does not eat memory.