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

[Polymorph <polymorph69@hotmail.com>]

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.

>
> 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.

>
> > 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.

>
> 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.

> 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.

> 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").  ;-)

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

cheers,
-p