When you press the "next-line" key, it's nice to know where you're going to end up. With a non-monospaced-font, you have to guess or count. With a monospaced font, it is visually obvious.
When I hit "Return", it duplicates the current line's leading whitespace on the next line. That will still work perfectly with a proportional font. When I hit "cursor-down", most text editors that allow proportional fonts know how to put the cursor where it visually belongs.
But that is exactly how my next-line key behaves, my cursor is always exactly where it should be. It's not like your tabs/spaces vary in width from line to line it is just that an uppercase W is wider than a lowercase i.
If you only want to move to the next line if you are at the beginning or the end of the line, I guess it works. For any other navigation, your cursor jumps to a random position. I just tried this, and for any line longer than about 3 characters, "next-line" becomes "random position on the next line". Not useful.
Other problems include lining up similar constructs:
my $foo = Foo->new(
bar => 'baz',
quux => 42,
);
With a non-monospaced font, there may not be an integer number of spaces that would allow you to align things.
Using a proportional font for programming seems like using a railgun to put a square peg through a round hole. Sure, you can do it, but why not just get a round peg?
Scintilla-based editors, GTKsourceview-based editors (I just tried with Scite and Gedit) and Emacs all correctly position the cursor when using the arrow keys and proportional fonts.
As for lining up similar constructs, I mostly code in Python, and the PEP 8 style guidelines explicitly forbid that.
I tried it in Emacs. Your definition of correct does not agree with mine.
If you draw a line parallel to the left-hand edge of your monitor down from the character that the cursor is currently over, it should touch the character that "next-line" will move to. That is not what happens when you use a proportional font in Emacs. (If you are on the 10th character of the line, you will move to the 10th character of the next line.)
What happens makes mathematical sense, but Emacs is a visual editor. Programmed text editing is nice, but sometimes you notice a visual property of the source code, and would like to exploit that instead of some lexical property. Visual editing lets you do this, but proportional fonts destroy this ability.
Anyway, sorry to hear about the Python style guidelines. If I did Python, I would ignore that one. (Haskell is whitespace-sensitive and allows you to align similar constructs. So this is just a Python thing.)
> I tried it in Emacs. Your definition of correct does not agree with mine.
Yes it does. In Emacs, with a proportional font, if I'm on the 10th character of a line and press "up", I do not necessarily move to the 10th character of the previous line. I move to the character visually above the current one.
Sorry it doesn't work for you - we must have differing Emacs setups. I'm using Emacs 23 in GUI mode.
Also, I'm a big fan of Haskell in general, but sometimes when I'm coding I think its whitespace is a bit too significant.
Well, part of it comes down to the fact that the text is read differently, depending on whether it's block letters or code. If you're writing prose, you process most text on a word-by-word basis, if not sentence-by-sentence. For instance, periods have very little spacing around them because there actually doesn't need to be that much more distance between letters at sentence boundaries—periods are not crucial characters, and thus do not have to be marked off from other letters. They are themselves boundary markers.
The situation is different with code. Every character that you type, unless it's within a comment, is very important. It's even quite possible that accidentally putting two spaces after a period might have some semantic effect, and it's certainly possible that having two periods instead of one will have some semantic effect. The programmer absolutely must be able to easily read code on a character-by-character basis, and thus he wants a typeface that treats each letter absolutely equally. It's only slightly distracting if your W is wider than your L, disrupting the natural grid of your text. But in a language where punctuation is just as important as the words themselves, you might just as well be troubled if your periods or commas have a tendency to disappear into the flow of letters.
Not to mention that there is nearly no block text font that has as much of an interest in differentiating I/l/1 and 0/O as programming/monospace fonts do.
Maybe for the same reasons you offered: readability and easy to look at.
Some modern monospaced fonts are rather nice to look at, Consolas for example, and the ability to distinguish between 0O1l easily is an advantage for some fonts without having weird letter spacings.
Don't get me wrong, I love Consolas, but having all of the letters be the same width doesn't make sometthing more readable. When was the last time you saw a book or newspaper in Courier New?
When I started my non-monospaced experiment 2 years ago, I, thought I might have trouble differentiating between 0O1Il, etc. but that has never been a problem in practice.
If you code in a style that uses data literals (lists/arrays and dictionaries/hash tables) to represent how an important part of the code is going to work -- e.g. a table that maps letters or keywords to argument lists used in some corresponding function -- then monospace fonts and block selection go well together. You can tweak one column at a time without upsetting the others if you set it up properly.
(Python's PEP8 is meant to take care of abuses, like lining up all the equal signs in a series of assignments or keyword arguments -- you wouldn't think of those as columns of data in a table, so there's no point in formatting the code that way.)
Also, monospace makes punctuation more prominent. Bjarne Stroustrup's C++ reference book uses a mixed font in its code examples, with monospace punctuation characters and proportional-font identifiers. It's weird but effective. I suppose if your code doesn't do exciting things with punctuation characters, and doesn't embed tables of data, then a proportional font would be just fine.
This bit of programmer dogma is totally unfounded. There is nothing more to it than tradition.