> Picking a programming font is like picking a religion. No matter what you pick someone will say you're wrong. Most people will agree at least that monospaced fonts are ideal for reading code and that both of you who use proportionally spaces fonts are destined for hell, or at the very least, purgatory.
I guess I'm destined for hell or purgatory then.
Hanselman is not alone. I had the CEO of one company look over my shoulder and ask, "Mike, I don't understand how you can program in a proportional font. How can that possibly work?"
He wasn't interested in the answer, he just wanted to make a point to me and our teammates that what I was doing was weird and wrong.
I would hope for people to have more intellectual curiosity than this. One of the best ways to learn is to let your assumptions be challenged: talk with people who do something differently from you and find out why they do it.
It's been said that a programmer should learn a new programming language every year or so, and especially learn a new kind of language that will teach you different ways to think about code.
Similarly, I think every programmer should try coding in a proportional font, at least for a while. It may show you new ways to think about how you format your code, as it did for me when I got curious many years ago and tried it.
For example, it cured the bad habit I had of lining up too many things in columns, like this:
This indentation-only style has many advantages, and of course it works just fine in a monospaced font too. In fact the Rust/Servo team recently switched to it from their former column-aligned style.
I used to have a coworker who was REALLY slow at reading code. For the longest time, I couldn't figure out why, but eventually he told me he was dyslexic.
I mentioned that I had hear of some fonts that were specifically made for people with dyslexia, so he downloaded one and tried it out. There was an almost immediate improvement in his output of code, and it was always interesting to go read over his shoulder and see things not-monospaced.
Personally, I only stick to monospaced fonts, but I wouldn't be totally opposed to trying something else. I even tried dotsies for a while (http://dotsies.org/) but could never get used to it and it slowed me down too much.
It means constant readjustment and unnecessarily bloated diffs every time you change a function or variable name.
or the lovely
foo := a;
bar := b;
then a day later
foo := a;
bar := b;
foobar := cd;
which also points to the problem that it lends itself to premature constant readjustment because a day later you have to move every thing again because as it turns out you really needed foobarlist as well. and each time you end up with a diff reporting that foo and bar (and then foobar) have changed too.
It's making busy work for yourself and ruining the usefulness of code review tools.
ALSO alignment vs indentation is the whole reason we have to have the spaces vs tabs argument.
In it, they make a really good argument that humans simply shouldn't be doing this type of formatting work. Let the computers do it, clang-format can get it right every time in a fraction of the time a human can.
Pick whatever style you want, let the computers deal with it. I quite like this, now I just write a big long single line, hit a button and have it fixed for me.
It's not a bad habit if it looks better and doesn't involve any time investment.
I've seen plenty of suboptimal code in review, commented about what I consider a better/more readable version to be, and gotten the response "this is what the clang formatter produces". Boo to automatic formatting. It produces the worst lowest-common-denomninator version of code.
Maybe no formatting characters should be allowed to be saved embedded in source code, and instead presentation filters should handle everything related to formatting, documentation, etc.
Git supports custom "clean/smudge" filters on push and pull exactly for this sort of things. Unfortunately neither github not gitlab consider them so your online diffs would look like a mess of you did that.
It looks interesting, but then one would have to define a normalization for the AST - either something like an XML printout of the AST, or a standard formatting for source code (perhaps whitespace-only minification?). It would also pose an issue when presenting code in "dumb" media (eg. a txt file).
I'm sure many know, but for those who don't, `diff` (and `git diff`) accept -w and -b to ignore all white space and changes in the amount of white space, respectively. I find these very handy.
Somewhat related, if you're looking at a diff on GitHub and want to ignore whitespace, you can just tack on `?w=1` to the URL (https://github.com/blog/967-github-secrets).
>It means constant readjustment and unnecessarily bloated diffs every time you change a function or variable name.
Your variable example is the thing that peeves me most about golang, since gofmt insists on aligning consecutive variable names and types in that columnar fashion.
> alignment vs indentation is the whole reason we have to have the spaces vs tabs argument.
Indeed, that is one of the things I like about the indentation-only style. Unlike column alignment, you can use either spaces or tabs for indentation and the formatting still comes out fine.
> I don't like this style either, but it's a style not a "bad habit."
Point well taken. But this was just a personal observation. If other people use column alignment, it would certainly be presumptuous of me to call it a "bad habit"!
For me, though, it was just that. I had no real reason for it other than having always done that way, and it was really starting to get in the way. So I was glad to be done with it.
On the one hand, I agree that the time of typewriters and their fonts is (or should be) long gone. On the other hand, something keeps telling me that program code is not (and should not be) exactly a piece of literature, and there may be some advantages to being able to see code as a two-dimensional object rather than linear text.
Block selection and anything having to do with IO formatting are very good reasons why monospaced fonts are still useful.
That being said the idea that a programmer being resistant to changing their font style is indicative of general intellectual laziness is one of the most laughable things I've ever heard. I'd be more convinced if someone told me that refusing to change syntax highlighting themes implied you're a bad programmer.
> ...the idea that a programmer being resistant to changing their font style is indicative of general intellectual laziness is one of the most laughable things I've ever heard.
Let me just mention that this isn't what I said at all. I don't blame you for misunderstanding, I must not have explained my thoughts clearly.
I didn't say anything about intellectual "laziness", and I certainly didn't mean that someone who didn't want to change their coding font was intellectually lazy.
I was talking about intellectual curiosity, specifically with reference to my former CEO who questioned the sanity of anyone who would code in a proportional font.
Instead of wondering why someone would make such a non-mainstream decision and being even slightly interested in their reasons for it, he simply dismissed it out of hand as the bad habit of a weirdo.
That's the lack of intellectual curiosity I was talking about.
Ironically, I'd disagree and say that your CEO was being intellectually lazy by explaining your preference for proportional font by the absurd declaration that anyone who does it is simply sophomoric or inexplicable.
However, I would not take this kind of instance of intellectual laziness to be indicative of a more general complacency when it comes to ideas, tools, or self-development more generally.
By contrast I think intellectual curiosity is a great thing when present and lamentable when not, but I don't think it's a prerequisite to be a good professional in almost any field, including programming related ones.
Sublime-text-style multiple cursor text manipulation would break here. And your code would look different than everyone else's machine. How would you display a guideline to make sure you were under a characters-per-line style?
What advantages are there? I could never see it working for me. I want a program to format my code with resonable defaults and be done with it.
> your code would look different than everyone else's machine.
Not if you use an indentation-only style like my second example. One of the great things about that style is that it looks the same on anyone's machine, whatever kind of font you use.
If you read some of my code, you'll never know that I wrote it in a proportional font. It looks the same if you view it in a monospaced font.
> How would you display a guideline to make sure you were under a characters-per-line style?
Most programmer's editors have more than one way to do that. There is usually a column number in the status line, and some editors can be configured to change the background color on any part of a line that exceeds your required line length. That works with any font, and it's visually less obtrusive than a red vertical line partway across your editor window.
Also, an indentation-only style naturally leads to much shorter line lengths. If you compare my two examples above, the column-aligned version extends to column 77, while the indented version only goes to column 40! That's barely half the line length for the same code.
In practice, I think a lot less about line length since I switched to the indentation-only style, since my lines of code tend to be so much shorter as a result. And I tend to write the simplest functions I can without excessive nesting, so it's pretty rare that I come close to any worries about line length.
> What advantages are there?
For a proportional font, I simply find it easier to read and nicer looking. And as I mentioned, it also helped teach me to use indentation instead of column alignment.
I'm not saying you or anyone should necessarily convert the the Proportional Church, only that it is a worthwhile exercise to try it for a while.
What proportional font do you use? I'd like to give coding in a proportional font a try but would like something designed for programming instead of just experimenting with Verdana.
Yeah, Verdana is not great. I used to use Georgia, but when I started doing more on OSX I found that it didn't render well in all apps - the character strokes were too skinny. It looked great in Windows though.
For the last couple of years have been using Trebuchet MS. It's not designed specifically for programming, but it has many of the attributes of a good coding font, in particular all of the easily confused characters like 0Oo and 1Il are easily distinguished.
The one thing I don't like about Trebuchet is that it has a really terrible tilde (~). Sometime I will sit down with a font editor and swap in a better tilde.
I tend to use largish fonts on a high-DPI display, and Trebuchet really looks nice with that setup, both on Windows and macOS.
Someone else recommended Input, which is designed for programming and comes in both proportional and monospaced variants. When I tried Input it didn't look as nice as Trebuchet MS to my eyes though.
How would multiple cursors be affected by this? I use a proportional typeface and multiple cursors for all sorts of things, I can't really see how these concepts are even related.
As you say, use automatic formatting and you don't need to worry about line-length. (Otoh, having a mandatory max line length makes about as much sense as having a max identifier length or a max lines per file.)
You can't drag a cursor down vertically and know what will happen, something I do surprisingly often because it is very powerful.
Line length guide lines makes sense for me as a visual indicator of what will wrap when I hit the max lines per file. They are also nice ways to gauge when you are nesting too deep or making overly complicated expressions.
Max line length allows you to do nice things with window management and diff tool layout and not spend forever moving around to see the text. I am a convert after thinking it didn't matter. Now it being 80 characters is arbitrary but so would almost any other number be.
Typically, when you do column selection, the lines are identical to the left of the cursor or you're selecting the end of the lines, which both still work in a proportional font.
Max column length (line length) does make sense in one case. It simplifies side-by-side comparison. We have a max 100 column rule which is perfect for our merge and review tooling :). It was raised from 80 few years back and probably raises again to 120 as everybody has all their monitors 1920x1080 now. The idea is everybody should see the entire line in one go without wrapping enabled.
A second reason is that it prevents nesting as a side effect. You are forced to make methods and don't go into nested if/for. Much easier to check for our (custom) linter than verifying for/if nested loop depth.
I use the proportional font "Input", which is designed for programming. I really enjoy it. The only annoyance is matching indentation in certain scenarios.
I would probably want to hit you with a baseball bat if I had to spend any time reading your code with my monospaced font. At least for the type of code that I work in that lends itself to code alignment.
> I would probably want to hit you with a baseball bat if I had to spend any time reading your code with my monospaced font.
Well, that's a good way to get a head start on the "hell or purgatory" thing, isn't it! :-)
I'm not saying every kind of code is suited for a proportional font. If you use ASCII art, or if you are writing out two-dimensional matrices or the like, a monospaced font will serve you better.
The kind of casual and unnecessary column alignment in my first example is what I was talking about. The second (indented) example is perfectly readable in either a monospaced or proportional font. So if you run across it you hopefully won't need your baseball bat.
I've been interested to try programming using proportional fonts for a while, but really like ligatures and don't want to do away with them (I'm using Hasklig at the moment.)
Does anyone have a recommendation? I'm having trouble finding anything at the moment.
Yup, that's a great example of where a monospaced font helps. I don't claim that proportional fonts are ideal for every kind of code, only that it's an educational experience to try them out, even if just for a while.
Your example is interesting because it combines two different kinds of alignment. One of them I find unhelpful - pushing everything to the right to match the length of the variable name. The other is the useful alignment within the matrix. So personally I would make this minor change:
Ditto for me. Going proportional made me consider using saner formatting policies rather than fancy ones. I've also narrowed my code column width by writing more vertically and less horizontally to make scanning easier on my eyes while also allowing for more side by side buffers.
There is another example of when mono spacing is useful; multiple calls to the same function with diffrent arguments.
But that's basically hardcoded tabular data, and should really be solved by an editor with proper tab-stops. Not by abusing the monospaceivity and spaces for alignment.
But that's basically hardcoded tabular data, and should really be solved by an editor with proper tab-stops. Not by abusing the monospaceivity and spaces for alignment.
That’s the crux of the issue for me.
I can think of many ways I’d like to present code in my idealised programming language(s) that would use significantly more advanced layout and typography than today’s typical environments.
However, I wouldn’t actually want to use any of them unless my programming tools all supported them properly. That means the editor, but also the source control and diff tools, the code review and bug tracking systems, and so on.
In the absence of any standard conventions for how to represent that extra metadata in an underlying format as robust and flexible as plain text, it’s hard to see this ever happening, though I imagine it would be fun to try.
I never used a proportional font while coding in my life and I always used the second way of indenting.
If this is the only advantage of the proportional fonts I guess that the mis-alignment disadvantage far, far outweighs it.
To each their own. Personally I dislike nested function calls in general and would use intermediate variables with descriptive names.
var calculatedOne = andthisCalculatedOne(anArgumentThatMeansSomething,
anotherWordyName);
myFunctionThatDoesStuff(someArgument, calculatedOne);
Edit: That "anotherWordyName" is supposed to be column justified, HN really needs <code> tags instead of this indentation nonsense.
The extra vertical space is easily worth the increase in readability IMO.
I've never touched proportional formatted code beyond a day or two when I was forced to by my environment, and all I encountered was more annoyances in getting my code to align properly. I'm glad you found some benefit, but I'd argue those benefits could be achieved any number of other ways.
> Personally I dislike nested function calls in general and would use intermediate variables with descriptive names.
Oh, I agree completely that step-by-step is often more readable than deep nesting.
OTOH, your example is a good illustration of the problems with column indentation. If it hadn't been HN's goofy code formatting that messed you up, it would have been some code refactoring that changed the length of one of those variable or function names.
I know, and I apologize for hinting that you of all people may have lacked intellectual curiosity! That comment was really directed toward the former CEO of mine... :-)
Actually I'm glad you put in that little joshing swipe against us proportionalites, as it gave me an excuse to have some fun exploring the topic.
I really wonder why, because alignment is one of the core things in lisp code style. Take this trivial snippet:
(let ((foo 1)
(bar 2))
(print foo)
(print bar))
The (print ...) statements should just be indented two spaces, so you don't need a monospaced font for that, but the bindings should be aligned... "(let (" in a proportional font generally won't have the same width as 6 spaces.
Why did you format the code snippets in your comment in a monospace font?
Also, I'm curious. I want to see how the code looks like. I want to know what are the downsides of monospace and the benefits of proportional. The one you cited isn't too much of a deal, since it is just a habit you can create using monospace still.
> Why did you format the code snippets in your comment in a monospace font?
Because I don't know of a way to get HN to format text in a proportional font without losing the line breaks. Believe me, I've tried. :-)
> Also, I'm curious. I want to see how the code looks like.
I am glad you are curious about it!
> I want to know what are the downsides of monospace and the benefits of proportional. The one you cited isn't too much of a deal, since it is just a habit you can create using monospace still.
Indeed, and now that you mention it, I'm not entirely sure which happened first. I may have switched to the second style with indentation instead of column alignment before I started using a proportional font, just because I was tired of the excessive line lengths and always having to fiddle with the spaces.
Regarding the downsides and benefits, will it sound like a cop-out if I say it's just something you have to try for yourself?
Part of my preference for proportional fonts isn't even tied to any rational reasons. I spend much of my day looking at code, and I just find proportional fonts easier to read, more beautiful and pleasant to look at. But beauty, of course, is in the eye of the beholder.
Unicode has some wonky characters - I use zero-width space, probably the most ridiculous of them to bypass filters at times. For intentionally wide spaces you have a few options:
Test unicode non-breaking space.
Test unicode narrow no break space.
Test unicode figure space.
EDIT: So there you have it, if you want a non-breaking space on hackernews, use unicode's figure space or narrow non-breaking space. Apparently they already filter out the normal non-breaking space.
Nah, you can do it on Reddit because they use Markdown instead of HN's homegrown comment formatter. In case you ever need to post a proportional font code sample over there, the trick is to use for all the leading spaces, and also add two regular spaces at the end of each line before the last one.
I like switching fonts every couple of years just to keep it fresh.
My font right now is Iosevka: https://be5invis.github.io/Iosevka/ A font generated from its source code. You can build your own variant. It has ligatures as well.
I like that it’s not as wide as many other monospace fonts.
My problem with Iosevka (and Input and others like them) is that the [x-height][0] is too large, ie the bottom-half parts are too tall compared to the top-half and uppercase letters. Especially in less-wide weights, it feels muddy and hard to distinguish.
Seconded. I swore by Inconsolata for the better part of a decade but within days of installing Iosevka I had it set up in every editor or terminal on all of my computers. And it supports programming ligatures!
I love Iosevka Term! My only issue with it is that there seems to be a problem in Emacs 25 that makes the screen flicker once in a while when I use it. For Emacs, I like to use Fantasque Sans Mono, another amazing font.
I've rifled through many a programming font, bought Pragmata Pro at one point (as you can see I also like taller fonts), tried many others over the years (Monoid was my previous favorite ligatured font). Iosevka is my current favorite. My customization args are part of my dotfiles repo so I can install it exactly how I like on any new system without effort.
This is a deeply personal choice, I feel. I am not a fan of using ligatures in programming code as it gives some abiguity around how many characters are in a given ligature.
I think you're maybe confusing monospace ligatures with something else (though I'm not sure what.) In all of these programming ligature fonts, it's quite apparent how many characters a given ligature is composed of, because a ligature still consumes the horizontal width of the characters it's composed of.
Look at the "!=" ligature in the Fira Code example: it's a ≠, but it clearly takes up 2em of width.
the issue is that some of the ligatures, especially the arrows, aren't as heavily towards the "clearly". I have difficulty telling the 2 character vs 3 character ones apart.
My thoughts exactly. Aesthetically, I love these ligature fonts, and I think it's great if people are using these and enjoying them. But I just know that, if I used one of these fonts, I'd have to mentally convert the ligatures back into the real characters. It would use up brainspace that would be better spent on actually writing code.
The issue, at least for me, isn't that it makes it impossible to figure out how many characters a ligature is (since, as you noted, it doesn't), but that it adds some ambiguity, especially when taking a quick glance. Ambiguity can slow down parsing (in the brain) and potentially lead to errors (in the code) if I mistakenly think a ligature is a single character.
For instance, in the examples from the article, the == and -> ligatures in particular look like something I might not always see as two characters.
> I frankly can't understand how tiny font people can function. It gives me a headache to even consider programming at anything less than 14 to 16pt and I am usually around 20pt.
What? I can't understand how such large font people can function. I mean, how large (or dense) are your screens? Is that a Macbook thing?
I'm at... something small. Hard to tell exactly, because on my laptop screen, all following fonts look pretty much the same size, while having different configured values:
- IntelliJ - Monospaced, size 12
- Emacs - (:family "Hack" :foundry "unknown" :slant normal :weight normal :height 76 :width normal)
So 8 / 12pt (which one is pt?) and/or 76 somethings. People at work say I'm crazy working with such small text, but frankly, anything larger for me feels like wasting tons of vertical space, which is of short supply given the (IMO completely idiotic) market standardization on 16:9 and 16:10 displays.
What are you going to do when you get older and your eyes go through "the change"? You can keep your font sizes and wear readers, but then don't you have to move your head a lot to view the entire magnified image?
Any presbyopic developers care to chime in on what the experience is like? I'm 40, so mine could cross over any time now.
I hate 16:9 too. Please give me back the bottom of my screen that you chopped off.
I'm 50 and have been wearing glasses for about 6 years now.
Your neurology adjusts pretty quickly. The first few days, your field of view feels limited. After that it feels normal. It was a delight to adjust my font sizes down on all my devices, back to what I would have used at 30 years old.
You could try rotating your screen to get 9:16, although I find that it tends to be a bit narrow if you want to split vertically and have two pieces of code side by side.
With 16:10 screens however I think it work rather well, I currently use three 1920x1200 monitors and two of them are vertical, it looks like this: https://svkt.org/~simias/emacs-vertical.png
I spent some years with dual 24" 10:16 screens. It was a convenient coding and documentation reading environment. If the workstation had supported a third screen, I would've requested one to run horizontally, for the rare times I had to view video, or something.
Given differences in monitor pixel densities, OS zoom levels, and distance from eyes to monitor, comparing any point/em/etc measure is practically worthless.
For example, I can use a 12pt font on my macbook pro's screen, but have to go up to 16pt on my 4k display at home, and down to 9 or 10pt on the 1920x1024 screens in the office. It's a pain, but... <shrug>
Instead, if you really want to compare font sizes, compare either the height relative to the window, or actual size on a ruler held at arms length while at normal viewing distance. That way you can measure the arc-height of the font - something that translates much better with such a wide variance in displays.
My fonts, corrected for device, all end up being around 1/8" ( tall (for capital letters) on a stick held at arms length.
I don't have a ruler handy, so here are two random screenshots I just made, showing terminal and Emacs font sizes I use, relative to my 1920x1080 laptop screen:
Sized to fill my screen, it's about the same font size as my own. Maybe one point size (probably less than 1/32") smaller. The only major difference is that my fonts are smoothed by the higher resolution.
> Given differences in monitor pixel densities, OS zoom levels, and distance from eyes to monitor, comparing any point/em/etc measure is practically worthless.
That’s... false.
With correct DPI settings – determined by measuring – the same font size equals exactly the same physical size.
This is my solution at work; I love it. The only caveat is that some font smoothing doesn't work as well on rotated monitors, since the pixels are no longer arranged as expected. Of course, with 4k monitors, it's a non issue (not that I can even realistically drive 2x 4k monitors on my MBP.
I have a 1080p 15" screen. I've configured my browser with a minimum font size of 18px as smaller text is hard enough to read, especially in the web pages suffering from the war on contrast. Because I sync my configs, also use them on my 21" 1080p displays on my desktop, but I could probably go smaller there.
That said, I turned off the OS scaling on Windows because apps that didn't support it got scaled by image scaling which resulted in unpleasant blurry messes. As for Linux, I don't think XFCE supports it at all.
On my work rMBP I also use 16px min, even with the OS scaling turned on.
When I was a teenager I used to use 10px fonts, but I tend to use displays at more ergonomic distances these days.
Apparently I'm one of the two users of proportionality spaced fonts for coding. I've used this now for five years and I don't understand why developers still see this need to code as if monospaced terminals is all that's available. Especially on large screens with high dpi it reads much faster. It also makes it less awkward to use editor unicode substitution for display purposes.
If like me you really like aligning your code proportional fonts are not exactly pleasant to use. I sometimes go out of my way (within reason) to have variables with the same number of letters so that I can align them nicely. A bane of my existence is that "width" and "height" don't have the same number of letters.
An example from some lua code I'm working on at the moment:
local hi = buffer:bitfield(4, 4)
local lo = buffer:bitfield(12, 4)
return bit32.bor(bit32.lshift(hi, 4), lo)
I find that aligning things not only looks better but also makes the differences more obvious. Same code with a proportional font:
local hi = buffer:bitfield(4, 4)
local lo = buffer:bitfield(12, 4)
return bit32.bor(bit32.lshift(hi, 4), lo)
It's not a deal breaker (and the offset is small in this case) but I much prefer the monospaced version. Obviously it might also be "Stockholm syndrome" after decades of coding with a monospaced font, I can't say I've really given proportional fonts their chance.
Also many proportional fonts make it hard to distinguish between Il1 or O0, but I guess you could design a proportional font that doesn't have this issue. What font do you use yourself?
I'm normally using Optima when working on Retina displays (because of serif typeface). Screenshot [1] of some old project for solving Project Euler problems (no solutions can be found in the screenshot).
The Il1 problem is primarily a problem with sans-serif fonts. In my work SmallTalk text is set in Arial in the default image, but I've set up my development image to use Cambria instead which is really quite nice.
The inability to do vertical alignment outside of the left edge of the line is a bit annoying, but honestly I don't miss it that much. If you have enough code that you really, really need to do that, I find it's a code smell indicating that something likely needs to be broken into smaller pieces anyways.
After programming in SmallTalk for a while, I'm starting to come round to a similar point of view. I haven't quite made the leap in my day-to-day work yet, but I really am considering it.
Another thing I'm considering to adopt from ST is dropping syntax highlighting. If research on highlighting for natural language can be transferred to code (I'm not entirely sure, but I suspect it might), highlighting might actually be harmful to comprehension. The only thing I'd keep is a slightly lighter colour for comments, as these don't have quite the same status as code. Ideally, I think I'd like to have them deemphasised by moving them off to the margin or something like that, but that requires rather more work than rendering them a lighter colour than the rest of the code.
> If research on highlighting for natural language can be transferred to code (I'm not entirely sure, but I suspect it might), highlighting might actually be harmful to comprehension.
Interesting. Could you share some of that research and its conclusions?
I don't remember whose research it is (it's a bit removed from my field of expertise =), but the gist of it is that they tried to highlight different parts of speech in running text in different colours, and showed that it actually decreased reading speed and comprehension.
Of course, there are several possible error sources (unfamiliarity with the colouring scheme for example), and whether this can be transferred to reading code is an open question. But I still think it's important to keep the existence of this kind of research in mind when discussing this kind of question (and also the similar question of mouse-driven interfaces vs. keyboard shortcuts), as it easily devolves into strongly held opinions and arguments along the lines of "it stands to reason that $opinion-held-is-true"
I've always considered those kinds of studies suspect. When I'm reading, human-language text, I spend most of the time going forward. Maybe I'll skip to an earlier part of the sentence if it turns out to be a garden-path parsing, or to a previous sentence to re-acquaint myself with context. Those are exceptional cases.
In code, I'm frequently tracing back and forth through a block, looking for specific information in different lines. I think that the coloration helps to provide "landmarks" for non-linear traversal of the code. I'd consider color-free code to be more similar to un-punctuated text, than I would consider colored text to be to colored code.
> Ideally, I think I'd like to have [comments] deemphasised by moving them off to the margin or something like that
This is one reason I'm a fan of Douglas Crockford's slightly unorthodox style of always beginning comments in column 0, rather than indenting them along with the code. This helps, to a small extent, in differentiating comments from code. Example: https://github.com/douglascrockford/JSLint/blob/master/jslin...
I've dabbled with it and enjoyed it, but I really feel like it needs editor support to feel truly fluent (i.e. being able to preview the formatted version on the fly, being able to collapse the text blocks, etc.).
Ideally, I'd prefer to float them to the right margin (suggesting the Lisp style of line comments starting at column 78 or thereabouts, I guess), but this is an acceptable compromise. At first blush it seems to break the flow of the code a bit too much, but I'd probably get used to it reasonably quickly, especially in conjunction with grey comments and black text.
Reading code isn't the same as normal book or news reading. You don't need to actually read the whole code. Most of the time we looking for a specific variable or function call. Syntax highlighting allows you to filter out everything that's the wrong color to find what you're looking for faster.
I've tried to look at code without highlighting and I can't read it because the color gives me additional context (metadata?) about the code.
I'm profoundly more productive when syntax highlighting is enabled. It's easier for my brain to focus on the details it needs at any given point, versus when it's all the same color
I'm sympatheic to Smalltalk's approach to highlighting, but as long as we're all editing text files that contain multiple classes / functions / methods / etc... colorizing a few tokens (like class/func/let) is still valuable.
Every time I've tried using a proportional font, my mind doesn't want to see it as code. I can force it, but that gets uncomfortable, so I switch back after a short time. Even if I take the time to adapt, that means switching fonts in all my dev environments (between home and work, 7 OSes, 1-4 editors used in each). And a lot of my hobby code is data format conversion, emulation, etc, so I'd need to find a nice way to format the data tables.
There's a good-sized category of things that have a bit of an adoption cost that I'm assured is worthwhile, but that I don't see a really solid reason to commit to. Proportional fonts is one of those (for me).
Personally I use input[0] which is easy to customize before download. If you aren't using a terminal-based editor, I really don't see the point in monospaced fonts either. I've never had an issue distinguishing differences because of the font style.
I also prefer proportional fonts, but some people's "ASCII artsy" programming styles, along with editors themselves, make it hard to use readable fonts in practice.
What I would like is a language-aware editor that can visually align assignments, parameters, etc. without touching the actual whitespace characters. You get 1 tab for indentation (if the language allows tabs) and 1 space for alignment, and the editor takes care of the rest. The raw text would still be readable enough and use fewer bytes for people who prefer to code in a monospace terminal over SSH over an acoustic coupler from a phone booth in rural Texas.
It isn't quite what you asked for -- doing this automatically would be really neat -- but the best solution I've seen is called Elastic Tabstops. http://nickgravgaard.com/elastic-tabstops/
I really, really wish this was available in the editor I fight with every day.
It could be a function of the kind of programming you engage in.
When I write code that reads more like long-prose, then I do prefer proportionally-spaced fonts myself. This is generally characterized as code with a low density of variables and constants, and lots of control and data structure manipulation. However, when I write code with lots of objects, I tend to prefer monospaced fonts. This is because my personal aesthetic style is to line up groups of related entities and logic; an IDE that gives a modern example of doing this is Eclipse [1].
For IDEs I have to use for a specific project that don't support such formatting, Emacs makes this easy to re-flow so adding a new variable, shortening or lengthening an existing one is still quick. The impact upon version control is still annoying, though; AST-sensitive merge/diff/version-control can't arrive soon enough for me. Fortunately, my code is not regularly inflicted upon others within a team; when I do have to work within a team, I put up with not carrying out my personal preference and use the code formatter that comes closest to the team's formatting standards before checking in.
I do this because it helps me read my own source code quicker. Blocks of entities and logic related by domain and not intrinsically related through the language itself happen to be easier for me to read when I line up like this.
This all goes back to a phase I went through a long time ago when I tried to figure out how to adopt literate programming in all my own work, within the context of an integrated single-source publishing, version control, testing, training, and problem management environment. In my mind's eye, I imagined all the media and activities surrounding a software product related back to the code in some manner, with the code displayable in different contexts based upon the AST and domain-specific hints, and when I made a change in either, I could see and manage the change in the network of related nodes. So if I change how a GUI behaved, then the parts of the User Guide that reference the old GUI, list of users who logged problems documenting confusion about that part of the GUI, etc. would all be automatically flagged. The User Guide would automatically get updated graphics content available from the GUI testing as soon as the testing data was built, the training material as well, and the users would get a note from the support team when the next version was released, detailing the change. I eventually decided that mountain was one I wasn't going to grind down myself anytime soon, so my code formatting is one of the many small ways I preserve that ideal.
Thanks for this interesting write-up on AST-based editors. Smalltalk has some of these ideas, and you might want to have a look at TexMacs (even though the project is abandoned). Like you, I feel that linear text-based editors are severely holding us back in communicating our intentions and inventions. I've had very similar ideas myself and even worked shortly on a Lisp which recursively forms an editor for itself (using a meta-object protocol).
I love Firacode and use it in Android Studio/IntelliJ but it has this bug[0] where "=" is invisible in Gnome terminal. So, I had to switch to Fira Mono[1], the parent of Fira Code, from Mozilla. Fira Mono doesn't have cool ligatures but it's a good font and works pretty well.
Use them for a bit before judging it, don't forget that you've trained yourself to read some character combinations as meaningful.
After using Fira Code for a while, I can say code looks weird without it. Especially plain === and => look really jarring now. The ligatures also help me spot typos!
Regardless of the ligatures, one of the cooler things about Monoid is how it tries to fix kerning problems inherent to monospace fonts:
I'd like to use it, but they turn custom operators such as "|>|" into an illegible jumble of characters (in this case, "▷|"). If I'd wanted my operator to be "▷|", I'd have defined it that way.
Now, if they can come up with a way to selectively turn the ligatures off and on, I'll give it another go. Until then, I'm perfectly happy to see the occasional "<=" or something.
Also, that "www" ligature is the stuff of nightmares. Never, ever, with I use that on my computer.
It transforms them from individual characters being put together to approximate symbols into the actual symbols. The act of joining together particular character combinations into more aesthetically pleasing forms is common and very old practice.
It looks odd only because we're accustomed to seeing the individual characters due to display limitations inherited from typewriters and TTY machines.
The www is a bit artsy for my tastes as well, at least in a programming sense, but making a ligature of www isn't a terrible thing, IMO. It already almost creates its own ligature, especially when used with a serif font.
Heck, a lot of people I know will make a verbal ligature of www - something like 'dub dub dub'.
www was unnerving to me (and a couple of my team members) too.
In a way I am interested in psychological basis for my innate rejection of this. Conceptually, I comprehend why it is made into it's own ligature, like !=, it is a unit of information these days.
Well, for starters it's an abbreviation, whereas -> or != is an approximation of a symbol, so that makes it different from the rest. Also, you're on a website that has no www in any part of its website, so it's not nearly as ubiquitous.
If anything I think it makes more sense to have :// as a ligature.
> The act of joining together particular character combinations into more aesthetically pleasing forms is common and very old practice.
Yep, the ampersand symbol "&" originated as a ligature for et, Latin for "and". You can see this more obviously in italic families and some fonts expose a more fancier variant as well. Example: http://i.imgur.com/Rsmmql9.jpg.
I assume potential sarcasm would be related to the difficulty differentiating between similar symbols, based on length, with different lexicographic meanings.
For example, dash vs endash vs emdash, etc:
‒ – — ―
If those symbols were used in a programming language and had different meanings, differentiating quickly could be much more difficult than seeing the difference between -, --, ---, and so on at a glance.
But the point of the new triple-equals ligatures is that they're no longer only differentiated by length; they have three bars instead of two, as well.
> the difficulty differentiating between similar symbols, based on length, with different lexicographic meanings.
The very thing amk_ is praising is that this issue is fixed in both Fira and Monoid by the triple-equal being not just longer but represented using 3 horizontal bars rather than just 2.
One thing that really annoyed me in some monospaced fonts with ligatures is the [] ligature, I never understood why would someone rather see a box instead of two brackets. I'm no typographer, but I think that it makes the text lose its uniformity, because [] and [0] will look weird close to each other.
I guess I'm not alone in this, because in the Fira Code repo there's this commit from 2 months ago: "Remove [] ligature from specimen".
Tiny font person reporting in. I can easily read 9pt font scaled to 80% or 90% in Qt Creator on my 4k monitor. Some of my other coworkers are unsure if I even have text on my screen. I do it because I can fit 4 split views of 120 columns text on my screen (at 90%, 5 at 80%).
Right now I only have 3 split views, Unit tests, the header and the source file I am working on.That window does not take up the full screen and I have plenty of space for a build VM another text editor for scripts and notes, a file manager and a few consoles.
At the same time, I'm amazed that we, developers of all people, still use mostly software from the 80's. At least conceptually, if not actual code.
I mean, our tools can be as awesome as we want them to be. An illustrator is at the mercy of others to improve his daily software. We're not.
And yet, we get all fired up when we are able to display thousands of colors, some pseudo GUI feature like menus or divisors by patching fonts or have text appear at the opposite end of the line simultaneously. Madness right? I know.
I'm as guilty as the next guy, my editor is Vim (on the terminal) and I spend ridiculous amounts of time tweaking tmux, bash/zsh and fetishizing over color schemes.
I can't help but feel that by now we should have an OpenGL rendered environment where something like SublimeText's minimap would be easy and Hollywood style interfaces possible, albeit excessive.
I happen to like them, but the only one I'd put forth as a definite improvement is that JS/PHP's triple-equal === operator gets turned into three horizontal lines that take up more vertical space than the double-equal does. That can be the cause of subtle bugs, so I think making that distinction more obvious is a win.
Personally, I'd probably find it easier to visually mix up the two-line and three-line versions than to mix up the two-char and three-char versions when skimming code - but to each their own.
Honeslty, this should be handled by the language itself. If a language supports unicode, why not support ≠ for not-equals instead of "!="? Then provide a pre-processor that will replace all your ugly "!=" with the correct mathematical symbol.
I love the way Perl 6 looks with Unicode, it's really beautiful, but I'm just not very comfortable typing Unicode. It takes me a split second to type ">>*<<", but much longer to type the Unicode equivalent (and I probably have to look it up). The editor could probably do it for me, but I haven't looked too deeply into how.
I think doing it with the font might actually be nicer from a usability perspective. Unicode is fun to play with but slows me way down.
perltidy for Perl 6, perhaps, should offer it as an option. It'd only show up after you saved your code (or checked it in, or built it...I usually run perltidy on my Perl 5 code in my dist.ini, so it only happens during a dzil build).
One of the golang plugin bundles for Atom runs gofmt on every file on save which is actually pretty neat. I've been tempted to do the same for all of the languages I use. It sort of habituates me to do the right thing over time, as I see the changes happen immediately and I'm always working with a file that is mostly in the "right" style.
Well, providing the replacement engine as part of the language compiler package as a simple command-line tool you can hook into your editor of choice as a hotkey so I can say "replace all the operators in this file with their appropriate mathematical unicode counterpart".
This is what e.g. many Haskell developers do, the issue is that this will usually fuck up alignment (because the base font does not contain the non-ascii symbols) and generate different alignments between different viewing contexts. It also leads to odd issues where deleting a character just changes it and doesn't move the cursor at all.
Ligatures are a time-honored way to improve the look and feel of combinations of characters, that's basically the entire point of them.
I am a huge, huge fan of the free font “Input”[1]. Just love how customizable it is, so much so, that I’ve replaced Pragmata Pro with Input on Sublime.
The www was a little weird to look at for me too, but it's the combinations of multiple "-" and "=" that pushed this over into "nope" territory for me.
It's cool that some folks find it better, but it's just not for me
I really like the ligatures in Iosevka ligatures when working with Javascript, especially with `=>` (which it turns into a fat arrow). It's not really that significant, but it's a nicety that enjoy.
Oh, I didn't even know ligatures is a thing. Learned something.
When coding in Haskell, I used to use the vim-haskellConcealPlus [1] plugin for vim to swap chars being display into nicer unicode chars for various operations.
I'm no longer using it now because it wasn't monospaced and moving around lines was jarring.
If only there's a way to combine the benefits of the two. Monospaced font with ligatures seems to only work for operators that take the same amount of space as their ligature counterpart.
I really want someone to come out with a proportional font with programming-oriented ligatures; they make more sense with a proportional font because unusual "widths" are no longer a concern. I've foresworn monospaced fonts, but really like what they did in hasklig. I can get the same effect if I do my own editor (replace => with unicode ⇒), but not with an off the shelf editor.
I tried to figure out how to hack open sans to do this, but the tool chain and steps needed to modify a font aren't well documented as far as I can tell.
Really looking forward to having this capability in Sublime Text. I really love Fira Code. It looks great in Emacs for Clojure development and is right at home with my powerline-esque ZSH theme.
I think Scott updated the sample used for the screenshots after putting it in the post.
The code is listed as:
// FIRA CODE
object o;
if (o is int i || (o is string s &&
int.TryParse(s, out i)) { /* use i */ }
var x = 0xABCDEF;
-> --> ==> != === !== && ||<=<
</><tag> http://www.hanselman.com
<=><!-- HTML Comment -->
i++; #### ***
I think what was actually used is:
// FIRA CODE
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789!@#$%^&*()_+={}[]<>/?'";:~`
object o;
if (o is int i || (o is string s &&
int.TryParse(s, out i)) { /* use i */ }
var x = 0xAB_DE_F;
-> --> ==> != === !== && ||<=<
</><tag> http://www.hanselman.com
<=><!-- HTML Comment -->
i++; #### ***
The underscores in the hex literal are not part of the font, which looks like it is confusing some people.
I wrote a section on C# 7 for a new chapter in the upcoming second edition of my book from last year. There are loads of useful new features in C# 7 (and 6 if you're still on 5) and I thought I recognised those snippets.
I tried some of these fonts in Visual Studio and quickly learned that any ligature that contains a hyphen (e.g. "->") doesn't work, due to a limitation in the Windows Presentation Framework. :(
One of the things I love about DejaVu Sans Mono is that it has a human-designed oblique version and doesn't rely on my editor to automatically distort the font. I'd love to try Fira Code, but what do the ligatures look like auto-slanted?
(Oblique and italic are both slanted styles of font; the difference is that a true italic has some cursive features and an oblique does not.)
Yeah. The thing that blows my mind is that the guy who runs Input Club (they make/design keyboards with open-source firmwares) sent the USB consortium an email a year or so ago asking if there were any plans to update the USB HID spec for unicode, and the response indicated that he was the first person to ask! Really?!? Unicode was out for a few years before USB even existed, and nobody'd even thought about it before? You'd think at least the word processor industry (which wasn't nearly as homogenous back then) would've jumped on it.
For those of us who use programmable keyboards, it's not a problem at all.
For everyone else, perhaps it should be seen as an editor problem? There's no reason vim can't see that you type != or =/= and replace it on the fly with ≠.
I personally love hasklig. Iterm2 has it on the Mac, but I'm sol on Ubuntu.
Is there any good terminal app that supports ligatures? I tried konsole, but the font looked like it wasn't getting any anti-aliasing and was harder to read as a result.
I love terminator, but it doesn't support ligatures.
This is sort of off topic but every time I see a new font on anywhere I just try it out . At this point I think the fonts that I prefer are probably a set where they all fall into a global maxima of my utility .
I figured I'd leave this here: I rebuild Iosevka with the Haskell ligature mode on default. I use this for a lot of things (although recently it's gotten no use as I've been working in Emacs).
Since it's a bit of a process to rebuild Iosevka, I just bundled the artifacts: https://goo.gl/gsFm8P
(Please excuse the redirection, this got a LOT of downloads and I have a big azure credit so I hosted it there and youw ould not believe what a pain it is to host simple linkable files on Azure).
This replaces -> and whatnot with unicode equivalents, right?
There are a LOT of problems with that. First and foremost you really do want double character width for these symbols in the iosevka format. Stuff like → is microscopic.
it also seems to adjust the spacing, I have used it with FiraCode and it seems to work correctly. Note my main font is DejaVu Sans, with this I just use the Fira Code symbols for the "ligatures"
While I've had people say I'm crazy, I don't think I could ever give up my current font I've been using for years now: https://github.com/belluzj/fantasque-sans . It's both readable and fun. Keeps me extra happy throughout the day. :)
Ligatures are great, but I just love the cursive italics used by Operator Mono. Haven't justified the price to myself yet, but am considering it since I haven't been able to find any other fonts that do cursive italics.
I tried it and instantly switched all of my editors and terminals over - it's clear, legible at different sizes, and the monospace script "italics" are great for variable names, comments etc.
As the very article notes, Hasklig is a fork of Source Code Pro with programmatic ligatures. In much the way Fira Code is a ligatured version of Fira Mono.
Sorry, the missing C is just me being sloppy. The underscores are a C#7ism where you they are ignored and people can use them to separate LONG hex literals.
I noticed that immediately, too; I just assumed the author changed the source before taking screenshots and forgot to update it on site code. If a font was doing that, it would be criminal.
For some people this might be great but for me this is a total sensorial overload, I tried to use some of these fonts in the past and I just loose track of the code.
Did anyone experience the same in the begging and grew to actually like these fonts or was it always a "love at first sight" experience for you that use them?
There was definitely a lot of "whoa!" and distraction in the beginning, especially while typing and watching things transform.
Later I loaded up some JS code I was working in earlier but without ligatures as the terminal I was using didn't support them. It definitely felt oddly verbose, especially the arrow functions.
I can still go either way, but it's mostly lack of ligature support that keeps from adopting it wholesale. Changing one way or another is a tad disruptive.
It slightly alters the monospacing which would drive me batty when coding, but cool idea. Especially for displaying code like in a blog post or other non-interactive use.
In my experience using Fira Code with VS, VS Code, and Konsole, the monospacing isn't a problem. The ligatures are designed so that they fill up the same width as the original characters.
My opinion might be biased by a heavy math background, but I like that e.g. "less than or equal" now looks the same as the way I write it on paper, and I don't find myself spending any time thinking about what that symbol means.
I'll concede that it totally messes up command line help text in the console, though. You get lots of stuff like --parameter=<value> turned into —parameter≤value> but it hasn't annoyed me enough to switch back yet.
In the GIF, you can see the other characters earlier in the ligature shifting around when a character is added or removed to complete or undo the ligature. That would just bother me.
Ah, that's fair. It is a little bit of visual noise, maybe roughly equivalent to the blinking of matching parens or braces as you move your cursor around.
I think the slight improvement in visual clarity when reading the ligatures makes up for the slight noise when writing them, but it's definitely a personal preference.
Well, depending on your audience I think it would be a step backward for static display of code since in some cases it isn't clear what to actually type. Fine for experienced audiences but really frustrating for anyone learning.
For example, the 'x' in the hex value. Is it a regular 'x' or another character? How about those fat arrows? How are those typed?
If you don't use one of those fonts that support ligatures, you'll see the plain ascii characters. You shouldn't use these fonts if you don't know what kinds of ligatures it supports or how it converts plain ascii characters into a higher form.
The edges of the WWW symbol need to align with the old symbol if they are doing it right.
The && also breaks out of alignment. Alignment is the whole reason I am using mono-spaced fonts.
My history:
IBM VGA (strange j, h, k, etc.),
Courier,
Bitstream Vera Sans,
Lucida Sans Italics (only proportional font, but it looked great at the time),
Consolas,
Kids Play.
I guess I'm destined for hell or purgatory then.
Hanselman is not alone. I had the CEO of one company look over my shoulder and ask, "Mike, I don't understand how you can program in a proportional font. How can that possibly work?"
He wasn't interested in the answer, he just wanted to make a point to me and our teammates that what I was doing was weird and wrong.
I would hope for people to have more intellectual curiosity than this. One of the best ways to learn is to let your assumptions be challenged: talk with people who do something differently from you and find out why they do it.
It's been said that a programmer should learn a new programming language every year or so, and especially learn a new kind of language that will teach you different ways to think about code.
Similarly, I think every programmer should try coding in a proportional font, at least for a while. It may show you new ways to think about how you format your code, as it did for me when I got curious many years ago and tried it.
For example, it cured the bad habit I had of lining up too many things in columns, like this:
Obviously that won't work in a proportional font, so it forced me to try this instead: This indentation-only style has many advantages, and of course it works just fine in a monospaced font too. In fact the Rust/Servo team recently switched to it from their former column-aligned style.