home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / object / 3368 < prev    next >
Encoding:
Internet Message Format  |  1992-09-01  |  2.1 KB
  1. Xref: sparky comp.object:3368 comp.lang.smalltalk:1750 comp.lang.eiffel:1102
  2. Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
  3. Path: sparky!uunet!stanford.edu!CSD-NewsHost.Stanford.EDU!Xenon.Stanford.EDU!hoelzle
  4. From: hoelzle@Xenon.Stanford.EDU (Urs Hoelzle)
  5. Subject: Re: Future Issues of Object Orientation
  6. Message-ID: <hoelzle.715392239@Xenon.Stanford.EDU>
  7. Sender: news@CSD-NewsHost.Stanford.EDU
  8. Organization: CS Department, Stanford University, California, USA
  9. References: <923@ast.dsd.northrop.com>     <17tiuqINNn7i@network.ucsd.edu> <8ecdopy00awJ4HOlo0@andrew.cmu.edu>
  10. Distribution: usa
  11. Date:  2 Sep 92 00:03:59 GMT
  12. Lines: 32
  13.  
  14. sm86+@andrew.cmu.edu (Stefan Monnier) writes:
  15.  
  16. >Self (which is since recently available at self.stanford.edu in version 2.0)
  17. >claims to approach the C speed although it is FULLY dynamic
  18. >(even dynamic inheritance) by special 'run-time' compilation (which
  19. >writes different versions for special cases) !
  20.  
  21. This is a little bit of an overstatement: not all Self programs
  22. approach C speed (yet :-).  However, on the (C-like) Stanford integer
  23. benchmarks Self does very well.  
  24.  
  25. Speed discussions somewhat remind me of the 70s "C (or Pascal or..)
  26. versus Assembler".  At that time, people had to decide between higher
  27. productivity (i.e. a high-level language) or a factor of around 2-3
  28. performance gain (assembly).  Most people chose the "slow" high-level
  29. languages for normal applications, and I don't think anyone regrets
  30. it.  Furthermore, as compiler technology advanced, the performance gap
  31. narrowed considerably.  
  32.  
  33. To me, today's "should I use {Eiffel, Smalltalk, Self} or C" sounds
  34. like a deja vu.  If OO really helps productivity, it's worth a certain
  35. performance hit (the factor depends on the application, of course).
  36. If you can design and implement your new fancy application in half the
  37. time, you're better off than an application that is twice as fast but
  38. comes to market much later.  
  39.  
  40. -Urs
  41.  
  42. ----------------------------------------------------------------------------
  43. Urs Hoelzle                                              urs@cs.stanford.EDU
  44. Computer Systems Laboratory, CIS 57, Stanford University, Stanford, CA 94305
  45.  
  46.