🚀 go-pugleaf

In article <1992Dec28.003320.5437@sequent.com> furballs@sequent.com (Paul Penrod) writes:
>In article <1992Dec27.031740.27262@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
>>In article <1992Dec25.073517.16089@grebyn.com>, malak@grebyn.com (Michael Malak) writes:
>>> In article <1992Dec25.050515.20871@ncsu.edu> bank@lea.csc.ncsu.edu (Belgarath the Sorcerer) writes:
>>
>>> >4) Even if you're not going into OOP, do NOT take up Pascal as
>>> >    a road to C. ...
>> 
>>> Oh?  Have you ever seen C code written by a former FORTRAN programmer?
>>> If so, by how many?  Universally you will find:
>>>    1) Very short, illegible variable and function names, with the
>>>       first character wasted (all integers must start with 'i', don't
>>>       you know)
>>>    2) No use of structures
>>>    3) No linked lists or trees
>>>    4) No whitespace
>>>    5) Lots of illegible "creative" formulas
>>>    6) No comments
>>
>>As one who learned FORTRAN first, I consider this a slur; were it applied
>>to me directly it would be a libel.  The word `Universally' is used in
>>error.
>>
>>Before I learned C I began to declare all my FORTRAN variables; there
>>were no wasted initial letters.  And after I learned C, my FORTRAN began
>>to look like C.
>>
>>A FORTRAN programmer who meets bad C will not learn good habits from it;
>>a FORTRAN programmer who meets good C will.  `Good C' does not just mean
>>C free from the defects you give; it means C that expresses a good design
>>using C's idioms well.
>>
>>If the FORTRAN programmer whom you have watched learn C did not have good
>>C to learn from, do not blame C.
>>-- 
>> (This man's opinions are his own.)
>> From mole-end				Mark Terribile
>>
>> mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
>
>This is so true. People forget that the language is the human form
>of expression to the computer of EXACTLY what to do. Features don't
>really mean anything, unless they are directly applicable to a
>particular solution.
>
>But, more to the point, to support your position, a properly
>thought out algorithym that is expressed cleanly can be followed to
>its conclusion no matter what the language. I had the opportunity
>to convert some AI based material from LISP to C a while back.
>Having never learned LISP, I was a bit concerned that one of the
>features of the language would cause me no end of grief in trying
>to understand what the software designer had in mind.
>
>Fortunatly the designer had anticipated his code would require
>support in the future and wrote it with that in mind. It became not
>only a very good expression of the problem he was solving, but an
>excellent example in how to write good LISP code as well.
>
>My biggest headache with PASCAL is that it tries to force the
>programmer to think in bounded terms, the likes of which they never
>seem to recover without a lot of grief in the process. I really
>dislike the type restrictions, plus the brain dead way the force
>you to declare things up front. Using it to develop, in my opinion,
>would be the same as forcing an author to write a book, with no
>Thesaurus, Dictionary, or documentation for the brand new WP he's
>just received on the desk; which he's never seen before.
>Eventually he'll get there, but not without a lot of aggravation
>and serious stifling of creative expression. In a sense the tool
>determines the solution path, not the programmer.
>
>JMHO...

Now just where is a beginner supposed to learn "cleanly-expressed" C,
given a background in FORTRAN?

One of my points somewhere in this thread was that all the structured
programming teachers know Pascal, not C.