Re: [tlug] "Go Considered Harmful"

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

On 2020-09-02 02:40 +0900 (Wed), Stephen J. Turnbull wrote:

> I see your point.  But in the end, you can write a 1000-page
> benefit-cost analysis with twenty seven eight-by-ten colour glossy
> pictures with circles and arrows and a paragraph on the back of each
> one, and what it means is "yeah, that's hard, so we just bailed on
> it."

No, it does not mean, "that's hard, so we just bailed on it." When a
cost-benefit analysis is done, the thing in question wasn't bailed on
because it was hard, it was bailed on because _not doing it produced a
better product in some way_.


>  > Essentially, all the MIT guys need to do to win this battle is add "cheap
>  > is good" to their list of characteristics,
> 
> Sure, but that has been true since 1957, and Unix won anyway.  Maybe
> it's not that easy.

Well, it doesn't really sound from Gabriel's essay as if  "cheap is good"
is part of the MIT list. And it seems to me that where they did take that
to heart, they did win. (See, "Debunking the Myth of Expensive Procedure
Calls etc. etc.")

>  > Well, the first question of course would be, "why the heck are they
>  > putting that _there_, then?"
> 
> Sorry, I should have been more accurate.  It's about language design
> for future versions of Python.

Yeah; that still makes me raise the question. It's a lovely place if you
want to quickly bring it up to anybody with a Python interpreter nearby,
but not really where one goes to discuss language design. And they could
make the whole thing more clear, both in location, purpose and content
itself, with a PEP. At this point, I suspect there are a lot of folks out
there (including me) who, due to the nature of how and where they said
this, don't even know it's about language design and not Python code.

>  > 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.
> 
> I have never seen Guido mention Haskell in this connection.  And
> that's important: Python was designed by one genius who didn't have a
> lot of knowledge about making languages when he started, but did have
> very good taste.

Well, good taste assuming you consider ALGOLish language features to be
invariably more "tasteful" than non-ALGOLish language features.

And regardless of where he started with Python, he knew about Haskell well
before Python 3, and was taking ideas from it. (Though perhaps not well.
List comprehensions in Haskell have always been convenient syntatic sugar
for specific cases; in the general case construction via functions such as
fold, map, etc. is used far more often.[1] I suspect Guido chose list
comprehensions over functions because list comprehensions use those nice
comforting `for` keywords.)

[1]: https://www.reddit.com/r/haskell/comments/2k50tx/are_list_comprehensions_idiomatic_in_modern/

>  > (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,"
> 
> No, it's deliberate, at least ex post.  I have heard Guido say, "It's
> important to readability that you can scan down the left margin and
> see all the keywords that introduce a statement."

Yeah, again, "This very specific narrow rule must be applied everywhere
even though there are clear cases where it makes code less readable." The
hobgoblin strikes again, but this time in a way where there's no arguing
with it.

This is probably one of the greatest strengths of Lisp: it enables to at
least some degree creating a language to express the problem at hand (and
the community does not discourage this), rather than forcing on you a
different language designed for expressing some other, unrelated problem.

(BTW, though I keep bringing up Lisp, I do not think is the Best Language
Ever or anything like that. It just happens to be a good source of early
examples of Good Ideas.)

>  > And don't even get me started on Python' "lambda."
> 
> Even Guido hates it.  Always did, but the Lispwackos got to him. :-)

Well, you may be being facitious here, but I suspect it may not come across
that way clearly. So:

Yes it's clear that Guido hates the idea of lambda: not only did he
deliberately make it awkward and inconsistent, but he's explicitly said he
hates it on several occasions, and has tried to have it removed from the
language.

But I _love_ the idea of lambda, as do many programmers in languages that
originate and mostly live outside the functional programming community. My
complaint about it is not that lambda is bad, but that _his_ lambda is bad,
and unnecessarily so.

>  > 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.
>
> Well du-uh.  Programming is not a science, it's an art.  You can't
> "tell" people how to do art right.

Except, of course, for things like "lambdas must not contain assignments"
and "you can't have an `if` on a line after other code," where programming
is not an art and doing things that specific way trumps all else.

>  > 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.
> 
> I don't think that the Python community leaders think it is their
> place to tell people who aren't on their team to think.  I see them
> *showing* others *how* to think on the Python dev lists every day,
> though, and it's even occasionally observed that a new member shows
> signs of actually learning something.

Right. But when they go and provide lists of rules they are giving my
managers the tools to make my life unhappy. Dynamite is an incredibly
useful tool without which civilisation would be worse off, but that doesn't
mean that when you make it and hand it out to people you have no moral
responsibility for how it's then used.

> How do you propose preventing the latter? ;-)  YOLO, man! it's not
> worth the effort. :-(

I don't propose _preventing_ it; I don't think that's possible. But it's
certainly possible to encourage people to think, rather than just
abandoning them (and any unwilling people they happen to have power over)
to not-thinking.

>  > (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,
> 
> It turns out that's the way a lot of people think about these things.
> Pascal had what, four iteration concepts?

Indeed! But "they've done it that way in the past" does not mean "that's a
good way to do it."

> > 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"?
>
> By that you mean call-with-current-continuation, right?
> -- S. J. Trollbull.

Nice troll, though I don't know if it really counts as a troll if I find
the comment both informative and amusing. :-)

(To help avoid confusion for others out there, the "simpler and more
general construct" is recursion, and the "easy and ancient optimization" is
tail call optimization. As an inteteresting side point about the latter, it
seems that TCO comes naturally to programmers; it turns out to have been
broadly used in mid-to-late 1970s and early 1980s 8-bit assembly language
programming, and I'm pretty sure that many of the people using it had no
thought of "computing science" or "functional programming" or anything like
that on their minds.)

>  > All Guido had to do to avoid such a mess, back in 1990, was read
>  > and understand a fifteen-year-old paper.)
> 
> Sure, but Dijkstra didn't actually propose that as the way to do
> programming.

The paper wasn't by Dijkstra, the paper was by Steele ("etc. etc. Lambda
the ultimate GOTO.")

> I also worry about the plethora of boolean guards that you
> could (in theory) end up with.

That's a fair point. But Dijkstra went far beyond what you say here and
agreed with Knuth that a plethora of boolean guards was a Bad Thing,
as I pointed out in a previous post.[2]

[2]: https://lists.tlug.jp/ML/2008/msg00080.html

In the end, Guido's great failure is that he seems always to have held (and
still hold) as a core belief, "the ALGOL way of thinking about the world is
always better," something that not even the designers of ALGOL believed.
(And had extensively written about before reaching even the half-way point
between the introduction of Algol and the start of Python.) Python has not
suffered from this as much as it might have due to Guido getting beaten
down by others with more knowledge than him, but it still has suferred from
it extensively.

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

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