lies about OOP

[Daniel T.]

beliavsky at aol.com wrote:

> A paper finding that OOP can lead to more buggy software is at
> http://www.leshatton.org/IEEE_Soft_98a.html

Sure, OOP *can* lead to more buggy software, that doesn't mean it always 
does.


> Les Hatton "Does OO sync with the way we think?", IEEE Software, 15(3),
> p.46-54
> "This paper argues from real data that OO based systems written in C++
> appear to increase the cost of fixing defects significantly when
> compared with systems written in either C or Pascal. It goes on to
> suggest that at least some aspects of OO, for example inheritance, do
> not fit well with the way we make mistakes."

So, he has data that shows that C++ *appears* to increase the cost of 
fixing defects, then *suggests* that its because C++ is an OO language? 
Sounds like he is ignoring his own data to me...

Mr. Hatton suffers from the same problem that many OO critics suffer. He 
thinks that the language choice decides whether the program written is 
an OO program. I've seen plenty of very non-OO systems written in OO 
languages, I've seen expert OO systems written in non-OO languages. OOP 
isn't a language choice, it is a style of problem solving.

I'm happy to accept that it could take longer to fix bugs in programs 
written in C++ when compared to either C or Pascal, the language itself 
is quite a bit more complicated than either of the latter. 

You know, it tends to take longer to repair a 2004 Mustang than it does 
a 1964 Mustang, does that mean the newer car is not as good?


> If OOP is so beneficial for large projects, why are the Linux kernel,
> the interpreters for Perl and Python, and most compilers I know written
> in C rather than C++?

All three of the systems in question were begun before C++ was 
standardized. Python was also implemented in Java, does that mean OO 
other than C++ is good? Of course not, the fact that the three projects 
in question were implemented in C is not an indictment against OO in any 
way.