What's your favorite year end method?

[Donald Allen]

On Dec 25, 2007 9:44 AM, Mike or Penny Novack <stepbystepfarm at mtdata.com> wrote:
>
> >It's not a question of what the language allows.  It's all about
> >how the programmer uses it.
> >
> >
> ABSOLUTELY!
>
> You can write clean, easy to understand, well self documented code in
> any language.

You've written assembly-language code, as you mention below. Do you
think well-crafted assembly code is close to as easy-to-understand as
well-crafted <pick a good high-level language>?

> You can also write inscrutable crap in any language.

While true, I think it's beside the point. I think what we ought to be
optimizing here is, in part, choosing a language that will provide
good programmers a platform for doing what they do well, unimpeded.

>
> Some languages are a little easier to abuse than others (to either
> accidentally or intentionally write hard to read code). But that's only
> a matter of degree.

Everything we're discussing is a matter of degree! Nothing is absolute
here. We're debating the degrees.

Trust me, you can write hard to read code even in
> COBOL.

Wow. I think it's *easy* to write hard-to-read code in Cobol, with
it's over-the-top verbosity.

 What matters far more than what the language might be are things
> like whether the programmer made intelligent (meaningful) choices for
> names,  writes clean well structured code, and refrains from using any
> "tricks" not explained by comments.

All true. But I'm assuming that there will be some screening process,
perhaps embodied in people like Derek and Josh, that will insure that
only the work of people who know what they are doing will make it into
the SVN repository (perhaps this wasn't always true, having just read
Derek's comment that some of the reports are O(n^3) in the number of
transactions, but I'm guessing that this will not be an issue, given
the quality of the current lead developers). So if we assume good
programmers, then the issue boils down to not impeding them with
second-rate tools.

>
> The question may be in terms of "what is the average programmer likely
> to do when using language X". Not just the original designer/writer but
> those who have to maintain it later.
>
> Michael
>
> PS: IMHO the "problem" is not programmer unfamiliarity with (any)
> language but insufficient learning about "fundamental data structures
> and the algorithms that process these". By an large the introduced newer
> and or "higher level" languages are based around the concept that the
> average programmer doesn't know these language independent basics and so
> facilities are provided to provide "built in" capability. Doesn't really
> work.
>
>      Please understand that this viewpoint is from a person who
> sometimes had to design little systems which would work and could be
> maintained by programmers who did NOT understand the fundamental
> concepts behind the function (say a quick look up "exception table"
> which used  "hash table of lists" which could be maintained, expanded in
> capacity, etc. by programmers who understood neither hash tables nor
> list processing). We were considered an excellent, well trained shop,
> but how good could the coding be when the few times I had to replace
> program written in a high level language with one in assembler (critical
> speed issue) I end up with an assembler program that in spite of being
> well commented has far fewer lines that the COBOl or whatever original!
> (a typical single high level language statement is several lines of
> assembler).
>