Will there be any rules to this death match? I hope not, for it to
truly be a religious war then that has to be a war to the death, no
quarter asked or granted. And as well all know, EVERY topic in this
field takes on religious proportions. I've watched month long flame
wars over vi vs emacs. I'm proud to have been one of the first posters
on alt.religion.emacs (you can't spell evil without vi), but then it was
tounge-in-cheek humor, I read the newsgroup a couple months after it
started and sadly enough, people were taking it seriously. These people
have no lives.
But I will take up this call to arms and defend "the way things have
been and worked all right" vs "the fad of the month".
Actually I'm kidding. I am actually looking at this object stuff
seriously, I just picked up Orfali, Harkey and Edwards "Essential
Distributed Objects Survival Guide" and I actually intend on reading it
soon. But since I haven't found object religion yet, I'll make some
objections to your post.
I Find Karma wrote:
>
> Specifically, Dave wrote:
>
> | I'm not one of those programmers that, for lack of a better word,
> | are frightened about object oriented stuff. I just don't see the big
> | deal.
Its still no big deal.
>
> And then later on:
>
> | Am I just not understanding this stuff? Is there some major great new
> | thing that I just am not seeing?
>
> The short answer is, "yes." The longer answer is contained within
> Ron Resnick's response to the spurious Bjarne Stroustrup interview
> as posted to dist-obj earlier today...
>
> http://sphere.cs.caltech.edu/mailing_lists/dist-obj/msg00899.html
Hey, no fair garbing the cool, funny articles to booster your argument
>
> Read on, and you might find the answer you're looking for...
>
> Of course it's an old joke in new joke clothing. But if it illustrates
> a point, then maybe it can be useful anyway. Back to Ron's post...
>
> > Some hash about Bjarne Stroustrup claiming that C++ was
> > a giant hoax perpetrated in the name of increased software
> > development salaries. Personally, the skeptic in me seriously
> > doubts Stroustrup ever said any such things. Hence, my
> > reluctance to simply forward the whole mail here. But you
> > can check it out at:
Hmm, you know what they say on alt.conspiracy, where there's smoke
there's a high level white house stiffer destroying evidence of
whitewater land deals and Vince Foster's murder.
Adam, can you prove that OO isn't simply a plot to drive programmers out
of the field and increase salaries? The circumstantial evidence is
there, just as OO programming has gotten hot in the last few years the
demand for programmers is going up. Even now there is a serious decline
in the number of people going into the field. Probably all the C++ that
they are scaring the college kids with.
>
> > I also note that C++ is hardly the entire world of OO software design
> > and programming. OO existed long before C++, and appears to have a
> > bright future even as C++ loses its role in the spotlight. Equating
> > critique of C++ with critique of objects seems quite off the mark to
> > me. Most folks I know seem quite willing/able to reject C++ without
> > rejecting objects in general, merely moving on to Java or Smalltalk or
> > Eiffel or ...
But what are people rejecting when they are rejecting objects in
general? Hmm.. hold onto that question for a minute.
>
> So then what are the main reason to use objects? Oh, you answer that next.
>
> > Heck, I'm into objects mainly for decomposition and encapsulation.
> > I can live without inheritance, certainly without complex rules for
> > multiple inheritance.
>
> Decomposition and encapsulation, with inheritance optional.
> There's your answer as to why objects are good, Dave Crook.
I think we may be drifting from my original diatribe. I was
specifically bashing on the new testimate books on distributed objects,
not the OO bible in its entirety. But what the heck, if I'm going to be
a heretic then I might as well go for the whole enchilada.
Yes, decomposition and encapsulation are GREAT concepts. But they
PREDATE OO programming by a decade or too. How is a class fundamentally
different from an abstract data type? True, its got a neater
implementation, but its still the same thing. I've implemented typedefs
and related manipulation functions in one file in C before, I just
called it an abstract data type. I think you will have to go farther if
you are going to claim a decisive victory for OO. It is true that the
main subject of what is being decomposed and encapsulated is different
for functional based design. But still its still organization.
I grant that OO designed systems have a greater capacity for reusing
modules of code in other projects. The modules rely on code outside
themselves only through starkly defined interfaces. Functional
decomposition doesn't give you this.
But I ask, is this really a big deal? In THEORY it sounds great. But,
its theory. One of the quotes in the joke interview was Stroustrup
stating that no companies reuse their code. I hate to break it to you,
but its true. Now some things do get reused a lot, they are called
libraries and you can create those without OO programming thank you very
much. But follow me on this for a second. Assume you have an OO
designed banking system. Now lets say that over time that the
requirements behind the system have changed enough that a redesign is in
order (they had a merger, etc). How much of that system are you going
to reuse in the new design. I submit that you are mostly going to reuse
the lower level objects, the ones that get inherited by other objects.
I submit that in most functional designed systems that these same tasks
would probably be done by a library so that it could be easily called by
other parts of the system. The library would be just as reusable as the
object in this case.
Now maintenance is another area that I hear as being the strong point
for OO. I agree that since in OO design data is well encapsulated.
Changing how private data is manipulated within a method has no effect
on the other objects, even the ones that call it. But a good functional
design will give you the same benefit. Most language support having
private data for functions, even C. But maintenance work is more than
simply making dink changes to code. Any changes you make during
maintenance are for a reason, ie somebody wants you to make a change to
the FUNCTIONALITY of the system. Under which system of organization do
you think it will be easier to find and change all the code responsible
for a particular function, one where all the code is grouped by function
or one by where its grouped into objects that kinda match program
functionality. I submit that any benefits you gain in being able to
make changes without effecting the rest of the system are lost by having
to spend more time finding the code you want to change in the first
place.
I am of course not going to present any evidence for these, because this
is a theological argument :-)
>
> > In the same way that biologists seek cells within livers, and peptides
> > within cells, the argument of complexity being constructed from
> > simplicity just makes overwhelming sense to me. Sure, I think the OO
> > community goes overboard with jargon (polymorphism - what an ugly
> > word!). Yes, I think objects need to be championed as things that make
> > design *simpler* - not harder, as is so often the case! But let's not
> > throw out the baby with the bath water, either. I used to be a
> > confirmed C/sockets guy. I held out for about 2 years while taking my
> > OO training - 'why do I need this? It's always worked the old
> > way!'. At some point, some light clicked - this is personal, of
> > course- YMMV. But I think once you 'get' decomposition, there's
> > really no going back. You can't fall in love with structured
> > programming again once you've really seen the other.
Hey, good functional designs should have decomposition and encapsulation
too. Not every non-OO program consists on nothing but global variables
and goto statements. Its not magic, its just good design. The kind of
design that you can't learn in college simply because no one in college
has to live with their programming mistakes for more than a semester.
Maybe that should make freshmen programmers write some moderate sized
program and then make them maintain the damn thing for their entire four
years. Then maybe they will pause a second before writing programs and
think of the poor bastard that will have to fix the thing later.
>
> But can't you have decomposition without having objects? Doesn't the
> "philosophy" of objects transcend whatever meme is currently hot, as
> Dave Crook suggested?
>
> My attitude is, yes, object philosophy != existing object tools. We can
> learn from objects without using them as a hammer wherever there are
> nails.
Sorry Adam, but your religious fervor is showing. "object philosophy !=
existing object tools"?? You seem to miss the point, I'm not merely
suggesting that encapsulation and decomposition can be done without the
latest copy of Visual Studio or the newest JDK, I'm openly shouting the
blasphemy that these concepts are bigger than and can be implemented
WITHOUT OO programming at all.
Answer me this puzzle. Lets say I've created a nice stack
implementation in C using something as hideously non-OO as void
pointers. Now since I'm a neat freak about my code (my apartment is
another matter) I make some nice typedefs for my datatype. I also write
some general manipulation functions for my stack datatype and I throw
all these in one nice c source and header file for easy use my multiple
programs.
Now either what I have done doesn't show encapsulation or decomposition
separate from OO programming OR you can argue that C is an OO
programming language. Your pick. :-)
>
> > What we consider "objects" evolves, over time. Where once we were
> > focused on language objects buried within compiled program units,
> > we're increasinly focusing on distributed objects that span networks
> > and geography, and whose granularity takes on "real world"
> > proportions.
>
> So it's like, we don't know what language we'll be using in five years
> for writing software, but we're sure we'll be using objects if we want
> the state-of-the-art?
What the heck, lets just extend the definition of OO systems to
everything that happens with "computer objects" and "people objects".
:-)
Everything will be objects in five years? Hmm, sounds like a reasonable
prediction. But here, let me make one of my own.
Its 2003 and Wired has officially declared the distributed object
movement dead. Oh, it seemed like a great idea at the time. PC costs
five years ago were still high enough that making stripped down
computers strictly for running network based apps made sense. A short
lived "back to the mainframe" movement that was killed by the continual
march of Moore's law. Thin-clients always seemed like a great idea for
other people, but no one wanted one for themselves. But with the
continuing drop in prices for hardware and the ever increasing bang for
the buck the bottom end model simply outgrew the limitations expected of
thin-client machines, they could run real software just like the more
expensive computers. Even the PDAs today seem powerful compared the
machines of 5 years ago. The final deathblow for distributed objects
came when angry mobs of computer owners went to the main purveyors of
bloated software Netscape and Microsoft and demanded that they write
reasonably sized software.
How's that for a future?
>
> > And, as we're so fond of discussing on this list, objects and our
> > notions of them continue to evolve into the future to being
> > independent, autonomous, mobile, runtime composable things. That
> > causes us to figure out all the hard stuff - like runtime
> > introspection. Like concurrency & distribution & coordination between
> > such composable beasts. Like putting these finicky, complex beasts
> > into the hands of mere mortal developers and users, who still must
> > produce end-systems that have repeatable and pretictable cause/effect
> > behaviour in the overall systems.
>
> Oy gevalt. Now I'm even more afraid of the ramifications of this.
> Many people can't even write bug-free software in the current climate of
> less ambitious, static, local, non-concurrent "objects".
Ummm how about programmers using typical client-server programming
methodologies and actually spending some time DESIGNING BETTER <very bad
word>ING programs. I think the only thing that the browser war between
Microsoft and Netscape is showing us is what happens when program design
and testing are thrown out in favor of adding the feature dujuor.
Gigantic bloated programs that crash on a regular basis. The main catch
is that consumers basically have the choice of one pig or the other.
I've thought about looking at Opera, but since they don't have a linux
version it won't do much for me.
Another solution is to increase the skill level of the "programmers"
that you mention. This field has always had a ton of people that know
less then they let on. The web has increased the problem a thousand
fold. Every yeahoo that has a copy of hotdog pro thinks they are a web
page designer. People who manage to mail-merge in a list of people from
access into their holiday newsletter on Word thinks they are a DBA. I
personally don't suffer from these delusions of adequacy. I'm a pretty
good programmer and I know my way around administrating a unix box. But
when it comes to overall design and layout, my web pages suck. Just
because I can run pc paintbrush that doesn't mean that I'm a graphic
artist.
>
> How in the world are we going to add complexity AND reduce errors
> simultaneously in the next generation of software?
>
> > Sure, we could probably start all over and build a world of tomorrow
> > without trying to leverage what we already know about the less
> > ambitious, static, local, non-concurrent "objects" of today. But I
> > fear we'll be relearning a lot of those lessons if we build on,
> > e.g. web/cgi, without recognizing the legacy (?! what a strange word
> > here!) of "classic" OO.
>
> Web/CGI is not an enemy of OO. The underlying *philosophy* of the Web
> is that of objects being passed around a network.
>
> > Nope, to me "objects" represent the state of the art in what we know
> > about building large, maintainable, understandable software. That we
> > still don't have it right, and that experience with OO to date is less
> > than spectacular, just shows us how much further we have to go down
> > this road to get anywhere.
>
> So there you go, Dave Crook. "objects" = "state of the art", whatever
> that may be. So BY DEFINITION, objects are the best things you can use
> in your software development.
>
Come to the dark side Adam. Give up your faith in objects and join the
programming skeptics. Feel the power of the dark side of the force, use
ANY programming method that makes the most sense for the project at
hand. Treat the most faithful belief systems of others as mere tools in
your toolbox. Bend them to your will.
You see, "objects" = "current trend", great for a lot of tasks but not
the ONLY method for software development. Many of the concepts that are
being co-opted by OO proponents have simply been the hallmarks of good
software design before OO was even at the pre-fad days.
>
> The reason I sent this post here, is that I think FoRK remains the
> bastion of object skeptics, and perhaps this will inch some people
> forward in thinking about objects.
Not if I can help it :-)
Dave "Chief Representative of the forces of darkness" Crook