RE: Euphoria being OO Survey.
> From: Derek Parnell [mailto:ddparnell at bigpond.com]
> > From: "Jerry Story" <jstory at edmc.net>
> > Here is a website that is devoted to criticism of OOP.
> >
> > http://www.geocities.com/tablizer/oopbad.htm
> This man must be a polititian. He can argue a point without
> reasoning. This
> is a very sad example of humanity.
>
> His arguments seem to based on destroying "strawman"
> positions and hearsay!
> No real evidence is actually presented or clinically
> examined. Who are these
> nameless supporters of OO and where are their actual
> quotations? The author
> seems to place many words into many mouths.
>
> I found it mildly amusing that some of his rationale against
> OO could just
> as equally apply to non-OO programming too.
I usually try to stay out of holy-war territory, but since I just installed
linux a few weeks ago, I guess I'm qualified now. :)
Well, he did cite a few references, and I didn't follow many of the links
(many of which are to others' criticisms of OO, and I think at least a few
were to pro-OO pages), but I guess I disagree a bit with your review (can we
lump you in with his OO-fans? :). Much of his point seemed to be exactly
that no one had taken a critical look at the real world benefits and trade
offs associated with OO. Of course he could have posted the name of all the
people he talked about (there were several personal anecdotes about a debate
or an example or whatever), but I thought he made the point several times
that anecdotes shouldn't satisfy anyone. It seemed more of a philosophical
article than a scientific review, and I don't think he was attempting to
misrepresent that.
He admits in several places that OO may be the correct paradigm for some
problems, but not for others. He even says that the most important issue
(at least in the short term) is the individual coder (i.e., how do you
approach and think about programming).
I don't have a degree in CS, and I don't make my living programing, so there
are probably many on this list who have stronger opinions that may or may
not be better thought out, but as a registered Euphoria user, I'll put on my
flame-proof suit and let you know what I think (hopefully I won't set a sad
example for humanity). Derek, I'd be interested in hearing some of your
take (at least briefly) on his rationale that could apply to non-OO
programming.
I definitely agree with him that OO looks great in sound-byte form, but
whenever I've tried to look at or code OO in any real complexity, it's
always left a funny taste in my mouth (how's that for unscientific). I
think a lot of it was the forced hierarchy of OO (at least what I've used or
seen). I tend to approach things from a more set-oriented approach, about
which the author talked a little.
One thing I do like about OO is the concept of polymorphism. Of course this
is really handy in GUI coding, but in a lot of other areas as well.
Win32lib's event handling is probably the best example of that in Euphoria,
and I've used similar things in practically everything I've done.
Personally, routine_id() is my favorite part of the language, since with it
you can write very scalable and reusable code (my matheval lib--used in
EuSQL--is a prime example).
Speaking of which, I've never really understood why OO would make code more
reusable. I've often looked at code in the archives, to see if I could use
something without reinventing the wheel, and most of the time, I can't,
because the code simply solves a slightly different problem than what I'm
doing. No matter the paradigm, if code doesn't do what you need it to do,
you can't reuse it. I don't see the fundamental thing that makes OO more
reusable than non-OO.
> From: fred at jordah.freeserve.co.uk [mailto:fred at jordah.freeserve.co.uk]
> Thank you Derek for your comments on the issue. It seems most
> people round
> here haven't bothered to code win32 libraries and get ugly
> code + had to
> extend.(bloated).
>
> I was recently looking at the java implementation of Swing
> and i thought
> that was great. I mean,....if you create a basic class eg
> JPanel...you could
> easily extend it my overiding the default methods for
> painting..etc then get
> an Edit Control.
Fair enough. But that doesn't mean that there's not a different way to do
it. Of course, the only thing I know about Swing or JPanels is how to spell
them. It's not obvious to me why an OO implementation is necessarily better
or prettier than a non-OO implementation, though I do admit that GUI's tend
to lend themselves to OO.
> Pple had better try coding GUI libraries then they'll
> understand why its needed for cleaner syntax.
In fact, I'm writing one right now (wxEuphoria), which actually sits on top
of a ton of OO (C++) code, but I don't have your understanding, or perhaps
we don't share the same definition of cleaner syntax. One of the points in
the article was that the author thought problems were often best oriented
around tasks (verbs), as opposed to things (nouns). In general, this fits
my way of thinking. It's often clearer to me when a function sits on its
own than embedding within a class. Of course, this is probably a very
personal preference, but I prefer:
do_it( to_this )
over:
to_this.do_it()
This is not to say that I think modularity is unimportant, but I don't think
that OO has a monopoly on this.
> I think it would be best if we have a PRO euphoria that supports OO or
> similar. Rob, Can't you notice how many times these discussions have been
> repeated? lets have some change...if we cannot get it from RDS, then lets
> team up and get the stones rollin'. OpenEuphoria, and if i could be any
> help, then send me an email..
The frequency of discussions doesn't mean anything. The fact that there is
rarely a real conclusion or consensus reached says a lot more. Even your
own poll has 50% (one vote being mine) saying that OO should be left out of
Euphoria (and only 25% with a strong opinion in favor)--at the time I write
this, anyway.
If you're interested in OpenEuphoria, you can do a search for OpenEu on
Topica and on Sourceforge.
Matt Lewis
|
Not Categorized, Please Help
|
|
