🚀 go-pugleaf

In <46@pine.ukc.ac.uk> arc1@ukc.ac.uk (tony) writes:


>In your opinion that is - this smacks too much of Orwellian
>overtones to me.  Why not let the programmer choose?
>Ok, it provides a standard layout, but open things up and
>let people decide over time what they want and they'll come
>up with a good working convention (or conventions) for
>layout.  I don't like having it enforced arbitrarily from
>on-high.

Hmm intersting, coz if you extend the 'on_high' argument why arent you
using your own programming language on your own system based on your own
VLSI process.

>Warren> Formatting a program in this way is good as one uses spacial relationships to indicate
>Warren> the programs structure.

>Not convinced.  Being forced into a particular layout
>doesn't, for me anyway, feel nice.  I'd like to learn what a
>good layout style is by getting it wrong, messy, learning
>from others etc.  It's a more constructive learning
>experience.

I agree, but if other people have done the messing about to find the
most natural way why not give it a try? In fact the OCCAM rules correspond to
my own preferred style of programming.

>Warren> , which cuts out the need of lots of end, od, esac, }
>Warren> and fi keywords.
>But they do make block encapsulation easier to see on the
>screen.

I disagree, fortunately or unfortuantely my first real programming experience
was in FORTRAN which has very few block ends etc, and one gets used to
seeing the structure of the code without the brackets, in fact one usually
blocks the code on the screen. When moving onto C etc I found the brackets
annoying, not only to type but because in some cases they are tacked
onto the end of a line or placed seperately, tracking down the end of
a block is hard. OCCAM makes it easier to see. 


-- 
Raggy                 | God smiles upon the little children, the alcoholics, and
u9dmlb@ohm.york.ac.uk | the permanantly stoned. S.King.