🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.mac.oop.macapp3
1 messages
1 total messages Started by Advanced Comm Eng, G G Apple,PRT Sat, 26 Dec 1992 22:19
Re: Performance tests...
#29
Author: Advanced Comm Eng, G G Apple,PRT
Date: Sat, 26 Dec 1992 22:19
47 lines
3057 bytes
 
----------------------------------------------------------------------------
>I have read in the THINK Pascal oop Manual (page 24) that oop is
>not really suited for highly algorithmic applications... It is not
>suited for computational programs...
 
    Au contraire, In my opinion, OOP is the only reasonable (and most useful)
way to do highly algorithmic applications.  However, doing so sometimes
requires a differently way of lookiing at your algorithms.  A few years ago,
before I got involved with the Mac, I developed a highly flexible universal
(ok, at least versatile) non-OOP modem simulator in Turbo Pascal on the PC for
a spook project.  This was a highly algorithmic program intended for long Monte
Carlo simulation runs.  I later ported it to run in a terminal window in Turbo
Pascal on the Mac.  The biggest change was when I later used Prototyper to
expand it and turn it into a real Mac application that was event driven with
Mac look and feel and Multifinder friendly.
 
    A friend of mine was doing DSP-32 cards for the PC.  I wrote some drivers
and we got a Mac Nu-bus card together using the same DSP.  After getting
somewhat familiar with MacApp, I realized the immense potential for OOP in this
environment and wished I would have had it when I was systems manager of a
program that used the world's most powerful DSP (a VHSIC processor for MILSTAR
ground terminals).  I then did the MacApp 2.0 graphical block-linking program
that is demoed on the Phoenix MADA CD.  Due to other priorities, we never got
the Nu-bus DSP and the block-linking program together.  One of my goals has
alwas been to get the modem simulator program running on a DSP, marry it with
the graphical block-linker, and get the whole mess into MacApp 3 (maybe BedRock
by then).  This would give us an extremely high level of simulation flexibility
that would be difficult or impossible to acheive otherwise.
 
    The point is that OOP is a very critical component of this endeavour and
now I would not even consider doing it any other way.  I fully expect that
there will be no algorithmic performance degradation whatsoever because any
OOP-performance hits will be mainly in the interface and control, not in the
core algorithm code.  If designers are taking performance hits, its because
they simply don't know how to design algorithm code to work properly in an OOP
environment.
 
    If I had time, I would write a book on this subject.  Just don't let anyone
disuade you from using OOP for algorithm-performance reasons.  You simply have
to know how to use it.
 
G. Gordon Apple, PhD    D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA
 
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads