lies about OOP

[Paul McGuire]

Re: lies about OOP

"Roy Smith" <roy@panix.co m> wrote in message
news:cpnstr$dca $1@panix2.panix .com...[color=blue]
> 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.[/color]

+1, QOTW!! :) (esp. "type bondage"!)

[Paul McGuire]

Re: lies about OOP

"Martijn Faassen" <faassen@infrae .com> wrote in message
news:PcLvd.9625 2$lN.45814@amsn ews05.chello.co m...[color=blue]
> Paul McGuire wrote:
> [snip][color=green]
> > I would characterize the 80's as the transitional decade from structured
> > programming (which really started to hit its stride when Djikstra[/color][/color]
published[color=blue][color=green]
> > "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.[/color]

<snip - it's "Dijkstra" not "Djikstra", you dolt! :)>

Yikes! (or better, "Jikes!" or even "Yijkes!"?) - my bad.
And he was on faculty at UT right here in Austin, too.

Red-faced-ly yours -
-- Paul

[Mike Meyer]

Re: lies about OOP

beliavsky@aol.c om writes:
[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++ combines the worst features of C and OO programming. It
also makes some defaults go the wrong way, and forces decisions onto
the programmer that are best left up to the compiler, as the
programmer is liable to get them wrong.

C, on the other hand, is a very nice portable assembler language. I've
seen cases where a good optimizing compiler wrote faster code than a
bright human writing assembler (though it was less readable). C is
enough liek assembler that some HLLs generate C instead of assembler,
thus making them portable. I've seen those generate C code as clean as
a human being might generate, given the write options.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Jive]

Re: lies about OOP


"Paul McGuire" <ptmcg@austin.r r._bogus_.com> wrote in message
news:XgGvd.1214 4$jf5.9412@fe1. texas.rr.com...[color=blue]
> I was just reacting mostly to the OP's statement that "by '86 the Joy of[/color]
OOP[color=blue]
> was widely known".[/color]

I (Jive Dadson) said that. I guess I figured that if I knew about it, it
was widely known. But in retrospect, I had an information edge. I was in
Silicon Valley, working on the Next Big Thing, and I was wired into USENET.
My earliest dejagoogle hit is from '86. (It's not under "Jive Dadson", a
more recent nom du net.)

He didn't say "OOP all began when..." or "OOP was widely[color=blue]
> 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.[/color]

Well, it was widely known by everyone who read the motos I stuck up on my
cubicle walls. :-)

Jive

[Carl Banks]

Re: lies about OOP

projecktzero wrote:[color=blue]
> He thinks that OOP has more overhead....[/color]

I think he's just confusing programming with marriage.


--
CARL BANKS

[Daniel T.]

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]

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

[color=blue]
> 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."[/color]

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?

[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]

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.

[Jive]

I DECLARE THIS THREAD FINISHED

Everyone keep moving. There is nothing to see here. Move along.

[Mike Meyer]

Re: lies about OOP

"sbassi@gmail.c om" <sbassi@gmail.c om> writes:
[color=blue]
> 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.[/color]

There are cases where functions just don't do the job.

I at one time needed to use the little-used (and probably little-know)
"account" featre of an ftp server to automate a regular file
transfer. Both Perl and Python come with ftp modules. Perl's was (is?)
procedural, Python's is OO. Neither supported the account feature.

Now, if I used perl to do this, I'd have to either modify the module
in place, meaning I'd have to remember to put the mods back every time
we updated perl if I couldn't get them to buy the patch, or I could
make a local copy of the module, meaning it wouldn't get any bug fixes
that might come with new versions of perl.

With the Python version, I created a subclass of the FTP connection
module, rewrote just the login method, and installed that locally. Now
I don't have to worry about installing new versions of Python, as my
code is outside the distribution. But I still get the benefit of any
bug fixes that show up outside the login method. I also submitted the
new login method, and it's now part of the standard module.

This kind of code reuse just isn't possible with procedural code.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Fredrik Lundh]

Re: lies about OOP

Mike Meyer wrote:
[color=blue][color=green]
>> 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++ combines the worst features of C and OO programming. It
> also makes some defaults go the wrong way, and forces decisions onto
> the programmer that are best left up to the compiler, as the
> programmer is liable to get them wrong.[/color]

that's a nice rant about C++, but it's not the right answer to the question. the
Python core developers are perfectly capable of writing working C++ code,
and both the core and most extensions would benefit from C++ features (just
look at Boost and other C++ layers).

but C++ wasn't a serious contender back when CPython development was
started, and nobody's going to convert the existing codebase...

</F>

[Gregor Horvath]

Re: lies about OOP

Daniel T. wrote:[color=blue]
> beliavsky@aol.c om wrote:
>
>[color=green]
>>A paper finding that OOP can lead to more buggy software is at
>>http://www.leshatton.org/IEEE_Soft_98a.html[/color]
>
>
> Sure, OOP *can* lead to more buggy software, that doesn't mean it always
> does.
>[/color]

I think that costs(=time) to develop and maintain software depends not
on wheter it is based on OOP or not but on two factors:

* Number of NEW Code lines to solve the given problem
* Complexity of this new code

The anwser to the question if OOP is better is: it depends

If the given problem is solved with less code and complexity in OOP then
it is the better approach if not the reverse is true.

Thats why I like python because it does not force to use OOP or
procedural programming.

But isnt the main argument to code in Python (or other high level
languages) easy of use and compact code?

Therefore should Python code be less buggy and cheaper to develop and
maintain. Are there any papers on that?

--
Greg

[Martijn Faassen]

Re: lies about OOP

Paul McGuire wrote:[color=blue]
> "Martijn Faassen" <faassen@infrae .com> wrote in message
> news:PcLvd.9625 2$lN.45814@amsn ews05.chello.co m...
>[color=green]
>>Paul McGuire wrote:
>>[snip]
>>[color=darkred]
>>>I would characterize the 80's as the transitional decade from structured
>>>programmin g (which really started to hit its stride when Djikstra[/color][/color]
>
> published
>[color=green][color=darkred]
>>>"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.[/color]
>
> <snip - it's "Dijkstra" not "Djikstra", you dolt! :)>
>
> Yikes! (or better, "Jikes!" or even "Yijkes!"?) - my bad.
> And he was on faculty at UT right here in Austin, too.[/color]

It's a very common mistake I've seen so often that for a while I
wondered whether his name really *was* Djikstra, but I knew he was Dutch
and that it couldn't be so. That the PSU picked you for its disclosure
is just a random coincidence, I'm sure.. :)

Regards,

Martijn

[Ilja Preuß]

Re: lies about OOP

Daniel T. wrote:
[color=blue]
> 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.[/color]

And he suffers from the common misunderstandin g that OO is better because
"it matches the way we think about the world". It wouldn't suprise me if
design created with that reasoning in mind is more costly than a good non-OO
design.

If you use the features of an OOPL, most importantly polymorphism, to manage
the dependencies in your code, and you do have some experience doing so, I'm
quite certain that it reduces "corrective maintenance cost".

Take care, Ilja

[Peter Hansen]

Re: lies about OOP

Martijn Faassen wrote:[color=blue]
> Paul McGuire wrote:[color=green]
>> "Martijn Faassen" <faassen@infrae .com> wrote in message
>> <snip - it's "Dijkstra" not "Djikstra", you dolt! :)>
>>
>> Yikes! (or better, "Jikes!" or even "Yijkes!"?) - my bad.
>> And he was on faculty at UT right here in Austin, too.[/color]
>
> It's a very common mistake I've seen so often that for a while I
> wondered whether his name really *was* Djikstra, but I knew he was Dutch
> and that it couldn't be so. That the PSU picked you for its disclosure
> is just a random coincidence, I'm sure.. :)[/color]

Well, in any case, thanks for setting the record straight, Martjin.

[H. S. Lahman]

Re: lies about OOP

Responding to Beliavsky...
[color=blue]
> 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."[/color]

Try and find and experienced OO developer who would advocate that large,
complex generalizations are a good practice. You can write lousy
programs in any paradigm. The likelihood increases when you use the
most technically deficient of all the OOPLs. (If those developers had
used Smalltalk, I'll bet their defect rates would have been
substantially lower even if they weren't very good OO developers.)
[color=blue]
>
> 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."[/color]

Part of that criticism was that his experiments were uncontrolled.
There was no attempt made to ensure that the programs under either
paradigm were of high quality for the paradigm. There were other
experimental issues, such as the scale of the programs, that make the
data anecdotal at best and a stacked deck at worst.
[color=blue]
>
> What papers have scientific evidence for OOP?[/color]

I don't know of any large, controlled studies but there must be some
buried in PhD theses somewhere. There is substantial anecdotal evidence
to the contrary, though. For example, where I worked before retiring we
ran a number of experiments to determine whether we should adopt OO
development. One experiment was for exactly the same MLOC application
(originally written in BLISS) that was rewritten in C and then in C++
using good OOA/D. The same developers, who were domain experts, were
used. Both C and C++ were new languages for most of them. [While they
were proficient at procedural development, OO was OJT. However,
extensive OOA/D training was provided.]

The initial development times were about the same, probably due to the
OO learning curve. The released defect rates for the OO version were
about 1/2 those of the C version. The big difference, though, was in
maintenance time, which was nearly an order of magnitude less for the OO
version. One of the first major rounds we estimated to take 6
engineering months using the established techniques we used for
procedural development (which were accurate to -5/+15%). Three people
turned the changes on the OO version in a week -- to the amazement of
everyone, including ourselves. Besides hard comparative data on time
spent, the permanent maintenance staff for the application dropped from
8 full-timers for the C version to one guy half-time for the OO version.

While this is anecdotal (among other things, it is dependent on the
OOA/D methodology employed), it was done with a whole lot more control
than Hatton's experiments. [We were a very process-oriented shop that
insisted on hard experimental data before instituting any process
change. We also collected data religiously. Not a lot of shops can
tell you immediately how much time the average developer spends in
meetings or the average time it takes to diagnose a memory over-write
problem. B-)]
[color=blue]
>
> 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++?[/color]

The main reason is performance. All those examples are very performance
sensitive. C will be ~twice as fast as C++ and C++'s design compromises
were made specifically to enhance its performance! In addition,
physical coupling is a much bigger problem in the OOPLs than in
procedural languages, so build time can become an issue for larger
applications.

[The OO translation-based approaches that do full code generation from
OOA models usually target straight C as the implementation language for
performance sensitive situations in R-T/E. (Also, translation code
generators can usually generate OOPL source code faster than it can be
compiled, but that is usually not true for C.)]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfinderm da.com
Pathfinder Solutions -- Put MDA to Work

http://www.pathfindermda.com

blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

[Jive]

NO REALLY

Isn't there a comp.lang.flame or something?