I'm not against it in principal, but leaving alignment to the editor sounds like the kind of thing that could be coding standard unfriendly (unless it were done quite well, or was solely visual).
That's just a matter of coding style. It's very easy to write code that reads equally well in a proportional or monospaced font. All you have to do is give up column alignment.
I haven't used column alignment in my code in over ten years, and it's been a real blessing. Column alignment leads to some absurd practices, like the examples below from this Servo source file:
You may need to scroll horizontally to read these long lines:
let construction_item = ConstructionItem::TableColumnFragment(Fragment::new(node,
specific));
self.set_flow_construction_result(&kid,
ConstructionResult::Flow(kid_flow,
Descendants::new()))
Those statements would be more readable and much more maintainable with a simple change: Stop making a distinction between parentheses and curly braces. Instead of lining up columns where parens are used, indent expressions the same way we typically indent statements:
let construction_item = ConstructionItem::TableColumnFragment(
Fragment::new( node, specific )
);
self.set_flow_construction_result(
&kid,
ConstructionResult::Flow( kid_flow, Descendants::new() )
)
Here's some of the trouble column alignment gets you into, again from the same source file:
It's easy to guess what may have happened here: at one time the code was aligned perfectly, but then four characters were added somewhere in one of those names, pushing whitespace_node farther to the right so it no longer aligned with the code below it.
With a non-column-aligned style, this would never happen:
Now you can change any of those names and it won't affect the code formatting one bit. And look how much shorter your lines are when you use indentation instead of alignment!
Another benefit of giving up column alignment is that it eliminates any need for arguing about "tabs for indentation, spaces for alignment" and all that. And with no alignment, your code becomes resilient to re-indentation. Company founders get older and find it's become harder to read two-space-aligned code? You can re-indent the source mechanically to four spaces, or tabs, or whatever you like, and it won't break the formatting at all.
Of course if you have to work with column-aligned code like the Servo source, you'll probably need to use a monospaced font. But if you have any influence over the formatting of the code you work, try giving up column alignment. Even if you don't find it makes any difference in readability, the people who have to maintain your code later will appreciate not having to fiddle with the alignment any more.
It is just far easier to use a monospaced font than to implement a whole tabbing system in every editor you'd want to use. And the alignment needs can vary by language and application.
That's why it is so nice to work in a grid: you can align things however you like for any purpose. You don't have to rewrite someone else's parser or build a plugin to properly format an ad-hoc table in a comment.
"If source code editors can highlight syntax, they could also interpret tabs and syntax to create true, adjustable columns of text."
Oh but they could. Are programmers condemned to an eternity monospace typewriter hell because we are too lazy to build better editors? Will we be able to upgrade to proportional fonts before the singularity occurs and programming becomes obsolete anyways?
I've been proportional for about 3 years now; once you go with better typography you can't really go back.
Yes, we probably are condemned. For the same reason that mathematicians are condemned to know how to add and subtract, even though one could achieve the same results using a more general method.
Monospace is just simpler. We use it in consoles, and they aren't going away or being revolutionized. And if you want to write a new text editor, you will probably end up supporting monospace behavior before proportional simply because it is such a simple and flexible algorithm.
And in the end, the only reason to use proportional font is for style and a marginal increase in readability.
So it's not a matter of laziness, but of efficiency and design fundamentals.
> And in the end, the only reason to use proportional font is for style and a marginal increase in readability.
Everyone always claims that "we read code" more than "we write code", yet we still optimize for writing rather than reading. Reading code that has been typeset well is a joy and much improved experience vs. reading code that has not.
I ended up buying the Butterick fonts a while back for a personal project, now I use Triplicate for basically all my coding/terminal needs. I like because it has good readability on both low res and high res screens.
I've been using input in terminal/vim for a couple months and quite like it. Not sure if it's the end-all be-all font but it's pretty easy on the eyes, and very tweakable.
One of its best feature is that after you select your preferences for style, width, weight, and alternates, you can bookmark the URL for later reference or sharing.
Just tried it. It is nice, but I think that I've been spoiled by Menlo, which I am now going back to. Not a very high DPI screen but around 14pt Menlo just seems easier on the eyes.
http://research.microsoft.com/en-us/projects/liveprogramming...
That was about a year ago, what I have now is a bit more tame.