Some programming languages or paradigms are consistent (read: monotheistic) from the bottom (grass roots level, near the metal) to the top (main level of application). (e.g. Forth, Lisp, OOP in Java) Actually, in the old days, most of them were.

But today, when we are wiser, is such fervor fruitful? This might sound as an utterly academic question, but what happens if we are designing a library? Should Phobos be procedural? Should it be entirely converted to OOP? Should there be (an arbitrary level) beyond which we switch to OOP? Or should there be certain parts where OOP is used and others where it really should be avoided? Or entirely two alternate versions of Phobos?

Richard Mansfield (in http://www.devx.com/DevX/Article/26776) offers a controversial opinion on OOP. Having read this, I had to admit that several of the things he took up have disturbed me for years. If we want to go on making D a superior language, we might have to deal with some of his issues, at least in library development.

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:csphdp$1872$1@digitaldaemon.com...
> But today, when we are wiser, is such fervor fruitful? This might sound as an utterly academic question, but what happens if we are designing a library? Should Phobos be procedural? Should it be entirely converted to OOP? Should there be (an arbitrary level) beyond which we switch to OOP? Or should there be certain parts where OOP is used and others where it really should be avoided? Or entirely two alternate versions of Phobos?
>
> Richard Mansfield (in http://www.devx.com/DevX/Article/26776) offers a controversial opinion on OOP. Having read this, I had to admit that several of the things he took up have disturbed me for years. If we want to go on making D a superior language, we might have to deal with some of his issues, at least in library development.

Certainly OOP has been oversold in the past. It's not the solution to every programming problem. But it is still a convenient paradigm for a lot of common problems. D supports OOP well, but it also supports procedural and metaprogramming paradigms. For each particular problem, use whatever fits the best.

In article <csphdp$1872$1@digitaldaemon.com>, Georg Wrede says...
>(in http://www.devx.com/DevX/Article/26776) offers a controversial opinion on OOP. Having read this, I had to admit that several of the things he took up have disturbed me for years. If we want to go on making D a superior language, we might have to deal with some of his issues, at least in library development.

Forgive me, but (IMO) that article is one amusing exercise in FUD :-)

Anyone who claims that OOP is somehow directly tied to a "paradigm shift from DOS to Windows", or that C++ is "not as difficult" as C, is seriously misguiding their readers ...

The title is "Think object-orient programming (OOP) is the only way to go? You poor, misguided soul."

So who in their right mind would claim that any one strategy is the /only/ way to go?

Perhaps the title should have been "I think machine-language is the only way to go; just look at my book titles; and then buy 'em all"

I agree, George, that there's a slight tinge of reality to some of the notions. But that's the basis of FUD; you've got to make part of it sound vaguely familiar before dragging the reader along to Mr Toad's vaccuum booth.

There a place and a time for OOP, just as there is for any other development style. I imagine that sorry author already knows this, yet deliberately wrote some "controversial" nonsense just to plug himself, again.

- Kris

Kris wrote:
> In article <csphdp$1872$1@digitaldaemon.com>, Georg Wrede says...
> 
>>(in http://www.devx.com/DevX/Article/26776) offers a controversial opinion on OOP. Having read this, I had to admit that several of the things he took up have disturbed me for years. If we want to go on making D a superior language, we might have to deal with some of his issues, at least in library development.
> 
> 
> Forgive me, but (IMO) that article is one amusing exercise in FUD :-)

From the "Typing Monkey" manual: "...If the final text is incoherent babbling please throw it away and wait for a better one. Your typing monkey is guaranteed to eventually write something pertinent..."

In article <cspqai$1hpk$1@digitaldaemon.com>, parabolis says...
>
>Kris wrote:
>> 
>> Forgive me, but (IMO) that article is one amusing exercise in FUD :-)
>
> From the "Typing Monkey" manual: "...If the final text is incoherent
>babbling please throw it away and wait for a better one. Your typing monkey is guaranteed to eventually write something pertinent..."

http://www.newtechusa.com/ppi/main.asp

Walter wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
> news:csphdp$1872$1@digitaldaemon.com...
> 
>>Should Phobos be procedural? Should it be entirely converted to
>>OOP? Should there be (an arbitrary level) beyond which we switch to OOP?
>>Or should there be certain parts where OOP is used and others where it
>>really should be avoided? Or entirely two alternate versions of Phobos?

>For each particular problem, use whatever fits the best.

I guess we all do that. And I think we should. But my fear above was that if "whatever fits the best [right here]" is used in standard library development, the result might be inconsistent, and hard to use because there is no "easy to remember logic" or pattern.

(I'm actually only talking about the API. The internals may of course be programmed with "whatever fits the best [right here]".)

Qu'un nit-wit. N'est pas?

As Kris says, a few dissembling correct points, intermixed in with total drek:

 "The day when a programming language needs to accommodate the machine rather than the human has long since passed". -
can someone explain to me how, in the past six months of Windows Update my 2GHz / 512MB machine has gone from a
lightning quick box to something that regularly takes 10s of seconds to go between large applications? "long since
passed" my arse.

 "Programmers describe it as little Ashley's first birthday party: the computer starts counting from zero, so to the
machine it's her zeroth birthday party." - pathetic

 "So colleges now turn out thousands of programmers annually who don't even know that serious alternatives to C++ or OOP
exist." - do they? Maybe where the author lives. Any contact I've had with Unis, or their products, in the last half
decade have revealed a disconcerting bias towards that obfuscator of understanding: Java.

 "OOP apologists keep making the same excuses over and over: you don't understand OOP yet (it takes years of practice;
you can't simply read about it in a book); your company isn't correctly implementing OOP" - as a search through the
history on this ng will attest, I am absolutely *not* a fan of pure OO, but this guy's just talking total kack, or he
associates only with morons. Most of my clients are quite adept at OO. Not perfect perhaps, but not in the least
reminiscent of these dubiously real people to which the author alludes. Drek. Drek. Drek

 "I find that leaving the data in a database and the data processing in the application simplifies my programming.
Leaving data separate from processing certainly makes program maintenance easier, particularly when the overall
structure of the data changes, as is so often the case in businesses (the most successful of which continually adapt to
changing conditions). OOP asks you to build a hierarchical structure and thereafter try to adapt protean reality to that
structure." - disingenuous drek!

"Computer "science" is littered with the debris of abandoned ideas." - yeah, and the sky is blue and 10% of all people asked in a questionnaire whether they like cabbage will respond that they have no idea where the nearest police station is.

 "Encapsulation, too, is a noble goal in theory: you've reached the Platonic ideal for a particular programming job, so
you seal it off from any further modification. And to be honest, constructing a class often is fun. It's like building a
factory that will endlessly turn out robots that efficiently do their jobs, if you get all the details right. You get to
play mad scientist, which can be challenging and stimulating. The catch is that in the real world programming jobs
rarely are perfect, nor class details flawless." - Please, please, please!!! If there be a programming god, please let
me live out my years never coming into contact with any technical system that this author has even walked past.
Encapsulation is not a mechanism for specification of "the perfect class", it is about enforcement of design.

At this point, i.e. on that last point, I must desist, lest I vomit on the floor. This author has, methinks, lost credibility for all time, due to his obvious, yet incomprehensible, inability to comprehend some of the basic tenets of design, coding, refactoring, all of which are basic skills for people in our industry. 32 books, eh? He'll not be short of doorstops, then.

Drek!


"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:csphdp$1872$1@digitaldaemon.com...
>
> Some programming languages or paradigms are consistent (read: monotheistic) from the bottom (grass roots level, near the metal) to the top (main level of application). (e.g. Forth, Lisp, OOP in Java) Actually, in the old days, most of them were.
>
> But today, when we are wiser, is such fervor fruitful? This might sound as an utterly academic question, but what happens if we are designing a library? Should Phobos be procedural? Should it be entirely converted to OOP? Should there be (an arbitrary level) beyond which we switch to OOP? Or should there be certain parts where OOP is used and others where it really should be avoided? Or entirely two alternate versions of Phobos?
>
> Richard Mansfield (in http://www.devx.com/DevX/Article/26776) offers a controversial opinion on OOP. Having read this, I had to admit that several of the things he took up have disturbed me for years. If we want to go on making D a superior language, we might have to deal with some of his issues, at least in library development.

Georg Wrede wrote:

> But today, when we are wiser, is such fervor fruitful? This might sound as an utterly academic question, but what happens if we are designing a library? Should Phobos be procedural? Should it be entirely converted to OOP? Should there be (an arbitrary level) beyond which we switch to OOP? 

Phobos *is* procedural. Some people hate this (hello, Ant! :-))
See for instance http://dool.sourceforge.net/manifestDool.html

You can follow the war under the "should there be a String class",
along with some heated discussion if arrays and dictionaries belong
in the core language or should be implemented as Collection classes...
To me, C and Java represents the "extremes". D is somewhere in-between.


The direction taken so far seems to be that runtime library provides
basic classes and then a function/struct based runtime API. And that
any implementation of an object-oriented API is left as an exercise ?

One very nice such "exercise" completed, is Kris's The Mango Tree:
http://svn.dsource.org/svn/projects/mango/trunk/doc/html/index.html
It has a lot of real-life implementations, and also Log4J and ICU!

--anders

Georg Wrede wrote:
> 
> Some programming languages or paradigms are consistent (read: monotheistic) from the bottom (grass roots level, near the metal) to the top (main level of application). (e.g. Forth, Lisp, OOP in Java) Actually, in the old days, most of them were.
> 
> But today, when we are wiser, is such fervor fruitful? This might sound as an utterly academic question, but what happens if we are designing a library? Should Phobos be procedural? Should it be entirely converted to OOP? Should there be (an arbitrary level) beyond which we switch to OOP? Or should there be certain parts where OOP is used and others where it really should be avoided? Or entirely two alternate versions of Phobos?
> 
> Richard Mansfield (in http://www.devx.com/DevX/Article/26776) offers a controversial opinion on OOP. Having read this, I had to admit that several of the things he took up have disturbed me for years. If we want to go on making D a superior language, we might have to deal with some of his issues, at least in library development.

Sooo, yeah, there's so much wrong with that article that it makes me angry, and then sick, and then angry again, and then confused.

What's all this nonsense about "hiding code"...both from others and from yourself...
When you're working on a project with others, it's not like they just give you an object code version of their work, you build the whole thing yourself, meaning you have full access (to read if it's someone else's, to modify any way you like if it's yours) to all the source code. How is changing a couple things in a class any different from changing a function and some data in a non-OOP design.

You can re-write a class, increase its efficiency and whatnot, and it can still have the same interface, so you aren't kept from ever touching it again, as he seems to imply.

My guess is that he's scared that he's losing too much market for books on machine language to higher-level languages. Sure OOP isn't good for everything, that's obvious, and heck, I enjoy writing assembly language now and then, but that doesn't make C++, or D, or even Java the root of all evil. (matter of fact, I have a soft spot in my heart for Java...but that's a different topic :P )

Also, the last bit he says there, the part about: "...just one more dead end in our fumbling efforts to communicate with intelligent machines."

What the crap is he talking about? A computer is not an intelligent machine...there's no such thing as an intelligent machine. A machine does what it's programmed to do, very stupidly. If a computer was intelligent, you wouldn't have to write programs for it, or it would notice logic errors in your programs as it was running them and fix them for you, send you an email letting you know about it, and set up a date with a hot chick from the Internet for you (I might note that I would not need that, being married myself, but you get the idea).
I mean, seriously...

On the note of the whole tone of the whole paper...he seems like someone else I know, who makes up his mind about something right off the bat and sticks with it religiously no matter what evidence there is against it, or lack of evidence he has to back it up, requiring him to just make crap up...or maybe he just likes typing "OOP".

Okay, I gotta stop..I could go for pages...

-- 

-PIB

--
"C++ also supports the notion of *friends*: cooperative classes that
are permitted to see each other's private parts." - Grady Booch

Wow, I think we have missed you Matthew!

:-D

- John R.

PS.  The note about windows slowing down: you've noticed that too?  I'm glad I'm not the only one!  And I thought I had power to spare...

Matthew wrote:
> Qu'un nit-wit. N'est pas?
> 
> As Kris says, a few dissembling correct points, intermixed in with total drek:
> 
>  "The day when a programming language needs to accommodate the machine rather than the human has long since passed". - can someone explain to me how, in the past six months of Windows Update my 2GHz / 512MB machine has gone from a lightning quick box to something that regularly takes 10s of seconds to go between large applications? "long since passed" my arse.
> 
>  "Programmers describe it as little Ashley's first birthday party: the computer starts counting from zero, so to the machine it's her zeroth birthday party." - pathetic
> 
>  "So colleges now turn out thousands of programmers annually who don't even know that serious alternatives to C++ or OOP exist." - do they? Maybe where the author lives. Any contact I've had with Unis, or their products, in the last half decade have revealed a disconcerting bias towards that obfuscator of understanding: Java.
> 
>  "OOP apologists keep making the same excuses over and over: you don't understand OOP yet (it takes years of practice; you can't simply read about it in a book); your company isn't correctly implementing OOP" - as a search through the history on this ng will attest, I am absolutely *not* a fan of pure OO, but this guy's just talking total kack, or he associates only with morons. Most of my clients are quite adept at OO. Not perfect perhaps, but not in the least reminiscent of these dubiously real people to which the author alludes. Drek. Drek. Drek
> 
>  "I find that leaving the data in a database and the data processing in the application simplifies my programming. Leaving data separate from processing certainly makes program maintenance easier, particularly when the overall structure of the data changes, as is so often the case in businesses (the most successful of which continually adapt to changing conditions). OOP asks you to build a hierarchical structure and thereafter try to adapt protean reality to that structure." - disingenuous drek!
> 
> "Computer "science" is littered with the debris of abandoned ideas." - yeah, and the sky is blue and 10% of all people asked in a questionnaire whether they like cabbage will respond that they have no idea where the nearest police station is.
> 
>  "Encapsulation, too, is a noble goal in theory: you've reached the Platonic ideal for a particular programming job, so you seal it off from any further modification. And to be honest, constructing a class often is fun. It's like building a factory that will endlessly turn out robots that efficiently do their jobs, if you get all the details right. You get to play mad scientist, which can be challenging and stimulating. The catch is that in the real world programming jobs rarely are perfect, nor class details flawless." - Please, please, please!!! If there be a programming god, please let me live out my years never coming into contact with any technical system that this author has even walked past. Encapsulation is not a mechanism for specification of "the perfect class", it is about enforcement of design.
> 
> At this point, i.e. on that last point, I must desist, lest I vomit on the floor. This author has, methinks, lost credibility for all time, due to his obvious, yet incomprehensible, inability to comprehend some of the basic tenets of design, coding, refactoring, all of which are basic skills for people in our industry. 32 books, eh? He'll not be short of doorstops, then.
> 
> Drek!
> 
> 
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:csphdp$1872$1@digitaldaemon.com...
> 
>>Some programming languages or paradigms are consistent (read: monotheistic) from the bottom (grass roots level, near the metal) to the top (main level of application). (e.g. Forth, Lisp, OOP in Java) Actually, in the old days, most of them were.
>>
>>But today, when we are wiser, is such fervor fruitful? This might sound as an utterly academic question, but what happens if we are designing a library? Should Phobos be procedural? Should it be entirely converted to OOP? Should there be (an arbitrary level) beyond which we switch to OOP? Or should there be certain parts where OOP is used and others where it really should be avoided? Or entirely two alternate versions of Phobos?
>>
>>Richard Mansfield (in http://www.devx.com/DevX/Article/26776) offers a controversial opinion on OOP. Having read this, I had to admit that several of the things he took up have disturbed me for years. If we want to go on making D a superior language, we might have to deal with some of his issues, at least in library development. 
> 
> 
>