home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / transput / 931 < prev    next >
Encoding:
Internet Message Format  |  1992-08-16  |  2.2 KB
  1. Path: sparky!uunet!mcsun!uknet!yorkohm!u9dmlb
  2. From: u9dmlb@ohm.york.ac.uk (Duncan McL Barclay)
  3. Newsgroups: comp.sys.transputer
  4. Subject: Re: occam
  5. Message-ID: <1992Aug16.205438.6380@ohm.york.ac.uk>
  6. Date: 16 Aug 92 20:54:38 GMT
  7. References: <2490@news.cerf.net> <1462@eagle.ukc.ac.uk> <46@pine.ukc.ac.uk>
  8. Organization: Electronics Department, University of York, UK
  9. Lines: 45
  10.  
  11. In <46@pine.ukc.ac.uk> arc1@ukc.ac.uk (tony) writes:
  12.  
  13.  
  14. >In your opinion that is - this smacks too much of Orwellian
  15. >overtones to me.  Why not let the programmer choose?
  16. >Ok, it provides a standard layout, but open things up and
  17. >let people decide over time what they want and they'll come
  18. >up with a good working convention (or conventions) for
  19. >layout.  I don't like having it enforced arbitrarily from
  20. >on-high.
  21.  
  22. Hmm intersting, coz if you extend the 'on_high' argument why arent you
  23. using your own programming language on your own system based on your own
  24. VLSI process.
  25.  
  26. >Warren> Formatting a program in this way is good as one uses spacial relationships to indicate
  27. >Warren> the programs structure.
  28.  
  29. >Not convinced.  Being forced into a particular layout
  30. >doesn't, for me anyway, feel nice.  I'd like to learn what a
  31. >good layout style is by getting it wrong, messy, learning
  32. >from others etc.  It's a more constructive learning
  33. >experience.
  34.  
  35. I agree, but if other people have done the messing about to find the
  36. most natural way why not give it a try? In fact the OCCAM rules correspond to
  37. my own preferred style of programming.
  38.  
  39. >Warren> , which cuts out the need of lots of end, od, esac, }
  40. >Warren> and fi keywords.
  41. >But they do make block encapsulation easier to see on the
  42. >screen.
  43.  
  44. I disagree, fortunately or unfortuantely my first real programming experience
  45. was in FORTRAN which has very few block ends etc, and one gets used to
  46. seeing the structure of the code without the brackets, in fact one usually
  47. blocks the code on the screen. When moving onto C etc I found the brackets
  48. annoying, not only to type but because in some cases they are tacked
  49. onto the end of a line or placed seperately, tracking down the end of
  50. a block is hard. OCCAM makes it easier to see. 
  51.  
  52.  
  53. -- 
  54. Raggy                 | God smiles upon the little children, the alcoholics, and
  55. u9dmlb@ohm.york.ac.uk | the permanantly stoned. S.King.
  56.