On 7/24/2015 8:38 PM, Joel Roth wrote:
Hi T.J. and others,
I've been following this thread with some interest.
T.J., it seems most of your objections to OOP are not
strictly against the principles and advantages of OOP in
abstract, but against the way OOP is implemented in C and
C++.
With respect, I disagree.
My problems with OOP pretty much apply to every single OOP language I
have ever used, because 90% of the OOP paradigm is flawed. I have no
problem with certain things. Some examples would namespaces or
polymorphism if they are handled sanely. Much of OOP - things like duck
typing, exceptions and inheritance are actually moving backward. They
obfuscate code and introduce points of failure that cannot possibly be
detected or tested for. The whole point of programming is to produce
reliable code. There is precisely zero evidence that OOP has produced
code that is actually any more reliable than previous methods.
In fact, some of OOP's usual features produce code that is less
reliable, more resource intensive, or both. Companies like Google
specifically ban their programmers from using certain things, like
exceptions, even if they are programming in C++. The Clang Project does
not accept contributions that use exceptions or RTTI - even though it is
primarily a C++ compiler.
As a programmer in a dynamic garbage-collected language,
I find most of these objections don't apply.
I have a special dislike reserved for those languages that force you to
use a garbage collector. I can tolerate them if I can override it.
Constructors and destructors are a helpful convention to
ensure objects get initialized and cleaned up properly.
Constructors (and destructors) in most OOP languages are a bloody
disaster. Because most constructors cannot return values, you can't
exit cleanly without throwing an exception. Throwing an exception means
that unless you catch it inside of the constructor. If you don't, any
resources you allocated for your object are not guaranteed to be
released cleanly. This is especially important in OOP languages with GC
where you are probably accessing libraries that have unmanaged code.
Then you have to throw it again in order to tell the calling class it
failed. Catching it and then throwing it again means that you lose
vital debugging data on the stack trace.
Either way, you lose.
I never use constructors or destructors in my code, and I find that I am
better off in all cases.
Working on an application that has grown to about 20k lines,
OOP is the only way I've been able to manage.
Try that when it gets to 2 million, including dependencies. When you
reach that point, I will agree OOP can be somewhat helpful. I don't
hate OOP entirely, but I do NOT believe that what we presently use makes
for better code. Features even if they are part of the language
standard should be evaluated for real world usefulness.
Perhaps I misunderstand your complaints, or perhaps I'm
fortunate to be using a language where those complaints
are less applicable.
That's okay. Everyone is entitled to their views. Just because I've
been kicking this around a long time does not make me right. Use what
you think best.
Take care!
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
