What's your favorite year end method?
Mike or Penny Novack
stepbystepfarm at mtdata.com
Tue Dec 25 09:44:18 EST 2007
>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 can also write inscrutable crap in any language.
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. Trust me, you can write hard to read code even in
COBOL. 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.
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).
More information about the gnucash-user
mailing list