home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / c / 13021 < prev    next >
Encoding:
Internet Message Format  |  1992-08-31  |  2.8 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!asuvax!ncar!noao!amethyst!organpipe.uug.arizona.edu!news
  2. From: dave@cs.arizona.edu (Dave Schaumann)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Most difficult part of learning C?
  5. Message-ID: <1992Aug31.171806.5168@organpipe.uug.arizona.edu>
  6. Date: 31 Aug 92 17:18:06 GMT
  7. References: <9208251159.AA04122@ult4> <1992Aug26.103256.5267@itnsg1.cineca.it> <drice.714872469@ponder> <714939390@romeo.cs.duke.edu>
  8. Sender: news@organpipe.uug.arizona.edu
  9. Reply-To: dave@cs.arizona.edu (Dave Schaumann)
  10. Distribution: usa
  11. Organization: University of Arizona
  12. Lines: 52
  13. In-Reply-To: trt@duke.cs.duke.edu (Tom Truscott)
  14.  
  15. In article <714939390@romeo.cs.duke.edu>, trt@duke (Tom Truscott) writes:
  16. >The biggest difficulty in learning C that I have encountered
  17. >is the lack of a hand-holding coding&testing environment.
  18.  
  19. Yeah.  One of the first programs I wrote did some simple array manipulation.
  20. I couldn't figure out why it was crashing on exit.  After much head-scratching
  21. and code dissection, I finally realized that I was accessing my arrays from
  22. 1 to N instead of 0 to N-1.
  23.  
  24. Now, the fact that C will let you do just about anything you want is very
  25. useful to the experienced programmer, but it also has the tendency to
  26. ensnare the neophyte.
  27.  
  28. IMHO, I think that new programmers can profitably start out in C -- they
  29. just need to be aware of the pitfalls.  Even a short list of rules could
  30. be eminantly helpful.  But if you just send them out there with no
  31. preperation... all you're going to get is a roomfull of students that hate C.
  32.  
  33. >A difficulty I have not seen mentioned is in learning how
  34. >to use the boolean operators & | ^ ~.
  35.  
  36. Of course, these are not boolean operators -- they are bit operators.
  37. But I agree.  They can easily be skipped.
  38.  
  39. >Some difficulties can be circumvented by avoiding them entirely.
  40. >In my opinion the following can be omitted:
  41. [...]
  42. >    enumerated types
  43.  
  44. What?!  Noooo!  Enumerated types are an incredibly useful feature!
  45. The ability to give things a symbolic name is essential to good
  46. programming.
  47.  
  48. [...]
  49. >    typedefs
  50.  
  51. Similarly with typedefs.  Perhaps you don't need them in a first semester
  52. programming class, but I wouldn't delay introducing them past the second
  53. semester.  Like symbolic names, the ability to construct abstract types
  54. (as opposed to clusters of structs and pointers) is essential to programming.
  55.  
  56. >Is the purpose of the course to explore every last corner of the C language,
  57. >or is it to teach some topic for which C happens to be appropriate?
  58.  
  59. IMHO, the purpose of the course should be to teach programming first, and C
  60. second.  If approached in the right manner, C's draw-backs can even be used
  61. to advantage in a programming course (show how to program defensively, show
  62. the importance of formatting your code reasonably, and choosing good variable
  63. names, etc., etc.)
  64.  
  65. -- 
  66. Dave Schaumann            dave@cs.arizona.edu
  67.