I'm going to hop on my hobby horse again for a second: One of their first points is this: >Designing a monospace font is much harder than a traditional, proportional one: being constrained by the same width of all glyphs can result in a boring or unreadable font. And they're absolutely right. But it begs the first-principals question-- why code using a monospace font? Today, every major editor that isn't terminal-bas…
> And they're absolutely right. But it begs the first-principals question-- why code using a monospace font? Today, every major editor that isn't terminal-based supports proportional width fonts beautifully. There was a whole "coding font" family designed around the idea that we should be using proportional fonts for this, and it makes a great case... https://input.djr.com/info/ ...except that just about every time I…
You quickly learn not to care about that. So what if the asterisks in the first boilerplate line don't line up with the ones below? And which of those two asterisks should have lined up with the others?
It just doesn't matter. Everything in the meat of the comment still lines up just fine in a proportional font, just as it does in monospace.
> Now think of someone doing visual alignment of assignment operators in a block of code like you often see in Ruby
I gave up that coding style many years ago, even before I switched to proportional fonts. You end up doing stuff like this (making up a contrived example, and not in any particular programming language here):
name = user.name
age = user.age
driver_license_number = dl_database(user).dl_number
Maybe it is because I am getting older and all that sideways visual scanning is not as pleasant as it used to be. Maybe it is because of the unnecessary commit diffs that this style produces.
Once I stopped doing this, I realized that the code would look fine in any font, mono or proportional.
> or any code following the indentation standard where you line up parameters in a multi-line function header with the character after the open parenthesis like you often see in Python.
It's worth noting that Black, by far the most popular Python formatter, eschews column alignment in favor of a purely indentation-based format. Python code formatted with Black is just as readable in a proportional font as in monospaced.
Here is a more extreme example from Rust, whose rustfmt tool used to rely heavily on the kind of column alignment you're talking about:
let mut rewrites = try_opt!(subexpr_list.iter()
.rev()
.map(|e| {
rewrite_chain_expr(e,
total_span,
context,
max_width,
indent)
})
.collect::>>());
let mut rewrites = try_opt!(
subexpr_list
.iter()
.rev()
.map( |e| {
rewrite_chain_expr( e, total_span, context, max_width, indent )
})
.collect::>>()
);
> re-teach a generation or two of programmers that indenting with the tab character is good, actually
Bless you for that! This is another advantage of indentation-only formatting. It stops mattering whether you use tabs or spaces! The code will be just as readable in any font, monospaced or proportional, and it won't matter at all if one dev prefers to render tabs as two spaces and another likes four.
The key to all of this is to abandon the kind of column alignment that monospaced fonts make so tempting.
I do agree with your point about Lisp. Monospaced fonts are so heavily ingrained in that culture that I couldn't begin to imagine how to change it.