home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / next / misc / 23027 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  4.7 KB
  1. Path: sparky!uunet!overload!dillon
  2. From: dillon@overload.Berkeley.CA.US (Matthew Dillon)
  3. Newsgroups: comp.sys.next.misc
  4. Subject: Re:    Why, Why, WHYYYY?? USE OBJECTIVE-C for IB??
  5. Distribution: world
  6. Message-ID: <dillon.0spl@overload.Berkeley.CA.US>
  7. References:  <dillon.0sh6@overload.Berkeley.CA.US> <1992Dec11.163906.2483@webo.dg.com>
  8. Date: 13 Dec 92 12:30:53 PST
  9. Organization: Not an Organization
  10. Lines: 85
  11.  
  12. In article <1992Dec11.163906.2483@webo.dg.com> dlewine@nf01.webo.dg.com (Donald Lewine) writes:
  13. |
  14. >In my experience (over 30 years of professional programming), your choice of
  15. >algorithm has a much larger effect on performance than your choice of programming
  16. >language or compiler technology.
  17. >
  18. >If programmers spent more time working on their algorithm and less time arguing
  19. >about the efficiency of their compiler, they would produce faster programs sooner.
  20. >
  21. >I have been able to speed up programs by a factor of 1000X or more by changing the
  22. >basic algorithm.  I have never seen a speedup that large from a compiler.  [Except
  23. >in cases where the compiler changes the basic algorithm (e.g. loop unrolling)]
  24.  
  25.     That's nice, but don't dwell on your years of experience too much, I
  26.     know people with at least that much experience who have trouble
  27.     grasping the basics of modern day programming languages (this is not a
  28.     personal insult directed at you).  Experience is a relative term and
  29.     the phrase 'years of experience' instills no confidence in me when I'm
  30.     interviewing someone for a job.  "It is always the mistake that
  31.     executives make".  My view of experience is to put uncommented
  32.     schematic or source code in front of someone and see if they can figure
  33.     out what it does.
  34.  
  35.     In the short term, yes.
  36.  
  37.     In the long term, however, the programming language has a lot to do
  38.     with the maintainability of the software.  Programs can start out good,
  39.     but when you loose the original programming team (which happens all to
  40.     often) the software generally degrades to the point where one is unable
  41.     to address new features required by the user base or even to fix bugs
  42.     in a timely fashion.  Software complexity has an equivalent effect.
  43.     This premise is bourn out by just about every piece of commercial
  44.     software in existance and is why it is so easy for a new company to
  45.     superceed an older company's software.
  46.  
  47.     People say that you can do anything with any programming language and
  48.     its true enough on theoretical grounds, but not realistic in practical
  49.     terms.  Just because you can doesn't mean you do, and like it or not,
  50.     most people stick pretty close to the models a particular language was
  51.     designed for rather then try to program it in a way it was not designed
  52.     for.
  53.  
  54.     Take Objective-C and NeXTStep for example... look how hard it was for
  55.     NeXT to make even the simplest of changes in their interface
  56.     specification (the alloc/init combination instead of new). It *still*
  57.     isn't generalized and has special cases all over the place for fonts
  58.     (the sharing of fonts is not hidden and requires one to view font
  59.     operations in special case situations), certain one-time structures use
  60.     a different initialization model, there are all sorts of
  61.     incompatibilities with multi-threaded operation because it turns out
  62.     that Objective-C's run time system is too dynamic... requiring extra
  63.     locking in order to work properly in a multi-threaded environment.    A
  64.     simple call, yes, but a huge gaping special case that became necessary
  65.     when NeXT found out the cost of multi-threading their dynamic caching,
  66.     method call overhead increases 3x best case. I can't even begin to
  67.     describe problems with the distributed objects interface, it is far
  68.     from seamless.
  69.  
  70.     One could argue that the Objective-C paradigm does NOT fit NeXTStep
  71.     like a glove and it is becomming less general, more special-cased, and
  72.     more difficult to maintain.  Still better then C, of course, but it
  73.     just goes to show that while there is such a thing as a 'better'
  74.     lanugage, there is no such thing as an ultimate language and even if
  75.     one starts out sticking to the bounds of the language model, ongoing
  76.     development tends to introduce new situations that the language cannot
  77.     easily handle well.  If this were not true we would still be
  78.     programming in pseudo-assembly.
  79.  
  80.                         -Matt
  81.  
  82. >--
  83. >--------------------------------------------------------------------
  84. >Donald A. Lewine         (508) 870-9008 Voice
  85. >Data General Corporation     (508) 366-0750 FAX
  86. >4400 Computer Drive. MS D112A
  87. >Westboro, MA 01580  U.S.A.
  88. >
  89.  
  90. --
  91.  
  92.     Matthew Dillon        dillon@Overload.Berkeley.CA.US
  93.     1005 Apollo Way        uunet.uu.net!overload!dillon
  94.     Incline Village, NV. 89451    ham: KC6LVW (no mail drop)
  95.     USA             Sandel-Avery Engineering (702)831-8000
  96.  
  97.