home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / cplus / 18547 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  4.0 KB
  1. Path: sparky!uunet!olivea!gossip.pyramid.com!pyramid!infmx!cshaver
  2. From: cshaver@informix.com (Craig Shaver)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: feedback wanted on appropriate OOPL
  5. Message-ID: <1992Dec30.171527.3534@informix.com>
  6. Date: 30 Dec 92 17:15:27 GMT
  7. References: <1992Dec28.173620.14793@microsoft.com> <1992Dec29.011354.5929@informix.com> <1992Dec29.230713.9401@microsoft.com>
  8. Sender: news@informix.com (Usenet News)
  9. Organization: Informix Software, Inc.
  10. Lines: 88
  11.  
  12. In article <1992Dec29.230713.9401@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:
  13.  
  14. .....
  15.  
  16. >
  17. >I am expected to provide you with concreate evidence about an
  18. >interview candidate ???  The kinds of problems I'm talking about
  19.  
  20. No.
  21.  
  22. >are people who don't know the difference between pointers and
  23. >references and pass-by-value, don't understand const, don't know 
  24. >how to program without GC, can't get pointers right, don't get 
  25. >their Ctors and Dtors right, who want to do everything on the heap, etc....
  26.  
  27. Sounds like these people lied to you.  But, what about style?  You are
  28. talking about language implementation details.  I have seen your postings
  29. for several years Jim, and I think you have been too hung up on the 
  30. particulars of the language rather than real world use of the
  31. language.  We may have some basic semantic differences rather than
  32. philosophic differences.  By style I mean problem solving approaches.
  33. I believe you are talking about language features and their use.
  34. IMHO this is the achilles heel of C++.  The features get in the 
  35. way of problem solving.  There are too many details to keep track of.
  36.  
  37. Would anyone care to comment on style differences between C++ and
  38. Smalltalk?  I have seen postings that claim you must approach
  39. design differently using C++ rather than Smalltalk.  I happen to
  40. believe that Smalltalk has some good things that the C++ community
  41. should look at.  
  42.  
  43.  
  44. >I have done so many times and will again.  Consider, for example one
  45. >measure, namely the number of references in the Computer Select Database
  46. >in 1992 of articles from the major computer magazines.  Number of
  47. >references to various languages we have been discussing:
  48. >
  49. >C            39498
  50. >C++         8148
  51. >COBOL         6179
  52. >Smalltalk      841
  53. >
  54. >Same source, number of software products listed referencing each 
  55. >above language:
  56. >
  57. >C             9748
  58. >COBOL         3222
  59. >C++          572
  60. >Smalltalk       39
  61. >
  62. >If you look at a large number of languages over time, you see C/C++
  63. >gaining [C++ strongly] and leading the pack by a large margin.  Then
  64. >comes a middle grouping of a large number of historical languages --
  65.  
  66. I see a lot of talk and not a lot of use.  I think there is something
  67. driving the programmers to push managements into C++ projects -- money!
  68. Most job advertising now requires c/c++ versus just c.  Most of these
  69. jobs will not actually be doing any c++, but they want it just in case.
  70. This has been done by HR people who poll the tech xxx's for what's hot
  71. and put it in the ad.  The tech xxx's see the ads and buy books on
  72. c++ just to cover their ass.  In the first flush of a new religion
  73. they push c++ internally.  Management stonewalls but HR puts it in
  74. the ads just in case.  And so on.  
  75.  
  76. The projects that do get started in C++ may never make it out the
  77. door.  We do not hear too much about the failures.  I think we will
  78. hear about something soon from Borland.  I think these guys really
  79. bit it big.
  80.  
  81. >pascal, fortran, cobol, ... then bringing up the rear is a very large
  82. >number of "esoterica" languages that never seem to reach critical
  83. >mass for some reason or another -- typically because they never get
  84. >even one stable efficient implementation on even one popular machine.
  85. >
  86. Smalltalk is on the verge of 'esoterica' I admit.  It is bloated and
  87. inefficient.
  88. >
  89. >Other simple "measures" are to go to a good computer book store and
  90. >count the number of texts available for different languages.  C++
  91. >has 100+ texts in print, for example.
  92. >
  93. See above comments.
  94.  
  95. .... deleted ....
  96.  
  97. -- 
  98. Craig Shaver  (cshaver@informix.com for now) (415)390-0654 (415)926-6407
  99. Productivity Group POB 60458 Sunnyvale, CA  94088
  100.