Forgot your password?
typodupeerror
GUI Programming

Programming With Proportional Fonts? 394

Posted by timothy
from the now-that's-wild-and-crazy dept.
theodp writes "Betty or Veronica? Mary Ann or Ginger? Proportional or Monospaced? There's renewed interest in an old blog post by Maas-Maarten Zeeman, in which M-MZ made the case for programming with proportional fonts, citing studies that show proportional fonts can be read 14% faster than fixed-width fonts. Try it for a couple of weeks, he suggests, and you might like it too. Nowadays, Lucida Grande is M-MZ's font of choice on OS X, and he uses Lucida Sans on Windows. Helvetica, anyone?"
This discussion has been archived. No new comments can be posted.

Programming With Proportional Fonts?

Comments Filter:
  • Overrated (Score:4, Insightful)

    by tjstork (137384) <todd@bandrowsky.gmail@com> on Sunday January 17, 2010 @08:49AM (#30797572) Homepage Journal

    I've programmed in proportional fonts. It's ok, but I prefer fixed width for alignment.

  • Re:Monaco (Score:5, Insightful)

    by psergiu (67614) on Sunday January 17, 2010 @08:52AM (#30797582)

    background: black
    foreground: X11:peachpuff or #99CF96
    font: X11:10x20 or Monaco 12pt

    That's way faster to read than anything on a bleed-your-yeys white background.

    TFA is comparing 10pt Monaco with a 12pt font. Put them both at 12pt and Monaco - which is monospaced - the way God intended computer displays to be - wins.

  • Consolas (Score:5, Insightful)

    by Mangala (604031) on Sunday January 17, 2010 @08:52AM (#30797584)
    Microsoft's Consolas with properly tweaked ClearType has been my personal favorite since its release. Another huge improvement to my code screen is changing the background color to a light grey - still not a dark color scheme, but much less glaring than pure white.
  • Re:Monaco (Score:4, Insightful)

    by Jurily (900488) <jurily@NETBSDgmail.com minus bsd> on Sunday January 17, 2010 @08:55AM (#30797608)

    There are a lot of fixed width fonts specifically designed so each character is unique in appearance. That is not negotiable when programming.

    oO0 il1 lilli

  • Pencil and Paper (Score:5, Insightful)

    by turgid (580780) on Sunday January 17, 2010 @08:56AM (#30797616) Journal

    It's the only way to write real code.

  • by mattdm (1931) on Sunday January 17, 2010 @08:59AM (#30797630) Homepage

    Reading prose is different from reading code. I'd think that whatever you gain wouldn't be enough to make up for the loss from lack of vertical alignment.

    Additionally, which monospaced font you use matters. You need one that's designed to be readable and to make clear distinctions between 0 and O, l and 1, and so on. I use Raph Levien's Inconsolata [levien.com] for coding, and it's excellent (and available under the Open Font License).

    On Fedora, yum install levien-inconsolata-fonts.

  • Not the bottleneck (Score:5, Insightful)

    by bcmm (768152) on Sunday January 17, 2010 @09:07AM (#30797664)
    Speed of reading is not a bottleneck in understanding code anyway, since I am sure it is pretty uncommon to be able to understand code while reading it as fast as you would read a novel.

    And there are numerous disadvantages: lack of alignment, smaller punctuation making syntax errors less visible (" '" vs "' " for example), etc., etc.
  • I wonder .. (Score:2, Insightful)

    by Anonymous Coward on Sunday January 17, 2010 @09:10AM (#30797680)

    How do you align comments, etc.? How do you do visual block selection? What if you want to add a small ASCII drawing to a comment?

    The disatvantages seem overwhelming to me, and I find good monospace fonts (Deja Vu Sans Mono, Inconsolata, ...) easy enough to read. Also, some editors (e.g. gvim) will scale proportional fonts to make them look monospaced (and really ugly).

  • by Krioni (180167) on Sunday January 17, 2010 @09:15AM (#30797698) Homepage
    What I wonder about is whether the ease of reading attributed (correctly, I assume) to proportional fonts apply to prose, but not necessarily to the kinds of reading needed in programming. When I read code, I'm sometimes looking for single-character mistakes. In a case like that, a proportional font that helps form "word-pictures" might mask an error. In other words, the speed attributed to proportional fonts is for reading comprehension — translating text into thought — but might actually detract from the speed and accuracy of reading for the purpose of editing/finding mistakes.
  • Vertical alignment (Score:3, Insightful)

    by Skapare (16644) on Sunday January 17, 2010 @09:29AM (#30797744) Homepage

    I'm not willing to give up on vertical alignment. And lots of code sections I've written, in addition to ascii-art comments to explain lots of code, really needs that vertical alignment. And that's not just leading alignment, it is internal alignment.

    This won't break Python's indentation based syntax because one should be using consistent indentation. But many displays of proportional fonts will collapse multiple spaces into the space of one, and even Python becomes hard to read.

    The solution is to have a proper display system that can do both proportional fonts AND controlled alignment at the same time, without mangling the code files themselves, for all active programming languages (and that's a LOT of them). Inserting invisible alignment into the code is not an option unless we can teach every language parse to remove such alignment elements before parsing the code for what it is coded for. Someone could do this with a new language I don't doubt. But it remains to be seen if anyone can do it in general for all existing active languages.

    Oh, and if you do come up with a solution and it just can't manage to achieve it with COBOL, I won't cry. But it better work with assembly and microcode syntax.

  • Re:Consolas (Score:4, Insightful)

    by Anonymous Coward on Sunday January 17, 2010 @09:32AM (#30797754)

    Second the Consolas recommendation. One reason why I prefer fixed-width fonts is that proportional fonts reserve too little room for dots, commas, semicolons and other "narrow" characters, which happen to be of great importance in programming. Proportional fonts focus on text, while programming languages focus on structure.

  • Re:I wonder .. (Score:2, Insightful)

    by d3matt (864260) on Sunday January 17, 2010 @09:35AM (#30797780) Homepage
    Let's not forgot standardized coding styles. I have a hard enough time with developers who use the wrong spacing for tabs in their editor window!
  • visual cues (Score:5, Insightful)

    by pz (113803) on Sunday January 17, 2010 @09:41AM (#30797816) Journal

    Human languages have lots and lots of redundancy, such that you can often either screw up letter order, word order, or even drop entire words, and often the full meaning is clear. Visual cues in the form of paragraphs and chapters are added to help guide the reader, but removing them would not render the text entirely incomprehensible.

    Computer languages are not as forgiving, and, also, lacking redundancy, far denser. Reading speed is irrelevant because of the bottleneck formed by reading comprehension. Code is rarely read in novel-like linear fashion, but, much more often, flitting from one part of the text to another, navigating through visual cues. Visual cues in the form of often richly structured layout that includes idioms not required by syntax make navigating and comprehending code possible, and removing them although would, in most languages, not change the meaning of the code, would erect a formidable barrier to comprehension. Not using these cues to the fullest to help write clear, expressive and maintainable code is being self-indulgent and shortsighted. Requiring that a particular, and perhaps unspecified font be used for best display, rather than the ubiquitous assumption of monospaced font, is mere vanity.

    Remember, when code is written, it is meant not only to be converted into executable machine language, but also to be comprehensible and comprehended by other programmers, or future selves. Clarity of expression is vital.

  • by tagattack (412693) on Sunday January 17, 2010 @10:00AM (#30797946) Homepage

    VIM renders text-area as a grid. This is compatible with column-area selection, and other features it supports which frankly I use nearly daily. While I've honestly considered using proportional fonts — I've tried living without VIM, switching to Eclipse or IDEA for several months at a time to give the IDE experience a full opportunity. Doesn't work for me, so neither will proportional fonts.

    Besides there seem to be more reasons not to use proportional fonts than to use them:

    • Lot's of people align assignments, this will look terrible.
    • Several formatting techniques (newline before curly bracket) depend on the width of whitespace.
    • Occasionally code contains tabular data which is easily formatted for digestibility using fixed-width fonts.
    • Occasionally, although rarely, comments may contain diagrams or ascii-art figures which would be rendered useless with proportional font.

    Reasons to use them:

    • You might be able to read the contents of your code up to 14% faster, if you don't run into the issues above...
  • Odd. My impression after reading his book was that Stroustrup deeply misunderstood the importance of coding style. And not merely because "C++" and "style" should only be combined for humorous effect: the way "&" behaves in declarations is bizarre, and his explanation read like a rationalization for a bad decision.

  • by maxwell demon (590494) on Sunday January 17, 2010 @10:23AM (#30798096) Journal

    But compiling code written that way is awkward.

  • by TheRaven64 (641858) on Sunday January 17, 2010 @10:30AM (#30798138) Journal

    You're confusing indenting with alignment. Indenting is a set of whitespace at the start of a line indicating the depth in the scope. Alignment can be anywhere, for example between variable types and their names in a structure. If you have an int element and a float element, you might put one space after float and three spaces after int, then the variable names will line up. In languages like Objective-C and Smalltalk it's common to have colons lined up in message sends that wrap more than one line. To do this, you need to be able to guarantee that the whitespace that you put in one line is the same width as the characters that you put in the other.

    If your editor supports elastic tabstops, then you can use them, but then your code will look weird in something like viewvc or any editor that doesn't. This is why our coding conventions say you should use tabs for indenting and spaces for alignment. A tab is a semantic 'indent by one level' character, while a space is an 'advance the cursor by one character width' character. To have this work in a proportional font, you'd need to redefine space to mean 'advance the cursor by the width of the character directly above'. This is not impossible, but it would require a bit of hacking in the layout engine.

  • Missing the Point (Score:4, Insightful)

    by Deorus (811828) on Sunday January 17, 2010 @10:59AM (#30798326)

    While fixed-width might not be recommended for text, code is not exactly regular text. In a regular essay, skipping a period or a comma is usually not an issue. In code, however, it makes a world of difference, and therefore it doesn't make sense to use a font that may cause confusion between a pair of parentheses '()' and a zero '0', an 'I' and an 'l', a single dash '-' and two dashes '--', etc. Fixed-width founts are a lot clearer, and clarity and usability are extremely important for me.

  • Re:Overrated (Score:3, Insightful)

    by Yvanhoe (564877) on Sunday January 17, 2010 @11:04AM (#30798366) Journal
    Actually, it is less error-prone to work with fixed fonts, IMHO.
    In many occurences, one can anticipate if one line will have one more or one less characters than the previous one. Having a way to quickly check this gives a little supplemantal layer of proof-reading.

    this->posx=0;
    this->posy=0;
    tis->ttl=40;
    this->source="";

    The typo is easier to spot in fixed font.
  • Re:Dark background (Score:5, Insightful)

    by wed128 (722152) <woodrowdouglass@NOSpAM.gmail.com> on Sunday January 17, 2010 @11:11AM (#30798420)

    I call foul on this.

    On paper, you need the extra white to reflect as much reading light back at you as possible.

    with a computer display, the light is generated behind the text, so you don't need the sheer volume of light a white background gives you. This was even more true of old CRT displays, but even an LCD backlight produces way to much light to read comfortably. Note that non-backlit displays follow the opposate convention, and really benefit from a light background.

    in conclusion, go with what you're comfortable with; what do a bunch of dorks on slashdot know anyway?

  • RTF! (Score:2, Insightful)

    by Megane (129182) on Sunday January 17, 2010 @11:18AM (#30798486) Homepage

    I see a great need for compilers to support an RTF-to-plaintext filter on their front ends. Then you can program in whatever font you want, and it will look essentially the same when viewed by anybody else.

    But there should also be a standard on what you should and shouldn't do. For instance, it should not be kosher to specify text sizes or colors. Text sizes give you the "HTML mail" problem (where Outlook e-mails show up in a tiny font because the HTML hard-codes the font point size). Text colors screw things up for the "white on black" crowd, and also allow for "white on white" hiding of evil code.

    It doesn't have to specifically be RTF. RTF would really be overdoing it. Whatever format would be chosen should take well to merging in svn or whatever. Maybe something equivalent to Unix's #! line could specify the font. You don't want to specify the size, because that should be up to the individual reader, and I suppose the font should really be a matter of choice too. And most of the time, 8-space tab stops work well in proportional fonts.

    So you just need... um, you just need people to use 8-space hard-tab text, not use any tabs after the first non-tab character in a line, and... oh, I guess you can just use plain text after all, as long as everyone switch to hard tabs. Oops, never mind.

  • Re:Monaco (Score:3, Insightful)

    by kbielefe (606566) <karl.bielefeldt+slashdot@gma i l . c om> on Sunday January 17, 2010 @11:33AM (#30798606)

    TFA is comparing 10pt Monaco with a 12pt font. Put them both at 12pt and Monaco - which is monospaced - the way God intended computer displays to be - wins.

    You're missing the point that if you're trying to fit a certain amount of text horizontally on the screen, you can use a bigger font size with a proportional font.

  • Re:Monaco (Score:4, Insightful)

    by Sir_Lewk (967686) <sirlewk&gmail,com> on Sunday January 17, 2010 @12:08PM (#30798846)

    Um yes... its good looking.

    See what I did there? "good looking" is subjective and when you act like it's not you come off as a jackass.

  • Re:Python... (Score:1, Insightful)

    by Anonymous Coward on Sunday January 17, 2010 @12:16PM (#30798904)

    > ...the big criticism is that the parser uses the indentation to determine the structure.

    This has been true for config files and delimited data files since the dawn or programming.

    It's just that it hasn't been true for program code in most languages through that time--which isn't really a point against Python, it's a point against permissive formatting in other languages.

  • Re:visual cues (Score:3, Insightful)

    by coryking (104614) * on Sunday January 17, 2010 @12:49PM (#30799144) Homepage Journal

    Yup,

    Reading speed is irrelevant because of the bottleneck formed by reading comprehension.

    You shouldn't be reading code word for word anyway. Most of a programming language just symbolic (if, for, while) and could be replaced by icons and mean th same thing. The only real words are the variable and function names. As you read the names, it automatically fits them into the overall block of code. The only way your brain can do this preattentive trick [ncsu.edu] is if you provide it visual queues through syntax coloring and indentation. Take out one or both and you are stuck reading word-for-word... Since proportional fonts change the indentation, the meaning of the code is altered and spend more time reading the words instead of the meaning--comprehension slows down, not speeds up.

    If you think that proportional fonts helps you read code faster, I'd argue you aren't reading code correctly in the first place. You don't read a book letter by letter, you read it word by word or even sentence by sentence. Likewise, you don't read code word for word, you "read" it visually block by block pulling meaning out of the variable and method names. If you are reading code in your mind literally like "if variable1 equals variable2 then set variable3 to 5", you are doin' it wrong.

  • Re:Overrated (Score:5, Insightful)

    by ceoyoyo (59147) on Sunday January 17, 2010 @01:11PM (#30799306)

    Just use tabs. If the dork who opens your text file doesn't have his tab stop set for his preferred size then he deserves to see ugly code.

    You probably use four spaces, hey? Personally I hate four spaces. Waste of space. Two is the way it was intended to be. But I understand that other people might have different preferences. With tabs we can all be happy.

  • Re:Overrated (Score:2, Insightful)

    by Anonymous Coward on Sunday January 17, 2010 @02:04PM (#30799686)

    Sorry, Elastic Tabstops solve nothing. That is just yet another way of interpreting a tab character. The problem with tabs is the tab character itself and the fact that different rendering mechanisms interpret it differently. If you type a tab in an editor which renders it as an 8-character indentation and I view it in an editor which renders it as a 4-character indentation, then what I see is not what you intended. The only thing which works consistently is to use a fixed-width font and space characters for indentation. Any programmer who doesn't grasp this and who puts tabs into his code is obviously not a good rational thinker and is thus probably not a very good programmer.

  • Re:Overrated (Score:5, Insightful)

    by pjt33 (739471) on Sunday January 17, 2010 @03:30PM (#30800336)

    Nonsense. Differing widths of tab-stops only cause problems when people mix tabs and spaces.

Wherever you go...There you are. - Buckaroo Banzai

Working...