On Nov 4, 2006, at 9:13 PM, Dave Smith wrote:
I thought it looked better aesthetically, and I learned how to use
my editor more effectively (vim). I used to keep as much code on a
screen as possible, so I could refer back without scrolling (I'll
call it "optimized for vertical compression"). Then I learned how
to use vim. Between vim's m, ctrl+p, %, *, #, n, and N, I can move
around in code without regard to white space or vertical
compression. Also, I've fond ctags and cscope useful when working
with others' code, but I rarely use them on my own. That's been my
experience. I let the editor do the grunt work, and I lay out the
code however I think it looks best, even if that means sacrificing
a few rows of terminal space.
My vim-fu has become weak since I started programming in Lisp with
emacs, so I only recall what % does off the top of my head. There's
that memory thing again.
Even with fancy editor navigation, you simply get more context when
things are reasonably compact. Jumping around in the code via editor
magic is just as distracting as scrolling is. It's like a context
switch for the visual cortex. The more clear meaning that can fit
within visual range on a screen, the more meaning can be absorbed in
context before movement must take place.
Braces mean nothing to C and nothing to humans by themselves; they
are simply punctuation. We don't give English punctuation its own
lines; we don't even give our most frequently used punctuation marks
a full letter's width of space. That's because they're a secondary
informational cue and not meant to be consciously noticed. We convey
meaning to other humans in our words in English, and with keywords,
functions, and operators in C. By concentrating on how those
semantic elements fit in relation to one another on a screen instead
of the semantically void punctuation, we can get a lot more meaning
from a given visual space.
This is one thing that became very clear to me as I learned Lisp.
It's a very punctuation-heavy language, yet the punctuation is almost
never considered by the humans who read the code. Meaning is
conveyed to humans through indentation and positioning of semantic
elements, and the punctuation is fit in secondarily to that in as
compact a form as possible, so it can be ignored.
For example:
(defun foo (a b)
(let ((c 3)
(d 4))
(if (a > b)
(+ a c d)
(+ b c d))))
This is roughly equivalent to:
int foo(int a, int b) {
int c = 3;
int d = 4;
if (a > b)
return a + c + d;
else
return b + c + d;
}
You can see how the close-parentheses just build up on the end of the
last line of Lisp. You may think this is ugly at first, but it is
done because the parentheses are just punctuation, and Lispers just
don't look at them. Giving them each their own line would be
ridiculous, since the function would take a huge amount of space to
say exactly the same thing, and would be less clear to boot since the
information would be spread further from the center of the visual space.
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
