Re: [tlug] "Go Considered Harmful"

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

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

I understand your point, but we'll have to agree to disgree on that.

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

It's not in that essay.  But surely it's been tried multiple times.

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

I don't understand your point.  As Steele says, "Our approach [to
tail-call elimination] results in all tail-recursive procedure calls
being compiled as iterative code, almost without even trying, for it
is more a matter of the code generation strategy than of a specific
attempt to remove recursions."  This is not like the PC-losering
problem which really is both hard and rare.  He's saying that anybody
who cares is likely to fall into better approaches of code generation,
but the professors were too busy trying to create the perfect syntax
and the bureaucrats were too busy satisfying DOD-STD-2167 and
DOD-STD-2168, and the programmers just wanted to leave at 5pm, so you
ended up with monstrous prologues and epilogues to every procedure
call because nobody cared.  Apparently even the MIT people were mostly
just being pedantically correct without considering efficiency (except
Maclisp at that time, and later of course Scheme made TCO a hard
requirement for implementations).

 > >  > 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 an Easter egg.  That's why they put it there.  They weren't
planning to submit to POPL, and still aren't AFAIK.

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

Look, I understand you want to burn down the world and build anew,
youngster.  But that's not necessarily the best approach.

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

Nah, he picked up comprehensions because they're compact and
expressive and "look like" set-builder notation.  'map' was made a
builtin, but the combinators that don't reduce to a first-order
function in Python have been banned from the stdlib because very few
Python programmers have a clue of how to use them (and they may have
been actually broken in earlier versions).  Even the functools module
has very little, basically just a partial partial.

 > Yeah, again, "This very specific narrow rule must be applied everywhere
 > even though there are clear cases where it makes code less readable." 

Excuse me?  You consider

    a = 1; if True: print(a)

"readable", and more so than

    a = 1
    if True:
        print(a)

??  You're getting old and cranky if you're going to espouse that.

 > 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

Which is another non-goal of Python.  Certainly you can create DSLs,
but they will have Python syntax, and the specialized semantics can
easily be looked up by typing "help(NAME)" (assuming the author of the
DSL writes documentation).

I think the example you want here is not Lisp, though, but rather
Ruby.  Lisp forces you to write DSLs that look like Lisp.  (OK, you
can do anything with a reader macro, but that's cheating.)  Even DO
looks like Lisp.  Ruby is much more flexible, so you can write DSLs
the look like nothing in this world.  This is considered a
disadvantage by many....

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

Sure, I understand that.  It's annoying to write

    def _(x): return x.attribute_i_want_to_sort_on
    some_list.sort(key=_)

instead of

    some_list.sort(key=lambda x: x.attribute_i_want_to_sort_on)

But I've found that I used to write a lot more lambdas in Emacs, until
I discovered labels (and macrolet).  Now I frequently just use labels
in early drafts of a function even if I have only one use of one
lambda.  At least if I know I'm going to be kaizenning the thing
later.  And I'm writing more lambdas in Python now that we have both a
ternary operator and an assignment expression.

The fact that your mileage varies proves nothing.  The question is how
many of Python's users are like you, and how many like me.

 > >  > 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 gather you strenuously object to calling haiku and sonnets "art"?

And putting the word "trump" into a civil discussion with honest
American folk ... you wanna go to jail for inciting?

 > Right. But when they go and provide lists of rules they are giving
 > my managers the tools to make my life unhappy.

If your manager chooses to use the Zen to make your life unhappy, I
think you'd be happier unemployed.  And as Lazarus Long would
undoubtedly say, "but even better to work for a different manager, and
usually easier."

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

Strawman.  You know that's not what I'm arguing.

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

Hah!  You fooled me.  I thought TCO was a lot older than that, and
Steele hadn't been mentioned recently.  In any case, you can do
iteration in Python by tail calls (though not at scale, since you'll
blow the stack without TCO).  Nobody (not even the people who know
what foldr is) wants to.  TCO comes up occasionally as a theoretical
construct, but gets shot down because nobody wants to do the work of
making iteration implemented by tail recursion debuggable.

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

The only thing Python suffers from is Unicode (more precisely, making
str an abstract text type in Python 3).  For the stuff you care about,
"I fart in your general direction."  That's not really a criticism of
you, but I don't accept your criticisms of Python as valid.  Lisp and
Haskell both exist -- Python doesn't need to be either, nor some sort
of bastard offstring of such illustrious parents.

Guido, and Pythonistas generally, don't pretend that Python is the
greatest language ever invented.  It's only a very good language for
for a *very* large number of people who want to think about the
problems they're trying to solve without thinking about the language.

As drunk Manny says in The Moon is a Harsh Mistress, "Hear, hear!
I've aimed at 'less than perfect' all my life."  I will allow you to
finish the thread with Prof. Bernardo de la Paz's retort.