Re: [tlug] "Go Considered Harmful"

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

Curt J. Sampson writes:

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

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."  I don't think Gabriel misunderstood your point, he wanted to say
something different.

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

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

Sorry, I should have been more accurate.  It's about language design
for future versions of Python.  Some of it ("If the implementation is
hard to explain, it's a bad idea.  If the implementation is easy to
explain, it may be a good idea." for example) seems generally
applicable (to the extent it's applicable ;-), but a lot of it
("Although that way may not be obvious at first unless you're Dutch.")
is pretty idiomatic to Python.

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

Sez you.

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

 > (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."  That's his opinion,
that's all, but in Python it rules.  If you don't like it, use another
language or fork.  Guido doesn't care as long as you stay out of his
face with your complaints.

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

Even Guido hates it.  Always did, but the Lispwackos got to him. :-)

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

There's a big ambiguity in that statement.  Is the subject of
"abandon" "we" or "Guido"?  If "we", I'm with you.  If "Guido," can't
agree.  Not because he's right, but because diversity and
experimentation are good.

 > 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.  You have to mentor them:  

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

 > Every time you provide a rule,

Thing is, that the rules that the leaders provide are *for themselves*
and they emphasize this *frequently*.  PEP 7 and PEP 8 are style
guides for *C*Python and the standard library respectively; they don't
apply even to the interpreters developed by PyPy, IronPython, Cython,
and JPython, let alone to application programs.

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

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

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

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

 > 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.  He proposed it as a way to prove correctness in composed
programs.  I also worry about the plethora of boolean guards that you
could (in theory) end up with.  It would be easy to analyze with
modern symbolic algebra tools, but I'm not so sure about the ability
of programmers to convert their requirements to booleans, especially
under the nondeterminism in that formulation.  Lisp programs
regularly snafu cond forms, shell programs case statements, and
Python programs long elif sequences.