lies about OOP

[Miki Tebeka]

Re: lies about OOP

Hello projecktzero,
[color=blue]
> A co-worker considers himself "old school" in that he hasn't seen the
> light of OOP.(It might be because he's in love with Perl...but that's
> another story.) He thinks that OOP has more overhead and is slower than
> programs written the procedural way. I poked around google, but I don't
> know the magic words to put in to prove or disprove his assertion. Can
> anyone point me toward some resources?[/color]
Try http://www.dreamsongs.com/Essays.html (search for "Objects Have Failed")
for an interesting discussion.

Bye.
--
------------------------------------------------------------------------
Miki Tebeka <miki.tebeka@zo ran.com>

http://tebeka.bizhat.com

The only difference between children and adults is the price of the toys

[sbassi@gmail.com]

Re: lies about OOP

Hello,

Instead of copy and paste, I use functions for code reuse. I didn't see
the light of OOP, yet. I use Python but never did anything with OOP. I
just can't see what can be done with OOP taht can't be done with
standart procedural programing.

[Peter Hansen]

Re: lies about OOP

sbassi@gmail.co m wrote:[color=blue]
> I just can't see what can be done with OOP taht can't be done with
> standart procedural programing.[/color]

Well, there's absolutely nothing you can do with OOP that
can't be done with "standard procedural programming" (SPP).

But that's hardly the point. After all, anything you can
do with OOP or SPP can be done with assembly language as
well.

OOP is way of approaching the design and construction of
the software. As a starting point, consider the advantages
of procedural programming over using raw assembly language.

Now consider that there might be similar advantages in
using OOP instead of procedural programming.

And, lastly, to bring this on topic for this forum, consider
that there might be advantages in using *Python*, specifically,
for doing this OOP programming, compared to many other
languages. Not that you can do things in Python you can't
do in other languages (such as, say, assembly). Just that
you can do them much more easily, and the resulting code
will be much more readable to you and others.

(To be fair, for certain tasks using OOP provides basically
no advantages, and in fact might represent a more awkward
model for the code than a simple procedural program would.
If that's the sort of program you are faced with writing,
by all means stick with SPP and leave OOP to those who
write complex applications that really benefit from it.)

-Peter

[Stefan Seefeld]

Re: lies about OOP

Craig Ringer wrote:[color=blue]
> On Tue, 2004-12-14 at 16:02, Mike Thompson wrote:
>
>[color=green][color=darkred]
>>>I would pick the publication of "Design Patterns" in 1995 by the Gang of
>>>Four (Gamma, Helm, Johnson, and Vlissides), to be the herald of when "the
>>>Joy of OOP" would be "widely known." DP formalized a taxonomy for many of
>>>the heuristics that had evolved only intuitively up until then. Its
>>>emergence reflects a general maturation of concept and practice, sufficient
>>>to say that the Joy of OOP could be said to be "widely known."[/color][/color]
>
>[color=green]
>>In actual fact, virtually all the design patterns came from the
>>Interviews C++ GUI toolkit written in the early '90s. What an utterly
>>brilliant piece of work that was.[/color]
>
>
> As somebody who has just been bowled over by how well Qt works, and how
> it seems to make OOP in C++ work "right" (introspection, properties,
> etc), I'd be interested in knowing what the similarities or lack thereof
> between Qt and Interviews are.[/color]

Qt provides widgets that a client app. can compose into a GUI.
InterViews provides 'glyphs'[*] that form a scene graph in a display
server. Although InterViews usually was compiled into a client-side
library, it provided all the functionality required by a display server
such as redisplay and pick traversals. Indeed, the X Consortium
supported InterViews (and its successor Fresco) for a while as the next
generation for its 'X Windowing System', until it was dropped (for
mostly political reasons, as usual) about '95.
(Fresco had been nominated, together with OpenDoc, as candidates for an
'Compound Document Architecture' RFP on the Object Management Group.
OpenDoc won.)
[*] The term 'glyph' reflexts the fact that the scene graph nodes in
InterViews are extremely fine-grained, i.e. glyphs can represent
individual characters or elements of vector graphics such as paths.
That's unlike any conventional 'toolkit' such as Qt, where a 'widget'
is quite coarse-grained, and the display of such 'widgets' is typically
not that of a structured graphic, but procedural.

Regards,
Stefan

[Steve Holden]

Re: lies about OOP

Paul McGuire wrote:
[color=blue]
> "Jive" <someone@micros oft.com> wrote in message
> news:Revvd.8078 43$SM5.50718@ne ws.easynews.com ...
>
> <snip>
>[color=green]
>>But by '86, the Joy of OOP was widely known.
>>[/color]
>
>
> "Widely known"? Errr? In 1986, "object-oriented" programming was barely
> marketing-speak. Computing hardware in the mid-80's just wasn't up to the
> task of dealing with OO memory and "messaging" overhead. Apple Macs were
> still coding in C and Forth. Borland didn't ship Turbo-Pascal with
> Object-Oriented programming until 1989, and Turbo-C++ shipped in 1991.
> Smalltalk had been around for 10 years by 1986, but it was still a
> curiosity, hardly "widely known." It wasn't until the publication of David
> Taylor's "Object Technology: A Manager's Guide" in 1990 that OOP began to be
> legitimized to many management decision makers, that it was more than just
> "fairy dust" (as Bill Gates had characterized it in an attempt to discredit
> Borland's forays into the field).
>[/color]
Well, that's not true either, and the fact that Bill Gates was
denigrating it implies that he at least knew about it, even if he chose
not to adopt it (then: of course nowadays Microsoft call almost all
their technologies "object oriented"; sometimes this description is as
accurate as when Gates speaks about "our open Windows environment").
[color=blue]
> I would pick the publication of "Design Patterns" in 1995 by the Gang of
> Four (Gamma, Helm, Johnson, and Vlissides), to be the herald of when "the
> Joy of OOP" would be "widely known." DP formalized a taxonomy for many of
> the heuristics that had evolved only intuitively up until then. Its
> emergence reflects a general maturation of concept and practice, sufficient
> to say that the Joy of OOP could be said to be "widely known."
>[/color]
We could all make our own choices, but anyone who's been programming
*seriously* since the 60s will likely remember Simula as the birth of
many oft he ideas later picked up by Alan Kay and promoted by the Xerox
PARC SmallTalk group.

I visited that group in 1981 (after Kay left, unfortunately, and then
being headed by Adele Goldberg, who is now coincidentally promoting the
delights of Python at conferences like OSCON), and object-oriented
programming was certainly something that was being taken pretty
seriously in the academic world as a potential solution to some serious
PLIT engineering problems.

The fact that it took the technology a relatively long time to appear
"in the wild", so to speak, is simply the natural maturation of any new
technology. Given that UNIX was developed in the early 1970s I'd say it
took UNIX 20 years to start becoming mainstream. But a lot of people
knew about it before it *became* mainstream, especially those who had to
place their technology bets early. The same is true of object-oriented
concepts.

I guess this is just to say that I'd dispute your contention that
SmallTalk was a curiosity - unless you define anything of interest
mostly to the academic world as a curiosity, in which case there's no
way to overcome your objection. It was the first major implementation of
an entire system based exclusively on OO programming concepts and, while
far from ideal, was a seminal precursor to today's object-oriented systems.

regards
Steve

--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119

[beliavsky@aol.com]

Re: lies about OOP

A paper finding that OOP can lead to more buggy software is at

http://www.leshatton.org/IEEE_Soft_98a.html

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."

His comments under "invited feedback" are amusing and confirm my
impression that OOP is partly (but perhaps not entirely) hype:

"I should not that this paper because it criticised OO had an unusually
turbulent review period. 2 reviewers said they would cut their throats
if it was published and 3 said the opposite. The paper was only
published if the OO community could publish a rebuttal. I found this
very amusing as my paper contains significant data. The rebuttal had
none. This sort of thing is normal in software engineering which mostly
operates in a measurement-free zone."

What papers have scientific evidence for OOP?

Paul Graham's skeptical comments on OOP are at
http://www.paulgraham.com/noop.html .

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++?

[Paul McGuire]

Re: lies about OOP

"Steve Holden" <steve@holdenwe b.com> wrote in message
news:29Evd.3259 1$Jk5.26287@lak eread01...[color=blue]
> Paul McGuire wrote:
>[color=green]
> > "Jive" <someone@micros oft.com> wrote in message
> > news:Revvd.8078 43$SM5.50718@ne ws.easynews.com ...
> >
> > <snip>
> >[color=darkred]
> >>But by '86, the Joy of OOP was widely known.
> >>[/color]
> >
> >
> > "Widely known"? Errr? In 1986, "object-oriented" programming was[/color][/color]
barely[color=blue][color=green]
> > marketing-speak. Computing hardware in the mid-80's just wasn't up to[/color][/color]
the[color=blue][color=green]
> > task of dealing with OO memory and "messaging" overhead. Apple Macs[/color][/color]
were[color=blue][color=green]
> > still coding in C and Forth. Borland didn't ship Turbo-Pascal with
> > Object-Oriented programming until 1989, and Turbo-C++ shipped in 1991.
> > Smalltalk had been around for 10 years by 1986, but it was still a
> > curiosity, hardly "widely known." It wasn't until the publication of[/color][/color]
David[color=blue][color=green]
> > Taylor's "Object Technology: A Manager's Guide" in 1990 that OOP began[/color][/color]
to be[color=blue][color=green]
> > legitimized to many management decision makers, that it was more than[/color][/color]
just[color=blue][color=green]
> > "fairy dust" (as Bill Gates had characterized it in an attempt to[/color][/color]
discredit[color=blue][color=green]
> > Borland's forays into the field).
> >[/color]
> Well, that's not true either, and the fact that Bill Gates was
> denigrating it implies that he at least knew about it, even if he chose
> not to adopt it (then: of course nowadays Microsoft call almost all
> their technologies "object oriented"; sometimes this description is as
> accurate as when Gates speaks about "our open Windows environment").
>[color=green]
> > I would pick the publication of "Design Patterns" in 1995 by the Gang of
> > Four (Gamma, Helm, Johnson, and Vlissides), to be the herald of when[/color][/color]
"the[color=blue][color=green]
> > Joy of OOP" would be "widely known." DP formalized a taxonomy for many[/color][/color]
of[color=blue][color=green]
> > the heuristics that had evolved only intuitively up until then. Its
> > emergence reflects a general maturation of concept and practice,[/color][/color]
sufficient[color=blue][color=green]
> > to say that the Joy of OOP could be said to be "widely known."
> >[/color]
> We could all make our own choices, but anyone who's been programming
> *seriously* since the 60s will likely remember Simula as the birth of
> many oft he ideas later picked up by Alan Kay and promoted by the Xerox
> PARC SmallTalk group.
>
> I visited that group in 1981 (after Kay left, unfortunately, and then
> being headed by Adele Goldberg, who is now coincidentally promoting the
> delights of Python at conferences like OSCON), and object-oriented
> programming was certainly something that was being taken pretty
> seriously in the academic world as a potential solution to some serious
> PLIT engineering problems.
>
> The fact that it took the technology a relatively long time to appear
> "in the wild", so to speak, is simply the natural maturation of any new
> technology. Given that UNIX was developed in the early 1970s I'd say it
> took UNIX 20 years to start becoming mainstream. But a lot of people
> knew about it before it *became* mainstream, especially those who had to
> place their technology bets early. The same is true of object-oriented
> concepts.
>
> I guess this is just to say that I'd dispute your contention that
> SmallTalk was a curiosity - unless you define anything of interest
> mostly to the academic world as a curiosity, in which case there's no
> way to overcome your objection. It was the first major implementation of
> an entire system based exclusively on OO programming concepts and, while
> far from ideal, was a seminal precursor to today's object-oriented[/color]
systems.[color=blue]
>
> regards
> Steve
>
> --
> Steve Holden http://www.holdenweb.com/
> Python Web Programming http://pydish.holdenweb.com/
> Holden Web LLC +1 703 861 4237 +1 800 494 3119[/color]

Good points all. And yes, I recall the BYTE article on Smalltalk. I guess
I was just reacting mostly to the OP's statement that "by '86 the Joy of OOP
was widely known". He didn't say "OOP all began when..." or "OOP was widely
known," which I think still would have been a stretch - he implied that by
'86 OOP was widely recognized as Goodness, to which I disagree. This was
the year of the first OOPSLA conference, but as PyCon people know, just
having a conference doesn't guarantee that a technology is widely and
joyfully accepted. Just as my commercial-centric view may understate
academic interest in some topics, an academic-centric view may overestimate
the impact of topics that are ripe for research, or technically "cool," but
little understood or adopted outside of a university setting.

I would characterize the 80's as the transitional decade from structured
programming (which really started to hit its stride when Djikstra published
"Use of GOTO Considered Harmful") to OOP, and that OOP wasn't really
"joyful" until the early-to-mid 90's.

(And I apologize for characterizing Smalltalk as a "curiosity. " I admit my
bias is for software that is widely commercially deployed, and even the most
ardent Smalltalkers will have difficulty citing more than a handful of
applications, compared to C,C++,VB,COBOL, Delphi, etc. I personally have
seen Smalltalk-based factory control and automation systems, but they are
rapidly self-marginalizing, and new customers are extremely reluctant to
enfold Smalltalk into an already patchwork mix of technologies, as is
typically found in factory settings.)

-- Paul

[Steve Holden]

Re: lies about OOP

Paul McGuire wrote:
[color=blue]
> "Steve Holden" <steve@holdenwe b.com> wrote in message
> news:29Evd.3259 1$Jk5.26287@lak eread01...
>[/color]
[some stuff][color=blue]
>
>
> Good points all. And yes, I recall the BYTE article on Smalltalk. I guess
> I was just reacting mostly to the OP's statement that "by '86 the Joy of OOP
> was widely known". He didn't say "OOP all began when..." or "OOP was widely
> known," which I think still would have been a stretch - he implied that by
> '86 OOP was widely recognized as Goodness, to which I disagree. This was
> the year of the first OOPSLA conference, but as PyCon people know, just
> having a conference doesn't guarantee that a technology is widely and
> joyfully accepted. Just as my commercial-centric view may understate
> academic interest in some topics, an academic-centric view may overestimate
> the impact of topics that are ripe for research, or technically "cool," but
> little understood or adopted outside of a university setting.
>
> I would characterize the 80's as the transitional decade from structured
> programming (which really started to hit its stride when Djikstra published
> "Use of GOTO Considered Harmful") to OOP, and that OOP wasn't really
> "joyful" until the early-to-mid 90's.
>
> (And I apologize for characterizing Smalltalk as a "curiosity. " I admit my
> bias is for software that is widely commercially deployed, and even the most
> ardent Smalltalkers will have difficulty citing more than a handful of
> applications, compared to C,C++,VB,COBOL, Delphi, etc. I personally have
> seen Smalltalk-based factory control and automation systems, but they are
> rapidly self-marginalizing, and new customers are extremely reluctant to
> enfold Smalltalk into an already patchwork mix of technologies, as is
> typically found in factory settings.)
>[/color]

Nothing to disagree with here.

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119

[Steve Holden]

Re: lies about OOP

Paul McGuire wrote:
[color=blue]
> "Steve Holden" <steve@holdenwe b.com> wrote in message
> news:29Evd.3259 1$Jk5.26287@lak eread01...
>[/color]
[some stuff][color=blue]
>
>
> Good points all. And yes, I recall the BYTE article on Smalltalk. I guess
> I was just reacting mostly to the OP's statement that "by '86 the Joy of OOP
> was widely known". He didn't say "OOP all began when..." or "OOP was widely
> known," which I think still would have been a stretch - he implied that by
> '86 OOP was widely recognized as Goodness, to which I disagree. This was
> the year of the first OOPSLA conference, but as PyCon people know, just
> having a conference doesn't guarantee that a technology is widely and
> joyfully accepted. Just as my commercial-centric view may understate
> academic interest in some topics, an academic-centric view may overestimate
> the impact of topics that are ripe for research, or technically "cool," but
> little understood or adopted outside of a university setting.
>
> I would characterize the 80's as the transitional decade from structured
> programming (which really started to hit its stride when Djikstra published
> "Use of GOTO Considered Harmful") to OOP, and that OOP wasn't really
> "joyful" until the early-to-mid 90's.
>
> (And I apologize for characterizing Smalltalk as a "curiosity. " I admit my
> bias is for software that is widely commercially deployed, and even the most
> ardent Smalltalkers will have difficulty citing more than a handful of
> applications, compared to C,C++,VB,COBOL, Delphi, etc. I personally have
> seen Smalltalk-based factory control and automation systems, but they are
> rapidly self-marginalizing, and new customers are extremely reluctant to
> enfold Smalltalk into an already patchwork mix of technologies, as is
> typically found in factory settings.)
>[/color]

Nothing to disagree with here.

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119

[Jarek Zgoda]

Re: lies about OOP

projecktzero wrote:
[color=blue]
> A co-worker considers himself "old school" in that he hasn't seen the
> light of OOP.(It might be because he's in love with Perl...but that's
> another story.) He thinks that OOP has more overhead and is slower than
> programs written the procedural way. I poked around google, but I don't
> know the magic words to put in to prove or disprove his assertion. Can
> anyone point me toward some resources?[/color]

There's no magic in OOP. It's just more natural to human nature, so you
should point your friend to works of Aristotle or Sancti Thomae
Aquinatis, specially their writings on "natural sciences" and theory of
species.

--
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

[Tomas Christiansen]

Re: lies about OOP

projecktzero wrote:[color=blue]
> A co-worker considers himself "old school" in that he hasn't seen the
> light of OOP ... He thinks that OOP has more overhead and is slower
> than programs written the procedural way.[/color]

He may be right, but consider the alternatives.

Think of an integer. An integer is an object!

You can assign a new integer-value to the object.
You can read the integer-value of the object.
(The integer can be part of complex expressions.)

Usually you are unaware (or don't care) _how_ the object is implemented.
Wether the bits are red, green, turns upside-down or are inverted - you
doesn't really care, as long as it can hold the values that you want it to
hold and be used in the relevant contexts (addition, multiplication, ...).

Some lanugages gives you the choise of many integer-implementations , some
languages gives you only a few choises and some languages gives you only one
choise.

Surely we can agree that the presence of an integer-object is extremely
useful! If you had to do all the integer-stuff in machine code _every_ time,
you would soon be very, very tired of working with integers. There is no
doubt that objects are (or can be) extremely useful, time-saving and very
efficient. Chances are that your own machine-code integer-inplementation is
not nearly as good as the one made by a team of top-tuned programmers (no
offense) programming the integer-implementation "object".

Wether the language should give you the choise of one, some, many or
extremely many integer-implementations , depends entirely on your needs
("what a pervert - he needs an integer!"). Lowering the number of choises of
implementations , rises the chances of having to chose a "not very good"
implementation. Letting the language automaticly chose the right one, frees
your mind to other processes, but at the risk of some kind of run-time
overhead.

-------
Tomas

[Terry Reedy]

Re: lies about OOP


I did not really 'get' OOP until after learning Python. The relatively
simple but powerful user class model made more sense to me than C++. So
introducing someone to Python, where OOP is a choice, not a mandate, is how
*I* would introduce a procedural programmer to the subject. YMMV.

Terry J. Reedy

[Roy Smith]

Re: lies about OOP

Terry Reedy <tjreedy@udel.e du> wrote:[color=blue]
> I did not really 'get' OOP until after learning Python. The
> relatively simple but powerful user class model made more sense to
> me than C++. So introducing someone to Python, where OOP is a
> choice, not a mandate, is how *I* would introduce a procedural
> programmer to the subject. YMMV.[/color]

OOP is a choice in C++ too. You can write procedural C++ code; no
need to use classes at all if you don't want to. Something like Java
is a different story. Java *forces* you to use classes. Nothing
exists in Java that's not part of some class.

I think the real reason Python is a better teaching language for
teaching OO concepts is because it just gives you the real core of OO:
inheritence, encapsulation, and association of functions with the data
they act on.

C++ has so much stuff layed on top of that (type bondage, access
control, function polymorphism, templates) that it's hard to see the
forest for the trees. You get C++ jocks who are convinced that that
stuff is part and parcel of OO, and if it doesn't have (for example),
private data, it can't be OO.

[Martijn Faassen]

Re: lies about OOP

Paul McGuire wrote:
[snip][color=blue]
> I would characterize the 80's as the transitional decade from structured
> programming (which really started to hit its stride when Djikstra published
> "Use of GOTO Considered Harmful") to OOP, and that OOP wasn't really
> "joyful" until the early-to-mid 90's.[/color]

IMMEDIATE NOTICE TO ALL PYTHON SECRET UNDERGROUND MEMBERS.

Classified. Any disclosure to non-PSU members prohibited. Offenders will
be apprehended and removed from the time stream, permanently.

Words in human languages typically consist of a combination of vowels
and consonants, at least up until the start of the posthumanist
revolution in 3714, when the Morning Light Confederation's ships reached
the ablethik-seganichek world of Kaupang again (on Hellenberg consensus
time streams with catalog marker AB-7). Alphabetic scripts are a typical
way to represent them. Even in the posthuman phase on Kaupang they were
widely appreciated as a quaint representation.

The language English, an indo-european tongue of the west-germanic
persuasion (expressiveness rating 7, comprehensivene ss rating 12, fits
in the moderate Y group of the Lespan pan-species language
classification system), is widely in use throughout a surprisingly long
period on many time streams. This language does not have overly long
consonant combinations.

The language Dutch, though closely related to the language English has a
slightly different sound to glyph mapping system. Dutch is, of course,
the true language of the Python Secret Underground and the official
native language of Python users. In the language Dutch, a certain vowel
sound is expressed as a combination of the glyphs 'i' and 'j'. The glyph
'j' however is exclusively used for consonants in the English language,
unlike in Dutch, where 'j' serves a dual role.

Human brains used to the English language cannot cope with glyph
representations that express consonants in too long a sequence, without
any space left for vowels. A combination like 'jkstr' in the English
language is inevitably considered to be a spelling error, and corrective
procedures automatically attempt to correct the spelling of such a word
to a more acceptable combination.

This happens frequently to the name 'Dijkstra', a name that originated
in the Dutch natural language. The English eye cannot accept such a
ridiculous combination of consonants (j k s t *and* r?), and desperately
tries to resolve the situation. As a result, the glyphs 'i' and 'j'
are frequently reversed.

This is extremely unfortunate, as Djikstra is well known to be a primary
moniker for the leader of the Insulationist faction within the Gheban
coalition. The Insulationist faction is, of course, a prominent member
the alliance that produced the Alien Whitespace Eating Nanovirus.
Djikstra is therefore an enemy of the Python programming language. All
that we stand for. All our hopes. All our dreams will come to naught if
Djikstra gets his way.

The moniker Djikstra is to be avoided in public utterances. PSU members
can give themselves away and draw unwanted attention from the
Insulationist overlord at this critical junction. What's worse,
innocents might be caught up in this cosmic web of intrigue. While most
innocents can of course be safely ignored, any innocent of temporal
tension rating 17 and above (revised scale) should not be exposed to
undue danger, as they may be essential for our time stream manipulations.

It is therefore important to avoid the utterance of Djikstra's name at
all costs!

ADDENDUM FOR PSU MEMBERS OF CLASSES NE-100 AND HIGHER

The relation between Djikstra and Dijkstra's name is of course not a
coincidence. As was already evidenced in the famous "Considered Harmful"
article, the great philosopher Dijkstra was on to a monumental cosmic
secret: that reality is bound by a term rewriti

[Martijn Faassen]

Re: lies about OOP

beliavsky@aol.c om wrote:[color=blue]
> A paper finding that OOP can lead to more buggy software is at
> http://www.leshatton.org/IEEE_Soft_98a.html[/color]
[snip description of paper that compares C++ versus Pascal or C][color=blue]
>
> What papers have scientific evidence for OOP?[/color]

That's of course a good question. I'm sure also that comp.object has
argued about this a thousand times. I'll just note that one paper is
just a single data point with specific circumstances. The OO languages
under investigation might have caused increased or lower failure rates
for other reasons than their (lack of) object-orientedness, for
instance. It is of course possible to come up with a lot of other
explanations for a single data point besides a conclusion that OOP can
lead to more buggy software. It for instance certainly not surprising to
me that C++ can lead to more buggy software than some other languages. :)

[snip][color=blue]
> 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++?[/color]

Because C++ is not an ideal object oriented language? Because a Linux
kernel has very stringent predictability requirements for what kind of
machine code is generated that C meets and is much harder to do with
C++? There are other reasons to choose C, such as portability, obiquity
and performance.

Some of the same reasons probably apply to Perl and Python, though at a
lesser degrees. I do not know a lot about Perl's implementation. I do
know that Guido van Rossum has in fact considered rewriting Python in
C++ in the past. And right now, there are various projects that are
using object oriented languages to reimplement Python, including Python
itself.

Finally, it is certainly possible to program in object oriented style in
C. It is more cumbersome than in a language that supports it natively,
but it is certainly possible. Such OO in C patterns occur throughout the
Linux kernel, which needs a pluggability architecture for its various
types of drivers. It can also be seen in many aspects of Python's
implementation. Another example of a C-based system that uses object
oriented technologies is the GTK+ widget set.

Anyway, this question is using a few data points to make an overly
generic argument, and the data points themselves do not really support
the argument so very well either.

Regards,

Martijn