[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple IIGS ROM 1 or ROM 3, which is better?

Polymorph wrote:

On Jul 12, 10:29 am, "Michael J. Mahon" <mjma...@aol.com> wrote:


Polymorph wrote:




Although I agree with you regarding a pure speed comparison, please do
not write off OO.


Not only do I not write it off, I was using what is now called OO
programming techniques in the 1960s, when it was one of several
way of modularizing code.

But I do think that programming, since it is still much more art
than science, is beset by fashions.  No single methodology is the
best for everything, and every methodology has a terrible dark side.



I agree that no methodology is without its flaws. But for reasons of
standardisation, ease of documentation, ease of maintainability, good
design tools, relatively mature compilers, etc., OO is hard to go past
for many, if not most, non-time critical projects. I'm not saying its
the best methodology attainable, but its probably the best we have
thus far.


Probably the best "packaged" methodology--a measure of how we are
still in kindergarten.


I understand that today, OO is the most widespread method of making
code with firm interfaces allowing isolation and factorization.  But
there are other methods, too.



Yes, but until such a time as they are as well known and supported,
are they *really* a viable alternative? I mean, you would not want to
program a large complex piece of software that was designed using a
methodology that few knew about. If you did, it would either mean
trying *real hard* to keep those programmers who do know that
methodology, or expect high training costs because you have to train
any new programmers on how your methodology works.


Any new paradigm will begin as something that few people know about.
Get over it.

I believe that no project should ever be undertaken unless it can
be completed by less than 20 master programmers.  And I have enough
experience with large programming projects to know that they are
essentially doomed to mediocrity by having any programmers under the
95th percentile.

We have GUIs today because PARC was this kind of environment.

We have slow, bloated, buggy GUIs today because when it left PARC
it moved into the "usual" environment.

Given a choice between a staff of 150 average programmers and 10
95+ percentile programmers, I'll take the masters anytime.  (And I
know that they are a real management challenge.  ;-)


The OO paradigm was conceived to separate and control the interactions
(interfaces) between distinct entities of a program rather than for
speed. It also allows for the re-use of tried and tested objects.
These ideas are invaluable when you are dealing with large complex
applications. With modern processors and more mature compilers, the
percentage of processing power lost to the overheads of the OO
methodology is sufficiently small to be acceptable. Especially when
you consider the time spent developing and maintaining such an
application.


What is acceptable is relative to the demands of your application.



True. But I would guess that there are far more applications that do
not require high precision timing.


Right.  "Straight" OO doctrine is for the _hoi polloi_ of programming,
not the masters.  The masters invent new paradigms as needed.

(Have I mentioned that I'm an elitist?  ;-)

Virtually anything of value is created by geniuses, and then
popularized by a few journeymen and countless apprentices who
repeat the patterns of the geniuses endlessly, and often
inappropriately.

Never forget where the real value comes from--and it is *never*
from following the "rules".


If the application is non-critical, or relatively undemanding of
performance, then inefficient implementations are effective.  If,
on the other hand, current processors are marginally capable of
meeting the performance requirement, then giving up a factor of
ten in efficiency for the ability to write a high-level "shell"
calling on a hundred times as much general-purpose "library" code,
is not a good tradeoff.



True again, but I would guess that these scenarios are in the
minority.


Actually, they are all the cutting-edge applications, which are
essentially unattainable using conventional approaches.


In such cases, writing much closer to the silicon is called for,
and can deliver factors of ten to one hundred in problem solution
speed.  If the problem has a real-time component, that can easily
make the difference between feasibility and infeasibility.



Agreed.



On the other hand, if the problem is readily decomposed into
relatively independent pieces, then a "SETI@home"-style solution
may be just the thing--and then the efficiency of any particular
piece is much less critical.

One of the ways that OO is actually helping get the benefit of
hardware performance strategies is by localizing performance-
critical behaviors in a few libraries (such as graphics libraries)
that can be replaced with versions closely adapted to accelerating
hardware, so that most of the application need not adapt to new
approaches to accelerate the algorithms.



Right. But this same advantage can be said of most OO objects. You can
replace an object with a "better" one (read "more correct", higher
performance, or some other measureable worth) as long as it adheres to
the interface provided. This is where a good initial design becomes
paramount and where alot of OO projects become unstuck.


Um, I was giving that as an *example* of an advantage of OO objects...
(not to say that other stable interfaces would not do as well).


No modularization strategy allows code to be leveraged longer than
the lifetime of its interfaces, which makes interface design one of
the most demanding design activities.  Unfortunately, this us usually
realized about an interface after numerous short-lived tradeoffs have
been set in stone.



Right. Or major rework is required on both the design and
implementation phases when the initial interfaces are deemed to be
inadequate. People tend to forget that OO *requires* good design. The
time spent on design should be considerably longer than any
implementation phase. Again, many projects fail to remember this and
put there cowboy hats on and hack away! (I am not sure if the term
"cowboy" used for programmers is universal or just an Aussie thing -
but we call gung-ho, out of control, hacker types - "cowboys").  ;-)


It's pretty universal--hence my tagline.  ;-)


BTW, as I am re-read this post I realised how off topic we have
gotten....whoops. Nice discussion though.  :-)


Yes, but it seems appropriate to talk about real issues in computing
from time to time.  They are what motivated my interest in the Apple II
in the first place, as they did for so many of the early enthusiasts.

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."