What's your favorite year end method?

[Mike or Penny Novack]

>So language design doesn't matter -- it's all up to the programmer? I
>disagree completely with that. I think it's a combination of the two,
>and some languages are so bad, it's almost impossible to write
>well-structured programs in them. That's why we aren't writing
>programs in Fortran II any more. Of course bad programmers will write
>bad programs in any language. But good programmers will write bad
>programs in bad languages.
>  
>
I will challenge that statement. Give me just about ANY language and I 
can write well structured, well self documented code in it. THAT isn't 
the problem. The problem is whether the average programmer given that 
program to maintain will make shambles of it. You can write well 
structured code even for an assembler.

>I think Scheme (and Lisp generally) is a special case in the
>programming language space, because the prefix syntax departs from our
>usual notation, particularly for arithmetic expressions.
>
There are just two "natural" placements, before (like LISP) or after 
(like FORTH). The usual "infix" notation for arithmetic expression means 
dependence on just how many operands the operation expects. That is 
useless for GENERAL operations. If you think the "prefix" position is 
unfamiliar, trust me, the "after position" (reverse Polish) notation 
would be even more so. FORMAL arithmetic tends to use either prefix or 
postfix. For implementers, postfix is actually easier (all evaluated 
operands are already on the stack when the function is evaluated).

>
>So if you write reports in Scheme, you restrict future development of
>them to Scheme devotees, a very small percentage of people who know
>how to write code, even the really bright ones.
>
>  
>
The REAL issue of suitability if language to task is what are the 
fundamental data objects of the language compared to the natural data 
objects of the problem. Thus the LISP family is ideal if you are 
processing lists, SNOBOL (today say bash + the standard 'nix shell 
utilities) if you are processing strings, APL if your natural data 
elements are vectors, etc. If you don't know in advance what sort of 
data you will need to be processing most of the time, the great 
generality of things like LISP family languages quite useful.

Ask rather why we see errors in coding, commonly made errors (thus 
"buffer overflow vulnerabilities" in C applications because processing 
strings of undefined length is not "natural" for C)

Michael