🚀 go-pugleaf

In article <ROCKWELL.91Jun22014535@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Rockwell) writes:
 
> Anyways, the point [or the "insight", if you prefer] was that
> "write-only" is a reflection on programmer skill in a language more
> than a reflection of the language itself.

(Disclaimer up front:  I work for SMDS, with Richard Harter, who wrote
Lakota and is in this discussion.  The following isn't a plug for Lakota 
in particular, though.)

I disagree strongly.  When you write a program, you transform your
ideas into a form that the computer can use.  In some languages, the
transformation scrambles the evidence of the original thinking process.
In other languages, it's better preserved, so that you can go back and
pick up where you left off.

You might say that a "good" programmer can write a clear program in
any language.  This deserves two responses.  The first is that the design
of a language (or anything else) should have its users in mind.  If the
typical, or natural, way programmers use a language is write-only, then
that's the language designer's fault.  Blaming users for the faults of
our designs is one of the crappiest tendencies of computerists, and it's
not mitigated by applying the same macho ethic to ourselves as users of
languages.  So, perhaps a programmer could write a clear program in a
given language, but if the language makes this hard for some people, or if 
it takes a long time for them to learn how to do it, then the language is 
write-only for those people.

Second, it's not true that you can write any program clearly in any
language.  In the process of making a program "clearer" in a bad
language, all you can do is add complexity--extra variables, extra lines, 
extra function definitions, extra comments--and make the program bigger, 
with more parts.  This pushes details over the horizon, so that at any one 
point, you can see less and less of the relevant detail you need (and more 
and more stuff that's just compensating for the weakness of your language).

--Steve