I'm James Hague, a recovering programmer who has been designing video games since the 1980s. This is Why You Spent All that Time Learning to Program and The Pure Tech Side is the Dark Side are good places to start.
Where are the comments?
Extreme FormattingNot long after I wrote Solving the Wrong Problem, it occurred to me that this site is small because of what I decided to leave out, and that I never tried to optimize what remained. To that end I used a PNG reducer on the two images (one accompanies Accidental Innovation, the other is in The End is Near for Vertical Tab). And I ran the CSS through a web-based minifier.
A Cascading Style Sheet written in the common way looks like this:
And I found that I preferred working with the crunched-down CSS.
Unless you're reading the newsfeed, the CSS file is already on your computer or phone, so take a moment to look at it. If you're sighing and shaking your head at this point, you could put each selector on a line by itself, but that adds another 23 lines. 23 more if each closing brace gets its own line. And another 40 or so to make sure there's a newline after each property. Somehow the raw 23-line version puts the overall simplicity of the stylesheet into clear perspective. Free of superficial structure, it takes less than half of a vertical window in my text editor. Is inflating that to over 100 lines--enough that I need to scroll to see them all--buying anything concrete, or is it that verticality is such an ingrained formatting convention?
Okay, right, there's also readability. Surely those run together properties are harder to scan visually? Syntax highlighting makes a big difference, and any editor with a "highlight all occurrences of a string" feature makes this layout amazing. I can see everywhere the
border-styleproperty is used all at once. No jumping to different parts of the document.
Here's a good question: Does this apply to real code and not just HTML stylesheets?
There's an infamous, single printed page of C code, written by Arthur Whitney one afternoon in 1989, which became the inspiration for the J language interpreter. It occasionally gets rediscovered and held up as an example of what would happen if a programmer went rogue and disregarded all rules and aesthetics of code formatting, and most who see it are horrified. All those macros? Short identifiers? Many statements on the same line? Entire functions on a single line, including those triggers of international debate, the curly braces?
Despite being misaligned with popular layout standards, is it really such a mess? It's small, so you can study the whole thing at once without scrolling. The heavy use of macros prevents noisy repetition and allows thinking in terms of higher-level chunks. That level of density makes the horizontal layout easier to follow than it would be with preprocessor-free C. (To be fair, the big downside is that this is not the kind of code debuggers work well with.)
"How hard do you think that is?"
"Maybe a dozen lines or so."