home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12263 < prev    next >
Encoding:
Text File  |  1992-08-12  |  5.2 KB  |  111 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  3. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  4. Subject: Re: Handling of operator . pro
  5. Message-ID: <9222523.7061@mulga.cs.mu.OZ.AU>
  6. Sender: news@cs.mu.OZ.AU
  7. Organization: Computer Science, University of Melbourne, Australia
  8. References: <memo.565691@cix.compulink.co.uk>
  9. Date: Wed, 12 Aug 1992 13:32:47 GMT
  10. Lines: 99
  11.  
  12. vadim@cix.compulink.co.uk (Vadim Lebedev) writes:
  13.  
  14. > fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
  15. > writes:
  16. >
  17. >> >Well, 20 years is a little exagerated, but i'm sure that the time needed
  18. >> >to learn to use some feature of the language is MUUUUUUUUCH shorter than
  19. >> >the time needed to design and implement it's simulation it when the feature
  20. >> >is missing from the language (ERRTI for exemple).
  21. >> 
  22. >> *Someone* has to implement these features - the choice is between
  23. >> whether this is done by the language implementor or the programmer.
  24. >> All of the features you mention are not trivial to implement.
  25. >
  26. >Exactly!!! That IS the reason i want them to be implemented ONCE by the
  27. >language implementor, and not MULTIPLE times by compiler users.
  28.  
  29. There is more than ONE language implementor...
  30. OK, there are more programmers than compiler writers :-)
  31.  
  32. However, typically it is easier (requires less work) for the programmer
  33. to use a work-around and code what they want using existing language
  34. features than to modify the compiler to add a new feature to the
  35. language. There *is* a cross-over point at which modifying a compiler
  36. once is easier than using a work-around say 30 times, but there are
  37. other disadvantages with shifting the work onto the compiler-writer.
  38.  
  39. Compilers become more expensive, which discourages beginners, so the
  40. language becomes less popular. (This in turn leads to less resources
  41. being spent on compilers and tools for the language). Compilation
  42. becomes slower. Compilers occupy more disk space and take longer to
  43. install.  Also compilers become more error-prone; it is a lot easier to
  44. fix a bug in your work-around than to fix a bug in the compiler.
  45.  
  46. >> Also a good programmer MUST master the language they are using, for two
  47. >> reasons: firstly so as to enable them to write *good* programs, and
  48. >> secondly so that they can maintain other peoples programs.
  49. > 
  50. >Ok, suppose we have a C++ program which NEED some feature (by NEED
  51. >I mean that the program design is greatly simplified by availability
  52. >of this feature) that is missing
  53. >from the language (RTTI for exemple). The program designer have 2 choices
  54. >1) Design and implement some approximation of RTTI
  55. >2) Use an existing library which already implement RTTI in some way 
  56. >
  57. >The eventual maintainer will have to wonder: 
  58. > "How the guy did this RTTI stuff?"
  59. >
  60. >Now, if we had the feature IN the language, the situation becomes much
  61. >simpler, the program designer does not have to evaluate different choices
  62. >it simply can use the feature, and the maintainer simply have to know
  63. >the language, to understand how the thing works.
  64.  
  65. If the language becomes too complex, then "simply knowing the language"
  66. becomes a non-simple task. On the other hand if some feature has been
  67. coded using the facilities of a simple language, the maintainer can
  68. SEE how it works, by reading the code.
  69.  
  70. The ideal is to have a language that is simple but powerful and extensible.
  71. This is the idea behind using standard library i/o functions rather than
  72. special builtins, overloading rathern than printf %-specifiers, etc.
  73.  
  74. >> To quote my Programming Languages textbook [Watt],
  75. >>         "Simplicity should always be a goal of language design."
  76. >
  77. >The question is: "What simplicity?"  Learning simplicity, or usage simplicity?
  78. >Don't you agree with me that in the above exemple the language with RTTI 
  79. >built-in is simpler to use than the language without it?
  80. >Actually the learing simplicity and usage simplicty are often two 
  81. >contradicting requirements. To satisfy both of them a programming language 
  82. >should be designed in such a way that you could
  83. >learn and use it gradually in subsets. In this case the base subset is still
  84. >simple to learn, and you learn about advanced features only when you need
  85. >to use them.
  86.  
  87. Often it is not clear whether you should use a feature until after you
  88. have learnt it, so this is difficult.
  89.  
  90. Also you have to learn the advanced feature every time you are maintaining
  91. code that used it, even if that code could have been written using only
  92. simpler features.
  93.  
  94. >> If you think otherwise, then have a look at PL/1 as an example of a language
  95. >> gone wrong (because of rampant "featurism").
  96. >
  97. >I really LOVE PL/1. Especially when i was using IBM OPTIMIZING PL/1 
  98. >compiler and IBM CHECKOUT PL/1 compilers (which is actually an interactive 
  99. >interpereter) which had an excellent macro pre-processor.
  100. >I learned and used all and every feature of this language. 
  101. >I don't think that this language is 'gone wrong'.
  102.  
  103. I shouldn't have said PL/1 (I have never learnt that language, I was just
  104. repeating what I have heard and read). Instead I should have said C++ :-)
  105.  
  106. -- 
  107. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  108. This .signature VIRUS is a self-referential statement that is true - but 
  109. you will only be able to consistently believe it if you copy it to your own
  110. .signature file!
  111.