home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / ada / 3640 < prev    next >
Encoding:
Text File  |  1992-12-12  |  4.3 KB  |  94 lines
  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!seas.gwu.edu!mfeldman
  3. From: mfeldman@seas.gwu.edu (Michael Feldman)
  4. Subject: Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)
  5. Message-ID: <1992Dec12.175323.26128@seas.gwu.edu>
  6. Sender: news@seas.gwu.edu
  7. Organization: George Washington University
  8. References: <1992Dec8.172551.16780@newshost.lanl.gov> <1992Dec9.060218.23940@seas.gwu.edu> <9234801.7095@mulga.cs.mu.OZ.AU>
  9. Date: Sat, 12 Dec 1992 17:53:23 GMT
  10. Lines: 82
  11.  
  12. In article <9234801.7095@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  13. >
  14. >A good compiler would give a warning that the call to printf was
  15. >unreachable code. The only compiler I have available, gcc, unfortunately
  16. >doesn't give any such warning. But the Pascal-subset compiler I wrote (as one
  17. >of the projects for a 3rd-year subject) gives the following warnings for
  18. >the equivalent Pascal code:
  19. >
  20. >warning: variable 'x' is not used after assignment, so assignment has no effect
  21. >warning: 'while' statement will cause an infinite loop
  22.  
  23. This is particularly good "advising" on the part of the compiler. A good
  24. compiler is really a rule-based system, with lots of heuristics that
  25. represent the domain expertise (potential logic errors). Most compiler
  26. writers don't bother. The syntax and associated semantics of a carefully
  27. designed language should work to minimize this sort of error anyway.
  28.  
  29. In the Pascal case, I believe that whether a null statement is legal
  30. turns out to be implementation dependent. Great standard.
  31. >
  32. >>Any similar idiosyncracies in Ada? 
  33. >
  34. >The difference between '<' and '>' is only a single keystroke.
  35. >More insidious perhaps is the difference between '<' and '<='.
  36. >So it can happen even in Ada. 
  37. Well, this is a bit different. "+" and "*" are single keystrokes too.
  38. Arithmetic operators generally are. At least the operator is saying what it
  39. means a little more clearly.
  40.  
  41. A better Ada example is the problem of procedure specifications vs. bodies.
  42.  
  43. PROCEDURE P;
  44.  
  45. is a valid statement in most contexts, so
  46.  
  47. PROCEDURE P;
  48. BEGIN
  49.   -- something
  50. END P;
  51.  
  52. will often lead to propagation errors. This is confusing to students
  53. because the error messages don't point to the real error location.
  54. Try it on your favorite compiler; most Ada compilers have little or
  55. no "expertise" that would catch this. Ada/Ed picks up some of it;
  56. discussion with the GNAT folks informs me that their parser has a
  57. lot of this kind of intelligence. 
  58.  
  59. But at least the ";" vs. "IS" problem is picked up _somewhere_ as a
  60. compilation error. The single keystroke ";" problem in C arises because
  61. people carelessly type extra semicolons where they don't belong. The
  62. magnitude of the logic bug is far out of proportion with the magnitude
  63. of the keying error. These things should (somehow) be more proprtionate.
  64.  
  65. Intuitively, in Ada they are. Having taught intro-level Ada to many 
  66. hundreds, if not thousands, of students, I have found quite consistently
  67. that - at that level - a program that compiles without errors will
  68. _generally_ run without really strange behavior. Of course, this does
  69. not prevent students from writing programs with logic errors, but
  70. those are generally _logic_ errors and not _keying_ errors.
  71.  
  72. I have had very many students and colleagues who have studied and used
  73. both Ada and C. I've never done a formal survey, but my informal survey -
  74. done as far as possible without bias, leads me to a fairly form conclusion
  75. that the real work in coding an Ada program (design questions aside!)
  76. is in getting it through the compiler, while the real work in coding
  77. a C program is in finding the reasons for the unexpected run-time
  78. behavior. I am NOT arguing Ada's "superiority" in any global sense,
  79. just pointing out where the real workload seems to be in both languages.
  80. (At least this is true in the environments I have worked in.)
  81. >
  82. >However I do agree that Ada syntax is less error-prone than C or Fortran.
  83. >This is not because it is verbose but rather because the Ada designers took
  84. >this issue into careful consideration. I believe that it would be quite
  85. >possible to design a syntax that was concise but that was no more error-prone
  86. >than Ada.
  87. >
  88. Programmers seem to have a "thing" about verbosity. Ada's designers were
  89. quite open about their intention that Ada code be easier to read than to write,
  90. because as Pascal Obry pointed out yesterday, a program is written once but
  91. read hundreds of times.
  92.  
  93. Mike
  94.