home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / object / 5082 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.6 KB
  1. Path: sparky!uunet!think.com!spool.mu.edu!sdd.hp.com!network.ucsd.edu!lyapunov.ucsd.edu!mbk
  2. From: mbk@lyapunov.ucsd.edu (Matt Kennel)
  3. Newsgroups: comp.object
  4. Subject: Re: Maintenance and OO
  5. Date: 26 Jan 1993 08:03:30 GMT
  6. Organization: Institute For Nonlinear Science, UCSD
  7. Lines: 67
  8. Message-ID: <1k2r8iINNa4a@network.ucsd.edu>
  9. References: <1993Jan25.093100@axion.bt.co.uk>
  10. NNTP-Posting-Host: lyapunov.ucsd.edu
  11. X-Newsreader: Tin 1.1 PL3
  12.  
  13. pkeddie@axion.bt.co.uk (Paul Keddie) writes:
  14. : I know that, in theory, the benefits OO gives to developers should also
  15. : count for maintainers (data hiding, etc) -- but does this bare up in
  16. : practise? Specifically:
  17. : <deleted>
  18. : 3) Are there more difficulties because of C++ rather than the 00 paradigm?
  19. : 4) Is badly written C++, 00 programs worst than the equivalent C programs?
  20.  
  21. I don't have that much experience with C++ except to say that I
  22. think it's revolting.  It inherits (ahem) many of the flaws from C but
  23. then proceeds to combine them exponentially.
  24.  
  25. In my opinion, C++ is way too hard for humans to parse.  I think many people
  26. have problems just figuring out the *literal* meaning of C++ programs(like
  27. APL), rather than the underlying content.  That's an utterly needless loss
  28. of productivity.  C++ helps for some things, but the real bugs are orders of
  29. magnitude more difficult.  The "random memory stomp bug" of C turns into
  30. fire-breathing Mothra.  
  31.  
  32. OO programming without garbage collection is difficult and dirty.
  33.  
  34. Personally, I like Sather much, much better.  Even with an early
  35. preproduction compiler (0.2), I'm 2 to 3 times more productive than with
  36. C.  And it runs as fast as C++.  The entire documentation for the 
  37. (early version) language and compiler is 25 pages.
  38.  
  39. I've been rewriting many of my science programs in Sather for a couple of
  40. months now.  I've never felt the need to use the debugger. Best
  41. experience---I wrote 2000 lines or so "cold" at the beginning.  This was the
  42. bare minimum setting up all the classes before I could get anything
  43. reasonable to run. Once I got it to compile, I ran it once, and got a
  44. checked run-time error.(line# and file).  The bug was trivial to fix.  I
  45. recompiled, and reran and the damn thing worked perfectly. "I'm not
  46. worthy! I'm not worthy!" :-)
  47.  
  48. In any case, there are lots of "low-brow" items that I think C++
  49. blows completely that make a big difference in productivity.  For
  50. example, you can compile Sather programs with run-time checking, so that
  51. it is *impossible* to core-dump or stomp random memory.  (factor of 2
  52. in speed, I'd say) This has saved me in minutes from bugs that would take
  53. hours to find in C, and other bugs that are probably still hiding in
  54. my programs.
  55.  
  56. The benefits of garbage collection can also hardly be overstated.
  57. How much of real C++ class libraries is devoted to figuring out exactly
  58. when to allocate and deallocate, and when who's allowed to assign to what?
  59. Ever have a dangling pointer to previously freed memory?  Doesn't happen
  60. with GC.
  61.  
  62. There are other languages that have great advantages over C++.  Some
  63. may even be efficient, c.f. Modula-3.  (I think I"ll still like
  64. Sather better though).
  65.  
  66. : I think that is enough for now, thanks in advance for your comments
  67. : 
  68. : Paul
  69. : Software Maintenance Group, Software Technology Division, BT
  70. : Research Labs, Martlesham Heath, Ipswich, IP5 7RE, UK
  71. : E-mail:  pkeddie@axion.bt.co.uk
  72. : Phone:  +44 473 649154
  73. : Fax:    +44 473 643019 
  74.  
  75. --
  76. -Matt Kennel          mbk@inls1.ucsd.edu
  77. -Institute for Nonlinear Science, University of California, San Diego
  78. -*** AD: Archive for nonlinear dynamics papers & programs: FTP to
  79. -***     lyapunov.ucsd.edu, username "anonymous".
  80.