home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 16951 < prev    next >
Encoding:
Text File  |  1992-11-21  |  1.9 KB  |  59 lines
  1. Path: sparky!uunet!mcsun!sun4nl!and!jos
  2. From: jos@and.nl (Jos Horsmeier)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Pascal as C prelude?
  5. Message-ID: <3903@dozo.and.nl>
  6. Date: 21 Nov 92 15:38:27 GMT
  7. References: <forb0004.94.722315425@student.tc.umn.edu>
  8. Organization: AND Software BV Rotterdam
  9. Lines: 48
  10.  
  11. In article <forb0004.94.722315425@student.tc.umn.edu> forb0004@student.tc.umn.edu (Eric Forbis) writes:
  12. |The U of Mn suggests, but does not require, taking a quarter of Pascal 
  13. |before taking C. I have no experience with pascal, but have read that the 
  14. |two languages utilize similar concepts and structures couched in different 
  15. |terms. Is pascal really a useful introduction to C- should I be taking 
  16. |that class after all? It's not my intent to start a C vs pascal flame war 
  17. |here... It seems to me that, if pascal is that similar to C, you might as 
  18. |well forego pascal and hop right into C. 
  19.  
  20. Yes, you could do that, but if you're new to _programming_, you would
  21. hop right into a slimey can of worms. The C programming language allows
  22. a programmer to do about anything s/he can come up with, using his/her
  23. perverted mind ;-) The compiler doesn't really care what you're doing,
  24. there's no rigid runtime system linked with your code to protect you
  25. against small errors you accidentally included in your code. On the
  26. other hand a Pascal compiler (and runtime system) take you by the hand
  27. and lead you through all twisty passages called programming. 
  28.  
  29. My advice is: study Pascal first and when you think you've got a firm
  30. notion of pointers, pointer arithmetic, dynamic memory allocation and
  31. all sorts of wonderful stuff, switch to C. 
  32.  
  33. #define SILLY_MODE
  34. #ifdef SILLY_MODE
  35.  
  36. There's just one drawback, when you do this: you'll end up writing
  37. ugly formatted code like:
  38.  
  39. if (condition)
  40.     {
  41.     statement1;
  42.     statement2;
  43.     }
  44.  
  45. instead of the proper:
  46.  
  47. if (condition) {
  48.     statement1;
  49.     statement2;
  50. }
  51.  
  52. #endif
  53.  
  54. ;-)
  55.  
  56. kind regards,
  57.  
  58. Jos aka jos@and.nl
  59.