Java is not pure OO...

[puff@xxxxxxxxx (puff@xxxxxxxxx)]

Paul Timmins sys:
> 	Also, the phrase "our current state of slow, buggy, GUI-based
> applications" bothers me because, in this day and age, we as engineers don't
> run the show (if we ever did), the business area does. Time to market, and
> acceptable defect levels are the norm, not zero-defects. Slow applications?
> Buggy applications? Well, they're still making money, so the market
> obviously sustains them. Performance in most GUI applications is an
> afterthought, features and usability is #1. 

     Features and usability are usually opposing forces.  Usabilitiy
is as much about eliminating extraneous features as it is about
promoting the right features.  Features typically fulfill little more
than the need for marketing to be able to add bullet-points to their
glossy brochures.

     In a sense, you are very correct; market pressures today support
the current level of code.  As I once said to a friend who was whining
about computer reliability while I was troubleshooting a problem,
"sure, you can have a reliable computer, it'll just cost you $15000
and it'll only run the software it comes with, none of this newfangled
stuff you want." (I had in mind a DEC workstation at the time :-).
 
     While I agree with you that the problem can be laid at the feet
of the decision-makers, this begs the question of "who are the
decision-makers?"  Certainly, engineers are not responsible solely for
software, but neither are managers solely responsible.  The simple
fact is that software development is an attempt to model and automate
complex real-world situations.  As time goes by, both our
understanding of the situations and the situations themselves
constantly change in myriad small ways.

     That's the challenge of software development.  The obstacles in
solving the challenge primarily boil down to different styles of
thinking and communicating about the problems, between programmers,
managers and users (not to mention different priorities).  OO is one
way to make the programmers' portion of this more flexible and
accomodating.  Most of the folks here know this, though again we may
not agree on the nuances.  Why, as Paul asks, are we debating it?

     Or, if we're going to debate this, could we steer the debate
towards more useful, productive approaches that would at least help us
further our understanding of OO and how to successfully apply it?  A
good argument can be an excellent way to learn about a topic.

StevenJ. Owens
puff@xxxxxxxxx
puff@xxxxxxxxxx

---
To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx
To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx