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? -- https://mail.python.org/mailman/listinfo/python-list
