Re: [tlug] "Go Considered Harmful"

["Curt J. Sampson" <cjs@example.com>]

On 2020-08-31 22:49 +0900 (Mon), Stephen J. Turnbull wrote:

> Curt J. Sampson writes:
>
>  > 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.

No, it didn't come across that way to me. What the two caricatures looked
to me like were two groups who are _both_ not making real engineering
decisions. The MIT folks are (as he quite adequately explains) not making
cost/benefit (perhaps better expressed as cost/beauty, in a world where
lack of beauty has major economic consequences) tradeoffs that they should
be making to get their stuff out there and used in practice in a reasonable
timeframe.

But the New Jersey folks are even worse; they don't say "we made this
tradeoff because of XYZ," (much less, "but here's how we mitigated some of
the problems that causes"); they come across as saying, "yeah, that's hard,
so we just bailed on it."

Essentially, all the MIT guys need to do to win this battle is add "cheap
is good" to their list of characteristics, apply one of the incredible
AI-based-global-optimization algorithms they no doubt have kicking around
in their Emacs startup files :-) and boom, they're enough cheaper to
complete with New Jersey and yet still much better, particularly because
they also have (or should have) a _way_ better path to get from 80% to
100%.

> More seriously, the Zen of Python is not about coding, but rather
> about language design.

Well, the first question of course would be, "why the heck are they putting
that _there_, then?" Did they expect the designers of
NewThingThatCompilesToJavaScript to type `python -m this` before they they
started?

But that aside, and even admitting that Python is one of the
better-designed languages out there (which is maybe not a big bar to
cross), Python's language designers clearly aren't taking this to heart,
either. We can start with the indentation-based blocks. Clearly a brilliant
idea, and great of Python to look at Haskell and pick up on that. But
Haskell described, in about a page, how this could work incredibly cleanly
and Python took that and messed it up. (Why the heck does `a = 1; if True:
print(a)` give me a SyntaxError?!) You could put that down to, "oh, it's
hard to write a parser to deal with that," except that a) it was explained
how to do this on that page from the Haskell manual, and b) it has never
been fixed since then. In fact, it's been made worse when otherwise great
features such as decorators were added.

And don't even get me started on Python' "lambda."

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

No! Say it isn't so! :-)

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

Sure. But just because Common Lisp kinda (ok, maybe "utterly") failed with
their "do" special form does not mean that the correct solution is to
abandon all attempts to move beyond the state of the art in 1962.

>  Consider even "implicit is better than explicit."
> Quote much? :-)  python -m this | grep is your friend.

Ya, ya, you know what I mean.

But ok, I'll give you that if you look at the koans from the right angle,
even without squinting they're more or less on track. But really, only for
those who already know this stuff anyway.

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

Oh, I have drunk that Kool-Aid!

Possibly the the hobgoblins are perhaps not the "real" Python folks. There
are formatters out there that will happily give a pass to 82-column lines
without contortions (though I question how, if a programmer is so confused
about what he's writing that he can't even format his code to express what
he wants to say, an automated formatting program is going to help). But
that doesn't stop a large number of Python programmers from uglifying their
code to make a line three characters shorter to match a "rule." It's not
important to tell you and me to think rather than following rules, but I'm
not sure that the Python community leaders really understand that, for the
vast majority of programmers, it _is_ important to tell them to think.

Every time you provide a rule, you need to remember that it's going to be
used for two things: guidance by those in the know, and as a way to stop
thinking by by the vast majority.

(And sometimes they don't even guide those who should be in the know.
`python -m this` is about language design? How do you get from "Simple is
better than complex," "There should be one-- and preferably only one
--obvious way to do it," and "Special cases aren't special enough to break
the rules," to, "We're not only going to have _two_ special-case iteration
constructs, but also refuse to implement the easy and ancient optimization
that would allow people to use the simpler and more general construct that
subsumes both of these"? All Guido had to do to avoid such a mess, back in
1990, was read and understand a fifteen-year-old paper.)

cjs
-- 
Curt J. Sampson      <cjs@example.com>      +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch