home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / compiler / 2141 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  2.8 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code
  5. Keywords: optimize, performance, debug
  6. Message-ID: <93-01-068@comp.compilers>
  7. Date: 12 Jan 93 00:57:55 GMT
  8. Article-I.D.: comp.93-01-068
  9. References: <93-01-041@comp.compilers> <93-01-065@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
  12. Organization: The Johns Hopkins University CS Department
  13. Lines: 43
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16. nickh@CS.CMU.EDU (Nick Haines) writes:
  17. > 4. Use of a language with a good type system eliminates the
  18. > edit-compile-bomb-edit cycle, ... Typechecking is (in general) much
  19. > faster than compilation because it includes no optimisation or code
  20. > transformations.
  21.  
  22. In article <93-01-065@comp.compilers> jlg@cochiti.lanl.gov (J. Giles) writes:
  23. >Then your programs are considerably different from what I'm familiar with.
  24. >Most errors are not syntactic or static semantic errors (like type
  25. >errors).  The vast majority of debugging time is spent isolating and
  26. >correcting problems which are not - and cannot be - found by the
  27. >typechecks no matter how strict your type system is. 
  28.  
  29.     Hmmm; well, if this is your experience then it is very different
  30. than mine!  I think that my most common coding errors are (in order of
  31. decreasing frequency):
  32.  
  33.     1) Typographical errors, such as misspellings of keywords and
  34.        identifiers.
  35.     2) Failing to pass parameters to a function in the correct order,
  36.        or neglecting to pass all of the necessary parameters.
  37.     3) Using "=" for "==", especially after I've been coding in
  38.        something other than C for a while!  :-)
  39.     4) Incorrectly dereferencing some pointer to a complicated data
  40.        structure, or incompletely following a chain of pointers.
  41.     5) Attempting to add new functionality to a piece of code after
  42.        1:00 AM.  :-)
  43.     6) Bugs in the documentation of system calls and library functions.
  44.     7) Being a general bonehead!
  45.  
  46.     Obviously, a typechecker will catch most of the errors of types
  47. 1,2,3,and sometimes 4, which probably accounts for 85% or more of the
  48. _errors_ in my code.  Of course, since these are so easy to fix, this
  49. probably only amounts to 15% of by debugging _time_.  Of course, that is
  50. to the typechecker's credit, not it's detriment.  After all, if one had
  51. the Acme Super-Duper Bug Remover, that removed all of a programs bugs in
  52. minutes, you'd say that debugging programs is easy and we should waste our
  53. time talking about it.  ;-)
  54. --
  55. Jack Eifrig (eifrig@cs.jhu.edu)       The Johns Hopkins University, C.S. Dept.
  56. -- 
  57. Send compilers articles to compilers@iecc.cambridge.ma.us or
  58. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  59.