[tlug] "Go Considered Harmful"

["Stephen J. Turnbull" <turnbull.stephen.fw@example.com>]

Curt J. Sampson writes:

 > > Oh, no, you don't.  Before Linus came Richard (Gabriel, 1989).  
 > > https://www.jwz.org/doc/worse-is-better.html, read the whole thing,
 > > but pay careful attention to paragraphs containing the word "virus".
 > 
 > I think that what Gabriel misses in that paper, or at least doesn't really
 > make clear, is that writing "real" programs is almost invariably about
 > making _engineering_ decisions.

Oh, I thought he made it clear in the caricature that he led with,
which failed to make it to the level of satire.  "Although that may
only be obvious if you're [an economist]."

 > But they use it not because they don't know how to make a design
 > "better" or are just too lazy to do so,

That's the "ultimate computer virus" remark.  That short letter is
remarkably deep (at least from the social science point of view).

 > but because they do risk analyses and cost-benefit analyses and,
 > find and use ways of mitigating risk introduced by lower cost and
 > "worse" techniques,

Indeed.  I think that is *implicit*, but YMMV.  It's useful for you to
make it *explicit* here. ;-)

 > > OTOH, python -m this is shorter (though later, Peters, 1999).
 > 
 > Yes, and also unfortunately half nonsense,

You sir, are obviously not Dutch.

More seriously, the Zen of Python is not about coding, but rather
about language design.  Programmers, and maybe even engineers, are
going to be violating the Zen in their code all the time.  The world
is not "simple", it's usually even "complicated".  If you're writing a
program that does "real work" (rather than automating your messy
paperwork shuffle), most likely your implementation is going to be
"hard to explain", but that doesn't make it a "bad idea".  On the
other hand, when you're designing a language, you don't want the
programmers who need to deal with domain complications to have to deal
with unreadable language constructs whose semantics are hard to
explain.  Compare the masterpiece of unified obfuscation that is the
Common Lisp "do" special form with Python's pair of "while" and "for".

 > that even Python doesn't follow.  Consider even "implicit is better
 > than explicit."

Quote much? :-)  python -m this | grep is your friend.

 > I doubt many Python programmers, on seeing
 > 
 >     y = a*x**2 - b*x + c
 > 
 > would ask you to change it to
 > 
 >     y = (a*(x**2)) - (b*x) + c
 > 
 > much less tell you to abandon the use of `flag=None` in function
 > argument definitions, `from m import f` statements, and always
 > write `print("...", file=sys.stdout)`.

"Explicit" does not mean "eschew defaults."  All of those are quite
explicit.  Except for "None" in "flag=None", which typically doesn't
tell you anything about what the default means.  What this koan means
is "the default must be obvious to a typical practitioner who is not a
language lawyer" and "don't depend on context hidden in a state
variable".  (Especially a dynamically-scoped variable.<chortle/>  And
what was that you were saying about "parser state" and Plain Old
Python Functions? ;-)

 > And "special cases aren't special enough to break the rules"?

The best thing about the Zen is that it's like the Bible: there's
always a verse to justify what you wanted to do anyway.  That one is
immediately followed by "Although practicality beats purity."  

 > Given the "rules" that programmers are usually adhering to, this is
 > utter rubbish, in my experience usually leading to code that trades
 > clear expression of what it's trying to say for appeasement of the
 > consistency hobgoblin.

You don't program enough Python!  Drink the Kool-Aid Curt!  Drink!

I don't think the rules are the problem.  I think the problem is the
programmers, and the dire scarcity of software engineers, especially
among project managers.

Steve