Slashdot Mirror
Programming With Proportional Fonts?
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 guys just trying to ensure the prophecy of the helvetica wars is fulfilled
Monaco is fixed-width & good looking.
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
... yeah right!
I've programmed in proportional fonts. It's ok, but I prefer fixed width for alignment.
This is my sig.
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.
MS Comic Sans is simply the best. My code doesn't have bugs, it has bloopers and out-takes.
fixed, AKA 6x13, or more formally, -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1.
The one true programming font. No other font better manages the compromise between legibility and compactness, and being a well-crafted bitmap font, it is crisper and clearer than ever on modern LCD screens.
X11 got it right 25 odd years ago, and now with near-full Unicode support, it's only gotten better.
It's the only way to write real code.
Stick Men
This was my favorite for a long time. No question about 1 and l, or 0 and O; which may have been identical in the default Monaco. Also :,;, and , where slightly bold so one could easily see statement ends.
But for whatever reason, big screens, better fonts, syntax highlighting. ProFont was quite readable in 9pt; important on small screens. I might try to put ProFont in Eclipse tomorrow. ProFont can be found here: http://www.tobias-jung.de/seekingprofont/index.html
and my lines of code cannot contain ascii-art anymore
àà®à¥à®à¾à¦ààYà¥àà àà
... /. had a thread very similar to this.
And there were a lot of valuable inputs, like
* 1. Make sure that the font's period (.) sign and the comman (,) sign is BIG, to aid in the debugging process.
* 2. Color of the font and background must also complement each others. Too much contrast hurts the eyes. Too little will blur them up and make it hard to see.
There are many other very useful pointers in that thread. If anyone can dig that thread up it would be very very useful for the new crop of programmers.
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 for coding, and it's excellent (and available under the Open Font License).
On Fedora, yum install levien-inconsolata-fonts.
From what I understand, the way we process written words is based on the idea that each word is a like a "picture" made up of letters. So, the easier it is to identify the picture, the easier it is for us to read. This means that the width and height of letters plays an important part in creating unique pictures. It is for this reason (at least in print) serif fonts are much easier to read than sans-serif fonts. It's also for this reason that ALL CAPS is the most difficult way to read compared to just reading normal text. On this basis alone, it's likely that proportional fonts are better to read because they're likely to create better word pictures.
'If Christ had tweeted the sermon on the mount, it might have lasted until nightfall.' - John Perry Barlow
if you're programming in COBOL.
Reading code is not like reading prose. It's more like reading poetry, where how the text elements are spaced and aligned can say a lot about the author's intended meaning. If I'm reading a book, I definitely want it typeset with a proportional typeface. Code, on the other hand, is MUCH more legible when set monospaced.
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.
# cat
Damn, my RAM is full of llamas.
/. is meant to be the font of all knowledge, not the knowledge of all fonts
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
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).
In the comments there, MMZ (author) notes "This was written 2 years ago."
Can we get a "-1 Wrong" moderation option?
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.
Lose essential liberties to get temporary safety = get only hassles and security theater.
When reading code speed is not the most important thing. Here quality is more important.
And the quality of alignment brought to you by fixed-length fonts is more important than any marginal gain in reading speed.
--
El Guerrero del Interfaz
Sounds like it shouldn't be a problem as long as you stick with 'the one true style' K&R.
The people who are going to maintain your code will probably use fixed-width fonts. Clever alignments tricks won't work for them and your code will look horrible.
If I were your boss, I'd just plain forbid this.
Unless your code is for yourself only, stick to the "standards". A 14% improvement ? Gimme a break...
I like the examples they show to prove their point.
Fixed width Monaco 10pt, which comes out too small and kind of blurry to me.
and Proportional Helvetica Neue 12pt, which is in a bigger font and is actually reasonable sized.
so yes, a reasonable sized proportional font is easier to read then a undersized fixed width font...
Troll is not a replacement for I disagree.
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.
now we need to go OSS in diesel cars
Terminus is what I tend to use now, but I really liked Neep and Neep Alt(I think). I think it was in the jmk-bitmap packages or the like. Google would probably find them :)
Programming with proportional fonts, this guy is funny!
Yes, let us use Microsoft Word or OpenOffice for programming!
n/t
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
But try it in assembly language.
now we need to go OSS in diesel cars
I like to line stuff up, such as assignments. (Tried to demonstrate this with a code sample, but /. comments collapse spaces)
So for a list of const definitions in .h file, for example, despite variable names of differing lengths, the "=" signs will all be in the same column, and the values will all begin in the same column.
You might be able to achieve this with a proportional font and tabs, but I don't trust tabs.
actually i want to have each variable a slightly different colour. That way i can easily follow the use of the variable throughout the entire source. (globals etc.) .
Choice of fonts is very subjective, similar to look of a desktop environment.
Take your pick.
http://www.codeproject.com/KB/work/FontSurvey.aspx
My favourite is Terminus. Unbeatable especially in environments without anti-aliasing.
http://fractal.csie.org/~eric/wiki/Terminus_font
Are we really in such a hurry when reading code? I'm under the impression that fixed fonts allow us, when we parse code, to see the different elements more clearly because their size is determined by the number of characters. But that's just an intuition. Anyone else has the same feeling?
Because the distinction of 0 versus O, I versus l, and l versus | don't matter in programming languages.
I'm sorry, but that font choice is a disaster waiting to happen.
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.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
The Python zealots will be along shortly to defend their indentation insanity in 3... 2... 1...
... out there, regardless of the coding language, who are developing and writing their code on those old punch card systems ... you insensitive clod!
now we need to go OSS in diesel cars
At work I do a bit of matlab programming and the default font makes it very hard to see the difference between parenthesis and curly brackets. That's a huge glaring flaw in the defaults that come with the IDE.
Back in the dark ages when I did a lot of FORTRAN77 programming, I would output a lot of data tables. Trying to setup the print statements to make those tables with a proportional font would make me want to kill someone.
Today I pick my fonts for programming on how readable the punctuation and letters vs. numbers are, and what I've got on the computer I sit in front of. Sadly I do a lot of code snippet writing on walk-up computers, or conference room computers, where I've got a standard windows and office font load.
I also do a lot of LabView programming, and the glyphs, icons, and lines are always proportional. :)
Sheldon
The "article" is stupid and ill-informed.
The author compared a Monaco at 10pt with Helvetica at 12pt and concludes Helvetica is easier to read.
I could do a similar test with Helvetica at 7pt and Arial at 12pt and conclude that Arial is better!
In programming, readability is determined by different factors than for literature. Word-pictures are less important since you basically have to deal with a lot of made-up words (variable and function names) but what's really important is to eliminate any room for misinterpretation, e.g. I vs l or " vs '' or O vs 0
Hands down, my font of choice for programming is Consolas, followed by Inconsolata.
... that while proportional is more visually appealing, fixed width is easier to read when it comes to large amounts of text. I don't know if that's bunk or not, but I'd rather code in a fixed width.
All code in Stroustrup's "The C++ Programming Language" is presented in a proportional-width font: "At first glance, this presentation style will seem 'unnatural' to programmers accustomed to seeing code in constant-width fonts. However, proportional-width fonts are generally regarded as better than constant-width fonts for presentation of text. Using a proportional-width font also allows me to present code with fewer illogical line breaks. Furthermore, my experiments show that most people find the new style more readable after a short while."
Not only is the font proportional, but it's bold, italic, and serif as well. Now, reading a textbook is of course pretty different from editing on-screen, but I remember reconsidering some of my habits after reading that book. That code ain't hard to read.
I'm a fairly serious typography geek, and I can tell you that for something like programming, fixed-width fonts make a hell of a lot of sense. When you're dealing with windows or displays that have a certain number of characters (80 char terminals, for instance), or programming languages that use a lot of nesting, having the visual cues of alignment far outweight the benefits of refined character recognition and easier legibility (which by the way generally only applies to long blocks of text set in a language in which you are conversant). And this is coming from a guy who generally can't stand seeing fixed-width fonts used (except in very specific circumstances, like this).
Use two different font sizes to prove your point: check
Must use tabs in code to get columns to line up: check
Use Baby's First Language instead of a real language: check
Another young idiot, with another idiotic attempt to make programming easier. You can create all the baby languages you want (Java, C#, VB), and come up with all the stupid tricks you want. Programming is still hard, and will remain so.
Proportional fonts: look pretty, increase readibility of words.
Monospaced fonts: increase readibility of code by making all symbols very distinct (ie. ( from {, O from 0, -- not a single line, etc.). The 14% improvement you gain in reading keywords and variable and fuction names is nothing compared to the bugs that arise from similar-looking symbols.
I use Terminus, with no smoothing of any kind. Just raw, beautiful pixels.
:wq
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:
Reasons to use them:
I thought I would have a look at this font but it looks terrible on windows with cleartype on at 11points, however I managed to find a hinted version at:
http://pgl.yoyo.org/bits/tech/inconsolata-cleartype-raph-leviens-inconsolota-font-hinted-for-windows/51:2008-09-25/
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.
Call me crazy.... but I started doing this a couple years ago.
I can't remember what font it was now; I was programming under linux using eclipse.
But I really enjoyed switching away from a fixed width font...
You can tell how powerful someone is by the magnitude of the crime they can commit and be able to get away with.
Betty AND Veronica
I believe proper use of whitespace in programming makes enormous improvements in recognition. Spaces in proportional fonts are often thinner and less contrasting. That alone may reduce proportional effectiveness, more readable or not. One would have to form a habit of using two space characters and more tabs.
That's way faster to read than anything on a bleed-your-yeys white background.
You should
1. setup good lighting
2. adjust your monitor to the lighting
and then you won't want to go back to black background. There is a reason why we use white paper and dark ink.
There are a few people who indeed need dark background, but that is related to serious eye disorders.
... the way God intended computer displays to be ...
Slashdot 10:01:17: Thou shalt use no GUI, and only text mode - the way God intended computer displays to be!
... but my VT102 terminal only has the one and the APL compiler doesn't understand a \t.
#include "humorous_pop_culture_reference.h"
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.
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?
The programming environments by Rob Pike use proportional fonts by default. Both Acme (also used by Dennis Ritchie) and Rob's previous text editor Sam (still used by Ken Thompson, Brian Kernighan and Bjarne Stroustrup).
The rio terminal windows also use proportional fonts.
At first (like many other things from the Plan 9 world) the lack of precise control about how everything spaced can be a bit frustrating, but once you learn to stop worrying about it, it can be rather pleasant and liberating to use (good) proportional fonts for writing code.
"When in doubt, use brute force." Ken Thompson
proportional fonts can be read 14% faster than fixed-width fonts
Sounds good, until brain engages, 14% later. can be always flags +10 in my wetware instance of CrapAssassin, unless BeerGoggles is displacing cycles.
I think, with maybe 60,000 hours of reading time under my lengthening belt, I'd have noticed this effect by now, if it applied carte blanch to all modes of reading. The other night I skimmed the 130,000 words supplied in response to the Edge 2010 question "How is the Internet changing the way YOU think?" This was not the cream of their efforts, but there were some interesting topical centers.
My reading speed through this exercise varied by an order of magnitude, depending on signal density. The weird thing is, for some of the longer responses, my subconscious sends notice "nothing to see here" at a skimming speed where I have no clue what words are actually flying past. Every so often, I drop out of warp speed to double check, and sure enough, not very much to see here, by whatever criteria turns my crank, which itself is sometimes elusive to my conscious mind.
I took a speed reading course and read 'War and Peace' in twenty minutes. It involves Russia.
— Woody Allen
I once attended a school where in some dark closet they kept copies of "Duck and Cover" films, as well as a CRM114-vintage machine designed to stretch your saccade, by forcing you to read words in a revealed window with a progressive speed ratchet.
I never did especially well compared to the best of my classmates on the quiz that followed. Had they slowed that stupid thing down to about half the speed they were forcing us to read, followed by an essay question to expound upon conceptual error, distortion, slant, exaggeration, and damn lies, I would have run out of foolscap before completing my task. In critical response, I was an autobahn surrounded by country lanes, yet many of my classmates could read for uncritical comprehension faster than I could. Dangerous skill. (I'm sure for some of my old classmates, whatever dirt path once existed has returned to nature in their adult years, with ample fertilizer from mainstream media, but that's another matter.)
It's no different with source code. You can read for comprehension, or you can read for all possible error, a state of mind where the eyes consume only a tiny fraction of total brain glucose. Critical thought in the candy factory is hard enough when the conveyor flows along at a consistent speed. Neither can I properly type a long sequence of i and l characters worth a damn in a proportional font. My eyes fail to sync with my fingers, and half the letters fall down my shirt.
Nothing impairs reading speed like a tightly written algorithm where every symbol is exactly right. Nothing inflates the volume of symbols violently gouged onto the retina as a chunk of code where no symbol means precisely what it seems to mean.
Personally, I'm not lining up for smaller gouges in greater number.
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.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
if it makes it hard to write ascii art it cannot be good for programming
I'm positive, don't belive me look at my karma
Real men program using Wingdings.
If they did those studies with $JoeRandom, they are meaningless for programmers, who see fixed-width fonts all day long.
Oh, actually I just came here to say: “Those who do not learn from history, are doomed to repeat it.” (In that some new generation thinks they have to test it for truth all over. Which can make sense... If you build up to what is already known, and not just ignore everything.)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Perhaps because most displays are sold pre-set to 100% brightness, 100% contrast, because that's what looks shiniest and most vibrant on display, driving sales.
A while back, I experimented, with the assistance of a color calibrator I use for photography (i1 Display 2, and turned the brightness on my LCD to 40%, contrast to 70%.
The result? "Wow, that's so dim. I don't think I could read that..." ... for about an hour. Now it's fantastic. My eyes hurt less, especially when the room is dark, and seem more sensitive (in a good way). Reading online all day, coding... so much more pleasant. Definitely a worthwhile experiment.
I see a lot of great points for mono fonts, most notably the ability to quickly distinguish puctuation marks or errors such as "' " versus " ". But acctual words and blocks of some code are easier to read in a proportional font. So... is there a font out there specifically designed for coding, with the best of both worlds?
This was on reddit today
http://hivelogic.com/articles/top-10-programming-fonts
Punch cards, with a dry ink ribbon, read against the light in 7 bit ASCII...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
No pro-programmer I know prefers a variable-width typeface to code. On first thought, a fixed-width typeface makes it easy to align statements and numbers. But one can get all that, and more, using tab-stops. So, on second thought, why do we prefer fixed-width typefaces to code? Well, in coding, things that are similar should look similar. ...
From: http://codeblab.com/2009/12/fixed-width-coding/
I write Fortran4 you insensitive clod.
Sent from my ASR33 using ASCII
I've tried, and I just can't keep the columns straight when programming RPG with a proportional font. Anyone got any tips?
-a.e.mossberg
That typo would be exactly as easy to spot in a proportional font because it happens at the beginning of a line where all will be lined up. If you add stuff to the beginnings of each line to put the text farther out, it will line up in a monospaced font only if you have exactly the same number of characters before the common text. That will happen either by chance,
in which case any editing will undo the chance, or by artificially padding out lines with oddball spaces, in which case you will be putting in a lot of work which will be a pain to maintain.
Monospaced fonts have their purposes, but your example is not one of them.
Infuriate left and right
I don't care what font other people use so long as any code I'm working on reads fine in an 80 column terminal with fixed width fonts. Just use whatever works for you and let's debate tom-ay-to vs tom-ar-to instead :-/
Dim your display? It saves battery power on a notebook too.
Today's IDE use special windows and sections to display structures of classes, XML files, schema definitions. Automatic generated program documentation is also already in proportional fonts. While most of the reading is done to lookup features (method names, tags, structural semantics) this is already done with proportional fonts. The only place where you read actual mono spaced text is in an editor to edit a class or function (if you are programming in a non OOP language).
However, there are other techniques which can improve reading speed at an even bigger scale. You could use domain specific languages (DSL) to generate C, Java, Python, Ruby, Fortran, etc. code. So instead of describing every aspect of every class you can use a problem specific language to model everything. Combined with AOP you can reduce the code base which must be read by humans by 300-400%. And if you are writing another application for the same domain you are able to reuse a lot of the template and artefacts you used for the first time.
When I started in computers (1993?) we did our programming at the console. And I remember being very thrilled the day I found that Linux had a "setfont" command, to set the console font.
"r.psf" was a great font. It set the console to a kind of "Times"-like font. Except it was still monospace, 80x25. The serifs made text really easy to read. Numbers looked distinctly different from letters, and certain digits (3, etc.) were "dropped" a little. You never could mistake 1 for l or |, or O for 0, and so on.
Combined with setting the foreground "grey" and the background "blue", it made reading/writing code a snap, and the console experience very pleasant. For that first year, I preferred doing everything at the command line, and would start X11 only if I needed to do something that required graphics (like, gnuplot.)
Although it gets to be a real bitch at 64-bits!
in conclusion, go with what you're comfortable with; what do a bunch of dorks on slashdot know anyway?
Yep, let me open with "GET OFF MY LAWN!"
As the eyes age, all that extra light from a white background constricts the pupils, which makes it easier to focus without corrective lenses... all a matter of personal taste and physiology.
On the other hand, true tabs in source code is a continued source of annoyance in my life - yes, tabs are superior to spaces, short term. Longer term, that source code will be opened on different editors where different settings make the tabs seriously annoying. And, why the tab rant? Because, the only way I would program with proportional fonts is with tab alignment for "tabular" blocks of code.
Fixed space fonts are just easier to manipulate, especially with column/block selections - and if your code doesn't need column manipulation, you're not fully using one of the two dimensions available to you to organize your information.
So, is it 14% faster to read a proportionally spaced novel, or 14% faster for an experienced programmer to read a block of code in proportional fonts? I know it's more than 14% slower to correct a hosed up file full of wrongly tab-spaced code, even if it is a sort of zen-like walkthrough to fix the spacing while getting familiar with the code.
I used Geneva 9 point for the longest time for the proper spacing between the letters. I never had any compelling need to use a monospaced font to program since I was offered an alternative.
- Zav - Imagine a Beowulf cluster of insensitive clods...
Thing is, you don't "read" source code the way you read normal text.
No sig today...
windows / super m or n
instant pain relief
Long ago, people used to do real studies. They timed people reading text, and they found that serifed fonts and proportional fonts were easiest to read, meaning people could read the texts faster.
All through the responses to this article I see people making assertions that coding isn't reading, that this won't speed things up, paper is different from screens, punctuation would be too hard to read, etc.
OK, where are your studies to back this up?
So many assumptions. It would be nice if someone here said instead "OK, I'll test this with my team and get back to you in a week."
For people who's "computer science" job consists in doing Object-Relational mapping, sure... Proportional may do the job.
But for anyone working with "true" algorithms, forget proportional. You need a fixed-width font (and, no, the elastic tab, let alone the pathetic non-existent editors support, ain't cutting it enough).
Show me a dynamic programming algo that doesn't look sucky with a proportional font. Show me some FSM implementation that doesn't look sucky with proportional font.
When someone argues that "proportional font are better for programming" you can safely consider the guy mostly clueless about algorithms, big-O perfs, etc.
They like their proportional font as much as they think nothing is bogus with someMethodThatDoesSomethingNTimes(...). Sure, with such long method names you better 'gain back' every pixel you can by using proportional fonts.
In other words: give him the monkey ORM type job but don't count on him to know about when to use, say, a skip list.
(btw this post touch-typed on a blind IBM Model M, monospaced font of choise being a modified 'proggy font')
Comments could be one font. Attributes another. Functions a third. As could DB and library calls. Has anyone tried this? Do you think it would help? Or would it be too noisy?
putting the 'B' in LGBTQ+
I'm a Whitespace developer, you insensitive clod!
Well, do as you please. You use your font and I use mine.
Reducing something by 300% leaves -200%.
I sure as hell don't want to be anywhere near your code.
Switch between monospaced and proportional with Ctrl+F11. Easy as pie.
http://www.scintilla.org/SciTE.html
From 1986 to 1993 I used proportional fonts in terminals and in the text editor (which was Emacs run in the terminal). It worked quite well. I fully expected this to appear on it's own and am rather disappointed that my ideas never seem to have happened again. I could try to make a program that uses them but do we really need another terminal emulator?
I have no idea if the code I wrote can be found: first is the NeXT-machine terminal emulator made by Mark of the Unicorn called "Communicae". Second is a terminal emulator written for the Sun NeWS system called "jet".
Both programs used the same technique based on getting the best output from programs expecting fixed-sized fonts. First of all spaces were rendered as "en spaces", actually it used the width of a '2' character. This made words be somewhat spaced apart but made most tables of numbers line up. Second was that 3 or more spaces, and also a tab character, would move to the N*en position, regardless of the text earlier, where N is the number of characters (plus the round up to multiple of 8 by tab characters). In most fonts this would make a wider space, if not I think it avoided overprinting by instead making the space zero sized rather than negative.
The rules were limited by them being run when updating the display. On modern machines I would think much more complex pattern-matching rules could be used, such as detecting alignment in adjacent rows, and detecting usage of | and - and + in ascii art and replacing it with line drawings.
what do a bunch of dorks on slashdot know anyway?
Well, collectively there's someone who knows the answer to any question you ask, complete with car analogy.
There's no place like
I do. But why does mono spacing matter if people don't read their source like normal text?
- Zav - Imagine a Beowulf cluster of insensitive clods...
DejaVu Sans Mono on emacs23 here, been using it since I first compiled emacs23! Non-fixed width fonts just don't work for me when I'm programming. I don't like the random look they have in my programs.
Stop trying to program with *any* fonts. Get the glyphs from some sort of system-wide font handler so the users can change them, and design your modal dialogs and menues such that they can accommodate the changes, including size changes.
Depending on fixed-size system fonts was fine back in the mid 80s, when you were lucky have a display a full 640 dots wide. It's the 10s, now. People's screens and eyes are all kinds of wonderful permutations of each other. Let us specify our own sizes.
Can you be Even More Awesome?!
I consider the suggestion of using a proportional font for programming frivolous and a bit juvenile. In fact, I'm of an age where it seems a little off if my SSH backgrounds are not green-on-black (and hence make them so).
That said, a *good* fixed font really makes a lot of difference. Not too long ago, I found one called Anonymous Pro, that I have become very fond of:
http://www.ms-studio.com/FontSales/anonymouspro.html
It's freely available, TTF, and I've installed it most places. As much as I hate being forced onto Windows machines, in the few cases where I am, I actually think Consolas is pretty good quality too.
Buy Text Processing in Python
What would be nice would be an IDE that could deal with proportional fonts. Keep my tab stops, spaces, and braces in alignment, but render the text in proportional font. I understand the value of being able to read the language part of my code as language, and read the structural part of my code as structure. The best of both worlds would be nice.
I'm sure proportional fonts can be read faster than monospace fonts, but this is absolutely and completely irrelevant. In no way, shape or form is reading speed something that slows down developers.
He who laughs last, thinks slowest.
HiveLogic did an article last year about the top 10 programming fonts. Inconsolata was number 1, but I believe all of the top 10 were monospaced fonts.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
Consolas is a good font, but I don't like the distinction between 1 and l. I think that incurs more cognitive overhead than it should. This kind of unobvious distinction is an issue with most fonts. For a long time I used Andale Mono (despite hearing fontophiles sneer at its esthetics) because the letter l is radically different from the digit 1. Then I discovered Vera Sans Mono, which has a similar letter l, and also has a narrow underbar, so that sequential underbars don't form a continuous line. I've often wondered why so many "programmer friendly" fonts overlook this issue: continuous underlining makes it easy to get the wrong number of underlines in things like __WEIRDCONSTANT.
Incidentally, both these fonts are designed by major font foundries, but are available for free. Andale Mono used to be part of Microsoft's free "core web font" program; that's long ended, but nobody seems to care about all the copies available on the web. The Vera Sans family appears to be Bitstream's donation to GNOME.
This discussion caused me to google "programmer fonts". Some interesting discoveries:
As long as tabs (And corresponding blocks) are indented properly, I don't think I would care as much.
They totally lost me in the "better" example for proportional spacing in the link for making the case, when I saw how collapsed a pair of parens [ () ] became in the proportional font - almost invisible, making it hard to recognize function calls.
In that example the mono-spaced font they chose just sucked, there are many more readable monospaced fonts which would look way better than the proportional example.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Try to see which characters (they're all unique) these are and position your cursor between them in a hurry with a proportional and a fixed width font: il[I|]
Anytime you see some coder craning towards the screen with narrowed eyes when selecting something, he's probably using a proportional font. Proportional fonts are better for reading prose, are not good for reading code and are terrible for editing code. Much of this is personal preferences and a few things (like 0 and O looking similar) can be fixed, but a few things are real. Editing characterwise will always be easier when the characters occupy the same space regardless of their actual width.
IMHO everyone should use a fixed width font for editing, even if it's not code. It's just much easier.
I pretend I'm reading the printout from a selectric.
Sent from my PDP-11
Apparently it's a Macintosh font, which is why I didn't get the joke :-) However, it's designed by Kris Holmes (who did Lucida), so I assume there may be some licensing or cost requirements. Is it available for either free-as-in-speech or at least free-as-in-beer? It's possible to download from various places around the web, but I don't know whether that's legitimate or not.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The human eye cannot adjust to two different brightness levels at the same time. So the brightness of the display must be similar to the environment. If someone has to sit in a dim room, then, and only then, it is correct to use dark background. But working in a dim room is a bad idea to begin with.
wed128 doesn't realize that it doesn't matter if light is produced from behind the text or is reflected from around it. Luminance is luminance, no matter if it is emitted or reflected. Dim the display to be the same as paper in you current environment. What makes paper easier to read is print, pen, and pencil are usually thicker/bolder than displayed text, and of higher resolution.
The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
You could include pictures in your code ( which are automatically comments)
The font and size of the code is changeable - you can have parts in a monospaced font and parts in a proportional font.
Outline levels are used to block statement
Times New Roman looks really good to my eye. .xccolortheme file)
This is my Xcode setup:
http://vectorvector.tumblr.com/post/339810337/proportional-font-programming
(I link to the downloadable
Worst to my eye: Monaco and Arial.
-- http://vectorvector.tumblr.com/
He has a bit of a point - paper is self adjusting. The luminance of white paper is always going to be the same relative to the luminance of anything else of a given reflectivity, so in general it will always be about the same relative to the surroundings. A computer screen, on the other hand, may be much dimmer or much brighter than the surroundings, if you don't adjust it (or if it's not smart enough to adjust itself). Paper IS easier on the eyes than a badly adjusted screen, due to luminance. It's also easy to fix.
I notice most text on my screen is usually smaller than printed text. When it's blown up to about the same size it's not really a problem to read.
A data point in this discussion is that it is traditional for Smallltalk implementations to use proportional fonts as the default for code editing. I've been programming in Smalltalk since 1985 and I think I've only encountered a couple of people who changed the default to anything but a proportional font. Some Smalltalks allow for rich text code, and then you'll see ASCII art done as a monospaced font section embedded in a larger proportional method or comment. But I've not seen it that often. Maybe I've led a sheltered life.
Another data point is the book "Human Factors and Typography for More Readable Programs" by Ronald Baecker and Aaron Marcus ( http://www.amazon.com/Human-Factors-Typography-Readable-Programs/dp/0201107457 ). In this outstanding volume they build a framework for understanding program legibility and an approach to formatting C programs that utilizes this framework. Recommended to anyone who wants to have a better understanding of the issues in this area.
I like the look of proportional fonts. But if you go for elastic tabstops, everyone using your code (you, your boss, your co-workers, the company you might be developing the code for which might not be yours, maybe co-workers on other teams too that might need to spelunk the code) all have to be using editors capable of using these elastic tab stops.
If they aren't, and the number of tabs inserted was different or if someone mixes spaces and tabs, it'll look like hell if they're using a different-width or different-kerning font (including fixed width).
And yes, some of you say 'too bad for them'. Except of course that quite a few of them may be higher on the corporate food chain than you are and/or perfectly willing to make your life miserable until you conform to a standard.
If everyone moved to Elastic Tabstops, and all the tools did, I'd love that.
Unrelately, my favourite programming fixed width font is: Andale Mono (check it out)
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
... is a proportional font called Cynthia Handwriting (the font license says it's OK for personal use) - I like how
This font isn't for everyone, though. I code in Java, where the class names are long and the doc strings abound, so most things read as words anyway. I also use Eclipse with a theme that bolds keywords, brackets and braces; the default settings also perform brace matching when I select a brace. It's pretty neat.
Comic Sans MS FTW!
If you weren't using Python or some other whitespace-is-syntax-fool language it wouldn't matter - your IDE could easily reformat the code for you. Thus space vs tab becomes somewhat moot.
goes something like;
with dark text on light background you get more light entering the eye, which causes the pupil to contract and increases the depth of field of the eye so that it doesnt have to work so hard moving around to get a focused image.
so assuming the brightness of the white and darkness of the black is the same in both cases of; white text on black background and black text on white background, the former should result in less eye fatigue.
although perhaps im missing something. as i tend to like bright text on black background consoles and editors late at night with the lights off (presumably when my eyes are already fatigued)
The typo is easier to spot in fixed font.
Actually, it's just as easy to spot in a proportional font, because what you're comparing isn't a character count but equal prefixes. If they're strcmp-equal, wouldn't they also be pixelwidth-equal, independent of the (constantness of the) char-to-pixelwidth mapping, as long as it doesn't vary per line?
Of course, you're right in your point that it lets you compare character count visually much faster. That seems to be relevant somewhat less often, though.
Maybe it's because white paper is easiest and cheapest to make?
... proportional fonts can be read 14% faster than fixed-width fonts
Does that really make any difference at all in programming? I doubt it; understanding source code does not hinge on how fast you could read the text, in my experience. What really helps is something else:
- Good indentation that follows the block structure of the code
- Good symbol names that are neither too simple nor too rich in information
- Good comments that explain why one has chosen an unusual algorithm and that sort of thing
I think when you read code, you don't read through each letter, you perceive each keyword as a whole. This process gets easier when you always use the same font in your editor, because the keywords then always have the same "shape". Personally I find the "grid-structure" of fixed-width font helpful when writing code, because I can relatively easily format the layout of things, which I occasionally do - eg. when I set up data in an array or table form.
As a coder I don't care about proportional/mono fonts. What I do care about is a font with clear and distinct characters, especially O0ilI({)}[]
To be honest, I'd like to bring back the ø for use in code.... I know its strictly a maths symbol and not a zero but it would be clearer than trying to spot a capital oh from a zero...
--- Users are like bacteria -> Each one causing a thousand tiny crises until the host finally gives up and dies.
How come people citing studies from the early '80s on reading normal text become experts on programming ergonomy? There are several reasons to distrust this.
1. Experience: normal readers (which were the subjects in these studies) mainly have experience in reading proportional fonts. Programmers on the other hand...
2. Context: ease of reading depends on the context, as does almost every cognitive task. Normal text does not look like code at all, so cannot be expected to be representative.
3. Importance: reading speed is not that important in programming. Reading speed for code must be way below that of normal text (which is 3 to 5 words per second for easy text, plus or minus a bit). I cannot imagine a programmer reading and understanding at that speed, so reading is not the bottleneck.
4. Errors: proportional fonts make it easier to misinterpret: 1, l or i? rn or m? 0 or O?
So, unless someone comes up with a relevant study, this should be discarded. And relevant doesn't mean speed alone.
Yes, I am a programmer and, yes, I do have a PhD and postdoc in psycholinguistics.
ProFont is my font of choice for programming needs. It's small and it provides a "0" (zero) which is good to distinguish from a capital "O". Extra goodie for german speaking coders: it includes umlauts.
Use code blocks - you know code in pointy brackets - just like in html.
Did I mention how old I was??? Them newfangled IDE autoformatters are a) one more thing to learn b) not really capable of reading my mind. I do occasionally break "formatting syntax" rules in the interest of visual clarity. I stick to a standard style, unless the standard style is obfuscating what I am doing in the code - which happens more often than you might imagine. These "custom style" blocks will often turn 10 pages of repetitive code riddled with copy paste error potential into a single page table where the errors literally jump off the page at you.
I'm a variable font user. I used Tahoma for the readability at lower resolutions, but ended up modifying it using a font editor to fix a few annoyances. I increased the width of the space, made all numbers, and punctuation characters the same width, as well as a few other minor tweaks (like adding a dot to the middle of the zero and adjusting the look of some characters like greater/less than signs)
You are all a bunch of limp wristed weaklings with your god damn new yuppie fonts. Use '-misc-fixed-medium-*-*-*-14-*-*-*-c-*-*-*' and view your code as emacs and X11 intended it with hard, cold gloriously pixelated simplicity.
Light is light, whether its coming reflected off a sheet of paper or being generated by a computer monitor. Your eyes can't tell the difference between "emitted" and "reflected" light - its all just photons to your rods and cones.
The difference is brightness and directionality. Paper is a fairly rough surface, and tends to scatter light in many different directions. Monitors tend emit the light in a single direction, much like a flashlight. This is the reason that light backgrounds are more comfortable on paper than on computer monitors - the paper scatters much of the light away from your eyes, lowering the apparent brightness of the background.
To see what I mean, try reading a book printed on glossy paper outside, or underneath a bright lamp. You'll find that the sort of eyestrain you get is exactly the same as with staring at a computer monitor for too long.
We all know what to do, but we don't know how to get re-elected once we have done it
(subject)
I'm surprised no one has mentioned it.
"Fish" (David B. Trout)
People have commented on the light sensor on my mbp being 'gimmicky' (other laptops probably have them too in the interests of fairness!), far from it imho.
Invaders must die
Ah yes, I was going to mention the MBP. I usually forget that mine adjusts automatically, but it usually manages to be comfortable to look at outside during the day or in dark rooms with no windows. One of the best features.
what do a bunch of dorks on slashdot know anyway?
Very little, and always less than they say they do.
But what would I know?
./Rockwolf
February 9th, 2009 8:55pm: Slashdot becomes self-aware.
Does anybody know of an editor with vi-like keybindings supporting proportional fonts?
Vim, the obvious candidate (or MacVim over here) does not and will not support proportional fonts, due to its internal design.
I'm all for programming with proportional fonts, but I will not give up my modal editing.