5 ms·

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, propo

by andjd 5y ago

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-based supports proportional width fonts beautifully. It's also incredibly rare to see modern style guides that depend on having consistent column widths. In 2022, there's no technical reason to code using monospaced fonts. And there are a ton of beautiful and readable fonts out there -- There are probably a dozen pre-installed on your system that are more beautiful and readable than this font. You see this tag line time-and-time again. "A font designed by and for software developers." But font design is and art and a discipline. Doing it well is very hard.

moonchrome 5y ago
Proportional fonts break code navigation, moving vertically is much more important in code than normal text. Also it's harder to line things up, and alignment is a good cue when scanning code.
- taeric 5y ago
  Is it, though? Important, that is. Can be convenient. But so is ace jump. And the latter still works.
- Stratoscope 5y ago
  I would argue that most use of column alignment in source code hampers readability and maintainability. There are some exceptions, of course. If you are writing out hard coded matrices, you may want to line up the numbers. But how many of us really do that day to day? Many modern formatters such as Black for Python and rustfmt for Rust avoid column alignment and prefer indentation instead. Then the code is equally easy to read and navigate in any font of choice, proportional or monospaced.
chipotle_coyote 5y ago
> 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/ https://input.djr.com/info/ ...except that just about every time I've tried this, I've quickly run into places where trying to use a proportional font creates visual fails. Here's a simple one: /** * Render a given template * * @param string $_template * @param array $_args * @return string */ Put that in a non-proportional font, and the asterisks on the first line probably won't line up with the rest. Now think of someone doing visual alignment of assignment operators in a block of code like you often see in Ruby, 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. Speaking of parentheses, can you imagine what will happen with proportional fonts and Lisp indentation? It'd drive the hardiest Emacs user to drink in short order. Proportional fonts in editors are a good idea whose time probably just hasn't yet come. We'd need (a) to have editors that support "elastic" or variable tabs to keep things aligned in a truly sane fashion, (b) to re-teach a generation or two of programmers that indenting with the tab character is good, actually, and (c) to develop a few new conventions for what makes code look neat and pretty.
- memco 5y ago
  Textmate 2 had some support for proportional width and different heights and styles in its early days. Don’t know how it panned out since I’ve since stopped using it.
- taeric 5y ago
  I do find it hilarious that using tabs with non static tab stops basically solved this problem. Anyone that ever typed, on a typewriter, almost certainly used controlled tabs to line up data. I recall tables were easily done by just seeing the tabs correctly then proceeding in standard way. That said, I don't see my lisp coffee caring that much. Let expressions benefit from lining up. Most other code, though? Not sure it matters that much.
thiht 5y ago
> why code using a monospace font? Because unlike prose, we don’t reason about code in terms of words, sentences or paragraphs but rather in terms of statements, lines and blocks. Navigating between visual lines vertically makes sense when navigating in code. And to optimize this kind of navigation, monospace fonts are the best choice because where your cursor lands is predictible. It also brings cool features such as block selection which you can’t implement properly with proportional fonts.
- Stratoscope 5y ago
  I don't quite understand this. I've used proportional fonts in PyCharm and other editors for many years, and vertical navigation and block selection work fine.
- GoblinSlayer 5y ago
  For me legibility is more important: unlike prose, for code it's much more important, what's written in those lines, and monospace fonts sacrifice legibility for columns. And no, monospace fonts can't make cursor land where it needs to, because the destination can be anywhere on the line.
toomanydoubts 5y ago
I had never considered using variable width fonts for programming. I can see some minor issues, like vim users(on an environment that support variable-width fonts) now have no consistency on where their cursor will land when using j/k to move up and down lines, but I think I will still try it out.

by andjd 5y ago

moonchrome 5y ago

Proportional fonts break code navigation, moving vertically is much more important in code than normal text. Also it's harder to line things up, and alignment is a good cue when scanning code.

taeric 5y ago
Is it, though? Important, that is. Can be convenient. But so is ace jump. And the latter still works.
Stratoscope 5y ago
I would argue that most use of column alignment in source code hampers readability and maintainability. There are some exceptions, of course. If you are writing out hard coded matrices, you may want to line up the numbers. But how many of us really do that day to day? Many modern formatters such as Black for Python and rustfmt for Rust avoid column alignment and prefer indentation instead. Then the code is equally easy to read and navigate in any font of choice, proportional or monospaced.

chipotle_coyote 5y ago

> 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/ https://input.djr.com/info/ ...except that just about every time I've tried this, I've quickly run into places where trying to use a proportional font creates visual fails. Here's a simple one: /** * Render a given template * * @param string $_template * @param array $_args * @return string */ Put that in a non-proportional font, and the asterisks on the first line probably won't line up with the rest. Now think of someone doing visual alignment of assignment operators in a block of code like you often see in Ruby, 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. Speaking of parentheses, can you imagine what will happen with proportional fonts and Lisp indentation? It'd drive the hardiest Emacs user to drink in short order. Proportional fonts in editors are a good idea whose time probably just hasn't yet come. We'd need (a) to have editors that support "elastic" or variable tabs to keep things aligned in a truly sane fashion, (b) to re-teach a generation or two of programmers that indenting with the tab character is good, actually, and (c) to develop a few new conventions for what makes code look neat and pretty.

memco 5y ago
Textmate 2 had some support for proportional width and different heights and styles in its early days. Don’t know how it panned out since I’ve since stopped using it.
taeric 5y ago
I do find it hilarious that using tabs with non static tab stops basically solved this problem. Anyone that ever typed, on a typewriter, almost certainly used controlled tabs to line up data. I recall tables were easily done by just seeing the tabs correctly then proceeding in standard way. That said, I don't see my lisp coffee caring that much. Let expressions benefit from lining up. Most other code, though? Not sure it matters that much.

thiht 5y ago

> why code using a monospace font? Because unlike prose, we don’t reason about code in terms of words, sentences or paragraphs but rather in terms of statements, lines and blocks. Navigating between visual lines vertically makes sense when navigating in code. And to optimize this kind of navigation, monospace fonts are the best choice because where your cursor lands is predictible. It also brings cool features such as block selection which you can’t implement properly with proportional fonts.

Stratoscope 5y ago
I don't quite understand this. I've used proportional fonts in PyCharm and other editors for many years, and vertical navigation and block selection work fine.
GoblinSlayer 5y ago
For me legibility is more important: unlike prose, for code it's much more important, what's written in those lines, and monospace fonts sacrifice legibility for columns. And no, monospace fonts can't make cursor land where it needs to, because the destination can be anywhere on the line.

toomanydoubts 5y ago

I had never considered using variable width fonts for programming. I can see some minor issues, like vim users(on an environment that support variable-width fonts) now have no consistency on where their cursor will land when using j/k to move up and down lines, but I think I will still try it out.