What's your favorite year end method?

[Donald Allen]

On Dec 25, 2007 10:13 AM, Mike or Penny Novack
<stepbystepfarm at mtdata.com> wrote:
>
> >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.

Ever written any early Fortran? Basic? It's well-nigh impossible to
write easy-to-understand, well-structured code in those languages.
Yes, those are extreme examples from the dark ages, but as we've
already discussed, we're debating shades of gray here among our
choices of modern languages. I'm simply arguing that there's
significant  dynamic range in the quality of today's languages and
that, in my opinion, the best programs in (what I consider) the best
of the languages are considerably easier for someone else to
understand (or yourself to understand when you come back to your own
code a year later) than (what I consider) the lesser languages,
assuming equal familiarity with the languages in question.

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

I don't really see what that has to do with what we're discussing. I'm
making a very simple statement: since we were schoolkids, we've
learned to write infix arithmetic expressions. Fact. Most high-level
programming languages, Lisp, Scheme, and Forth being obvious
exceptions, allow you to write infix arithmetic statements, as were
taught in school and have done ever since.  Most programmers tend to
prefer that, a big factor in the resistance to Lisp dialects, I think.
Arithmetic expressions aren't the whole story, of course. They look at
the syntax of Lisp, and no amount of discussion about the semantic
cleanliness of the language will move them -- their brains have
already shut down. Too bad, but true in my experience.

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