🚀 go-pugleaf

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...

-- 
--------------------------------------------------------------------
            Bureaucracy: noun, plural - Bureaucracies.
         The process of turning energy into solid waste.
---------------------------------------------------------------------