FAQ

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.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2022 Grokbase