home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / oop / macapp3 / 284 < prev    next >
Encoding:
Internet Message Format  |  1992-12-26  |  2.9 KB
  1. Path: sparky!uunet!olivea!apple!applelink.apple.com
  2. From: D4887@AppleLink.Apple.COM (Advanced Comm Eng, G G Apple,PRT)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re: Performance tests...
  5. Message-ID: <725409368.9811103@AppleLink.Apple.COM>
  6. Date: 26 Dec 92 22:19:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 47
  10.  
  11.  
  12.  
  13. ----------------------------------------------------------------------------
  14. >I have read in the THINK Pascal oop Manual (page 24) that oop is
  15. >not really suited for highly algorithmic applications... It is not
  16. >suited for computational programs...
  17.  
  18.     Au contraire, In my opinion, OOP is the only reasonable (and most useful)
  19. way to do highly algorithmic applications.  However, doing so sometimes
  20. requires a differently way of lookiing at your algorithms.  A few years ago,
  21. before I got involved with the Mac, I developed a highly flexible universal
  22. (ok, at least versatile) non-OOP modem simulator in Turbo Pascal on the PC for
  23. a spook project.  This was a highly algorithmic program intended for long Monte
  24. Carlo simulation runs.  I later ported it to run in a terminal window in Turbo
  25. Pascal on the Mac.  The biggest change was when I later used Prototyper to
  26. expand it and turn it into a real Mac application that was event driven with
  27. Mac look and feel and Multifinder friendly.
  28.  
  29.     A friend of mine was doing DSP-32 cards for the PC.  I wrote some drivers
  30. and we got a Mac Nu-bus card together using the same DSP.  After getting
  31. somewhat familiar with MacApp, I realized the immense potential for OOP in this
  32. environment and wished I would have had it when I was systems manager of a
  33. program that used the world's most powerful DSP (a VHSIC processor for MILSTAR
  34. ground terminals).  I then did the MacApp 2.0 graphical block-linking program
  35. that is demoed on the Phoenix MADA CD.  Due to other priorities, we never got
  36. the Nu-bus DSP and the block-linking program together.  One of my goals has
  37. alwas been to get the modem simulator program running on a DSP, marry it with
  38. the graphical block-linker, and get the whole mess into MacApp 3 (maybe BedRock
  39. by then).  This would give us an extremely high level of simulation flexibility
  40. that would be difficult or impossible to acheive otherwise.
  41.  
  42.     The point is that OOP is a very critical component of this endeavour and
  43. now I would not even consider doing it any other way.  I fully expect that
  44. there will be no algorithmic performance degradation whatsoever because any
  45. OOP-performance hits will be mainly in the interface and control, not in the
  46. core algorithm code.  If designers are taking performance hits, its because
  47. they simply don't know how to design algorithm code to work properly in an OOP
  48. environment.
  49.  
  50.     If I had time, I would write a book on this subject.  Just don't let anyone
  51. disuade you from using OOP for algorithm-performance reasons.  You simply have
  52. to know how to use it.
  53.  
  54. G. Gordon Apple, PhD    D4887
  55. Advanced Communications Engineering, Inc.
  56. Redondo Beach, CA
  57.  
  58.