Guido sees the light: PEP 8 updated

[Rustom Mody]

On Monday, April 18, 2016 at 2:34:10 PM UTC+5:30, Gregory Ewing wrote:
> Rustom Mody wrote:
> > Come to think of it take an SQL DBMS browser.
> > Should we say: Horizontal scrolls are BAD; just reformat the table after reaching 80 columns?
> 
> I would say, yes, horizontal scrolling *is* bad in a table --
> probably even worse than it is for text or code.
> 
> The reason is that tables are usually laid out so that
> data items in a row are related to each other. You can't
> make sense of a piece of data in the table without seeing
> the other items in the same row. That's hard to do if
> you can't see the whole row at once.

"horizontal scrolling: BAD" + "Need to see whole row at once"
How to reconcile these two? (Think of a 50 column table/spreadsheet)
The only answer I know in DBMS lingo is "normalize" (refactor in programming
lingo)
which one way or other amounts to "Store some of those columns in your head"

Obviously I am not against normalization when it actually cleans up
I am against normalization just to reduce no of columns

> 
> > In fact much of the point of 
> > http://blog.languager.org/2012/10/layout-imperative-in-functional.html
> > is just this: that as code becomes more and more data-ish,
> > a more-lines-less-columns regime becomes correspondingly irksome.
> 
> I draw the opposite conclusion. The more your code is
> laid out like a table, the more important it is to be
> able to see the whole width of it at once.
> 
> Your Haskell lexer example looks all very nice in a
> good wide browser window. But reduce it so you can only
> see half of it at a time and then tell me how readable
> it is.

Horrible.
So what are we (if at all) disagreeing on?