My favourite monospaced font is Triplicate <https://practicaltypography.com/triplicate.html>: the only true serif monospace that I know of (though I have a vague feeling I found one other at some point). Every other serif monospace I know of is a slab serif. Triplicate’s variable stroke thickness is also exceedingly rare in monospaced fonts; almost everyone goes for uniform stroke thickness, as is customary with sans-serif fonts but anathema for true serif fonts (though slab serifs could be either). Variable stroke thickness can be a bit iffy on low-resolution displays, but so long as you keep the size up or use a high-resolution display, I find it very pleasant. I’ve been using Triplicate everywhere for the last few years, including on my website.
(Also note on that page, since people are talking about ligatures a lot in this thread: “No, there are no programming ligatures in Triplicate, and there never will be.” with a link to https://practicaltypography.com/ligatures-in-programming-fon..., which can be distilled to the quote “ligatures in programming fonts are a terrible idea”. I agree.)
Pragmata Pro and Operator are two other well-regarded and popular commercial monospaced fonts that are missing from this list.
Triplicate has a nice look, but l (lowercase L) and 1 (one) are indistinguishable, which is an immediate non-starter for me in a programming font. (CORRECTION: there is apparently a code version that disambiguates these and others. See comments. That means this probably would be a candidate font for me, except:)
I finally just paid for Pragmata Pro, and haven't regretted it. The unicode support is incomparable, and for someone who lives in emacs and console, support for things like the Powerline glyphs and the option to use Emacs' prettify-symbols mode means an awesome user experience.
I actually like ligatures when reading code, less so when writing. The thing I like about prettify-symbols and a font like pragmata pro is that I can toggle between strict representation and a cleaned up version with things like the below replacements:
PragmataPro compromises readability across the board - here is why: It is compressed/condensed to allow for shorter line widths but legibility suffers.
Put up 2 exactly same code snippets side by side. One in PragmataPro and one with SF Mono (or Consolas, etc.).
I purchased PragmataPro but regret it. Now I use it on Mechanical Drawing dimensions :) It is fantastic in CAD.
I actually like the reduced width because of the way I arrange edit panes, and after a brief adjustment period, have no readability issues at the font sizes I typically use. That's a personal taste thing, though, so I can see that others wouldn't like it. The 'm' glyph is a useful bellwether/canary in that it becomes difficult to distinguish the legs before most other glyphs become problematic. I tend to adjust the font size to one level above where the m's start turning into bricks, and have no readability issues, and still ample horizontal space. I don't generally use the font for publication to others (although I'm experimenting with its use in code blocks). I do often use it in projecting demonstrations to students, although that's typically at a large font size, when the legibility isn't much of an issue, but the narrowness is an asset.
Which weight of Pragmata Pro did you purchase and use for emacs? Just wondering if I should get all of the weights which is super pricey or I only need Essential PragmataPro Regular/Bold.
I got the full version, but the nature of my job means I can claim a significant part of the cost against my PD funds (It's mostly for books, but I already own more unread technical books than I can complete within my expected lifespan. Thankfully they opened it up to allow software.) I think just the essential would be plenty for the majority of users.
Personally, my eyes and brain just can't scan ligatures in code efficiently, I have to double read the code, especially "is that =, ==, or ===? Oh, and that's !=="
(edit) I'll additionally qualify my comment, from a mathematics background I can casually scan a handwritten "!=" which is the same as the ligature, but I just cannot retrain my adult brain to accept the ligature version which is the same as the handwritten one. Brain plasticity I suppose.
Seconded. I get it for math but, it's just super confusing in code. Like, most of us agree "there should be one obvious way to do it" in code. Why don't we think the same about what code looks like? That feels much more fundamental.
I find some ligatures help a lot. I can often miss != but won't miss ≠ or ≢
I think the whole idea of pre-pending ! to negate is a poor idea in general, it's too hard to spot especially in long convoluted lines where it's just thrown in before a complex bracketed expression.
I sometimes use a triple negation !!! for that reason. I don‘t know if there are any drawbacks, especially if there are other people working on the code, but it worked pretty well for me so far.
Yes, it's one of those dirty JavaScript tricks that abuse type conversion. Negation converts anything into a boolean, so if you negate that again, you get the equivalent of converting the into a bool. In standard (old) JS fashion, it's both slower and less readable, but people still (used to?) do it. Similar hacks include 1* for num->string and +"" for the opposite, along with several others that I have luckily managed to forget.
I've never had to use JavaScript, but I've done the *1 or &"" in Excel to force conversion to the desired type... yes, let's mercifully lay the veil of forgetting over this.
Personally I think it is a good rule to never use Boolean(x), String(x), etc.
The problem is that many developers are unaware that `const s = new String(x);` creates a string Object. It looks like a string, and acts like a string, except that in some places it is not a string: for example `typeof s` returns “object”! Same problem for Boolean, Number, etcetera. Yes casts are ok, but it is easier to just say never use the value object keywords because you can end up with very wierd bugs a long way from where the value object was created.
Another example:
let x = new Boolean(true);
console.log(x === true);
I suppose it would be easy and might already be in some engines, but it's still discouraged because you can't rely on that optimisation (there are many engines), it's semantically incorrect, and most importantly much less readable - especially for someone not tok familiar with the JS type system.
I've recently started using a kind of middle ground by putting spaces around the !. Makes it harder to miss without losing the "reads like text" property that's lost when using == false.
if ( ! isLast(e) ) reads perfectly, especially since my native language doesn't insert the "not" im the middle like english does and my brain is used to that. if (isLast(e) == false) just jolts me out of that state where code reads as fluently as text. YMMV, of course, and I have a suspicion that your native language might play a role in that...
This looks really nice, too bad it doesn't (and never will) support ligatures. I understand the point the author is trying to make about ligatures in the separate blog post, but boy do I love my ligatures when programming.
The blogpost makes some good points, but it's extremely selective in choosing examples to support the author's thesis.
Mainly in that it ignores many examples of orthographic ligatures that don't fit the author's narrative. A (further deep-)linked blogpost on ligatures in general states:
> Ligatures were invented to solve a practical typesetting problem. In the days of metal fonts, certain characters had features that physically collided with other characters. To fix this, font foundries cast ligatures fonts [0]
But that's not true. That is why ligatures are used by many foundries more recently, but it's not why they were invented, and it doesn't cover all traditional uses of ligatures. German and French orthography in particular contain a lot of examples that are closer to programming operators in use than the author's "fi" example.
To me, ligatures in programming always file like a kind of syntax highlighting if that worked on the character level rather than the token level. Suppose given `difficulty = 3` your editor would highlight the `if`. That's how these ligatures feel to me.
For example, if you type three '=' symbols in Firas Code or JetBrains Mono, you get ≡, but if you type a fourth '=' it snaps back to '===='.
I can invent some odd situations where I get a ligature in the middle of a string, but in actual coding (for me 80% JS, 10% HTML/CSS and 10% Ruby) I simply don't see any incorrect ligatures.
Well, you just have to learn all the popular ligature forms, just like you have to learn all the popular variations of letter forms (e.g. "a" and "g" both have very different variations that are popular in different typefaces).
Of course. A `==` is two characters long, while `===` is three characters long. Also, with the font I use (Fire Code) the `===` ligature has three lines, making it even easier to distinguish.
Personally, it’s never really come up. I have no Unicode arrows in my actual source code.
On the occasion it’s in a string literal or whatever the it’s pretty obviously different, because it’s a single-width character as opposed to the double-width ligature.
Sure, but in a monospaced font both of those arrows would have to fit into the same small box, so 27F6 might be the full width while 2192 would be some partial width, while a -> ligature would be two widths.
The Unicode arrow looks smaller and is positioned lower, while the ligature has the same size as -> with the dash extended into the 'arrow'. Not that I use this frequently.
For me, I just selectively use _some_ ligatures. There are a few I like (like a lambda symbol instead of `fn` in Clojure), and the rest I just don't use.
“ligatures in programming fonts are a terrible idea”
I agree as well with the point about ligatures, but I find funny that the advice comes from a site that thinks straight up normal text with no hover, no distinct color, no distinct font and no underline is a good way to signal linked pages https://i.imgur.com/9iVMfgD.png (who would have guessed Racket was a link?)
"Ligatures in programming fonts—a misguided trend I was hoping would collapse under its own illogic."
The same could be said about so many programming conventions most people take for granted. Sometimes programmers are their own worst enemies. "just because you can doesn't mean you should" is probably the #1 rule of programming, at least for me, and ligatures definitely fit into that category.
I certainly don't blame you for not noticing the `#fbf3f3` background color on hover. However, it seems that every link is either small caps or has that trailing ° character. It looks like the former is used for internal links, and the latter for external. I agree that they're certainly not screaming, but considering that the author considers this a book, that is probably by design.
In short it’s a design choice paying homage to some other books, as well as to make the reading experience less distracting. He has a whole page explaining here, https://practicaltypography.com/how-to-use.html
It's a pretty interesting approach to the website and there's some features I never would have discovered on my own, but the author's reasoning seems pretty poor. The premise being that multi-line stretches of underlined text are difficult to read, therefore link-text (typically 1-3 words) should not be underlined.
It's also quite ironic that the author's argument against ligatures in programming fonts is that the simple substitution doesn't respect semantic difference, whilst using emphasis to signify that there is a link present
I'm not a fan of symbol ligatures but what I really loathe are monospaced fonts with a single character width fi ligature so the f and the i are both half width. I've seen several websites recently using fonts that do this. It is very visually distracting, especially in code samples.
On Macs, Courier (but not Courier New) can do it, though not by default.
(Open up TextEdit, enable Rich Text, select Courier, type "ff", highlight it, go to Font > Ligatures > Use All. The "ff" will now take up the width of a single character.)
I've run into a bug where certain styles of Courier Prime turns into ligatures in Google Docs. (Long story short, whether or not ligatures get enabled is a complex interplay between the OS, font, browser, and application, and not every layer always does it right.)
I'm not really sure why font designers even bother creating them in monospace in the first place though, I can't imagine any valid use for them. The only thing I can imagine is if a badly written application forces a ligature character, at least the end result will be readable rather than an empty box or something.
I can't imagine why anyone would do this either. I suppose one possibility is that some software in their web stack is converting fi to an explicit fi ligature and the monospaced font chosen by the web page doesn't support it so the browser does a substitution. When I spot another one I'll have to dig more deeply.
There's a free monospace serif-looking font called Go (made for Go, the programming language), designed by Bigelow & Holmes: https://blog.golang.org/go-fonts
I've been using Go/Go Mono as system fonts for a while, and they're one of my favorite typefaces. Their spiritual predecessors, Luxi Sans/Serif/Mono, are also worth checking out.
I have been using that font as my main development font since it was released. Great looking font. Although I have to give an accolade to Iosevka which is easily my favourite "narrow" font.
It’s unclear whether I need to include a copyright for this font in every PDF I create that uses this font. SIL Open Font License explicitly doesn’t apply to documents using this font.
I'm not clear on the outcry against ligatures. This is a client-side setting and not committed to code, is that right? If so, this is like prescribing that we should use dark-mode over light-mode because I like it.
Now during the pandemic we might screenshare more often so I can disable it for that, but for development on my own time on my own screen it's nonyabizness.
People like Having Opinions About Things In Public.
For ligatures it's bikeshedding taken to absolutely ridiculous extremes. It's past prescribing night/dark mode, it's at the level of pre/proscribing colour themes in a text editor.
It is a personal choice and it doesn't affect anyone else bar me. If you don't like ligatures, I don't care, it has no bearing on whether I like ligatures (and it is a personal choice, what fonts are easier to read is always based on what I'm used to reading text in)
I disagree that it doesn’t affect anyone else. The only way it can truly not affect anyone else is if no one else knows that you use ligatures.
And dark/light is fundamentally different: it doesn’t actually change the content, just the colours. Similarly most font choices are purely presentational in effect, with the variation easily within what a normal viewer can be expected to read. (There are exceptions; for example, I’ve seen a couple of fonts go for a very old style of r in their fancy joined-writing style italics which Indians will have no trouble reading, but which has completely fallen out of use in most of the English-speaking world, certainly in Australia, and so may be difficult to read.)
But ligatures change the actual glyphs, so that your fingers must type something other than what your eyes see, and any viewer must decode the ligature’s meaning. And this is the key reason why the proliferation of ligatures in coding fonts becomes a problem for everyone.
If anyone else ever sees your screen (in person, in a screencast, or in teleconferencing with screen sharing), it has affected someone else.
At an objective level, I think it’s fairly clear that for most people in most circumstances, a light background is superior to dark, and ligatures are a bad idea. However, at a personal level, the subjective factors routinely outweigh the fairly slight objective factors.
Popularity breeds popularity. I have been exposed to ligatures in coding fonts on websites and other people’s screens. I never chose to use ligatures.
There’s an ancient philosophical question about personal freedoms in all this.
> The only way it can truly not affect anyone else is if no one else knows that you use ligatures
That covers 99.999999999% of the times ligatures are used then, that's my point.
Sure, in a situation like screensharing, using ligatures "affects someone else". A font also "affects someone else". A theme also "affects someone else". Night/dark mode also "affects someone else". That's a given. It's also something that is normally trivial to turn on or off.
And sure, very, very occasionally people use custom fonts with ligatures turned on in the CSS on websites.
> I think it’s fairly clear that for most people in most circumstances, a light background is superior to dark, and ligatures are a bad idea.
It's not clear at all. Regarding typefaces and character sets and reading comprehension, what a person is used to reading turns out to be the easiest thing for them to read (why do you use a monospaced font in your text editor?). I get that it's a fun thing to argue about because it is completely stylistic, context-sensitive and personal and has near-zero real world effects (I'm doing it now!)
> But ligatures change the actual glyphs, so that your fingers must type something other than what your eyes see, and any viewer must decode the ligature’s meaning.
As opposed to typing a collection of "actual glyphs" which the viewer must then decode back to their actual meaning via the conventions of the language? The characters available a given programming language are determined by [sensible] technical limitations, so creative use needs to be made of those to represent concepts that are already represented by single, well known characters that are not available in the PLs character set.
My beef is that talking about which fonts you like/dislike: that's a productive discussion as they're a personal thing, very often an aesthetic choice.
But banket saying "usage of this _type_ of font is bad": that's not productive in any way, it's pointless, as it ignores the huge % of people who clearly don't share this view. Saying "it's fairly clear ligatures are a bad idea": no, it's display preference, and if is forced on you, you will generally have agency to request it be changed back to something you are used to.
And this is every time coding fonts appear in HN: comment after comment stating the latter as if it's some empirical truth when it most definitely is not (and yes, similar thing for tabs Vs spaces etc, so obviously everyone paints the bikeshed, but this time it's completely tied to one person's personal computer display)
I was going to complain about them because there are a few fonts there I like a lot, but not the ligatures. Wasn't sure if it was = or == or === in the samples.
I agree with the author on adding ligatures where they are not needed, but one of the comments used in their justification is not quite right:
> Unicode [...] identifies each character uniquely. This way, software programs don’t have to worry that things like the fi ligature might be stashed in some special place in the font. Instead, Unicode designates a unique name and number for each character, known as a code point. If you have an fi ligature in your font, you identify it with its designated Unicode code point, which is 0xFB01.
This is true for the Roman script, but for many other scripts, Unicode does not provide dedicated code points for common ligatures. They would instead have to be denoted by two characters with a zero-width joiner in the middle (much like emojis).
Also, most Unicode experts would tell you not to use 0xFB01 in new stuff today and instead should rely on font ligatures for it. 0xFB01 was included in Unicode for cross-compatibility with older encoding schemes for systems that didn't support fonts with ligatures. Today we have support for fonts with ligatures.
This looks very nice, but I can't pay that much for a coding font like this simply because until you load it into the various pieces of software you use it is impossible to know how it will render. Especially on a non-hidpi screen.
Chances are it will look significantly different than the PDF once you load it into your terminal. Each of the three terminal emulators I have installed already render fonts very differently from each other.
The author offers a pretty good 30 day refund policy if the font doesn't work in your use case: "Triplicate has no demo version, but I do offer a 30-day return option: if the fonts aren’t your style, you can cancel your license for a refund."
As for the customer service experience, the author himself has responded (within the day even) to a couple of emails when I had questions about licensing.
I agree with you and do consider the default l glyph to be a poor choice, insufficiently distinct from 1. Fortunately, the Code variant of the font goes for a curved tail on l, so that it’s sufficiently distinct.
(However, if you try to enable both the Code and Poly features—Poly meaning “don’t be a true monospace, make characters like l and i a little narrower and characters like m a little wider”—you end up with a slightly narrower flat-bottomed l glyph, rather than a curved tail. See this, for example, in https://chrismorgan.info/blog/make-and-git-diff-test-harness..., which is set in Code + Poly. Disable the `code { font-feature-settings: "ss01" 1, "ss02" }` CSS rule to see the effect of removing Poly—you get the curved tail l glyph back again. I’ve been meaning to sort out a better glyph for the combination, but I haven’t gotten round to it yet, because it’s annoyingly difficult to actually do that sort of thing.)
What's the decision process behind _choosing_ a font? I've always gone by look and feel but I've never felt fully satisfied with any of the (code) fonts I've chosen. I used Incosolata for a long time and in the last year I've moved to Hack. I really like Hack a lot but I am also trying harder to make more conscious decisions with my physical programming environment as I age (beyond aesthetics, caring about ergonomics, etc...).
I'm dyslexic. Because of that, I've spent a bit of time thinking about this for practical reasons. I prefer heavier sans-serif fonts with no character ligatures, but I like symbol ligatures and glyphs; they're not deal breakers. I've been using Cascadia Code, and find it usable, don't like the dotted 0 (the fact that the top and bottom of the 8 round in sharply helps offset this) or the few serifs it has. I've used Ubuntu Mono (spacing is too tight) and Source Code Pro (lines are too light) in the past.
What I look for is legibility between things like ({}), l1!|I, Oo08, mwnu, tl bpdq, ecoa, and being able to distinguish repetitio and symbols like --, ==, !!, "'`, :;, _-, and even ,.. (Something's going to try to parse that and absolutely shit itself)
I just grabbed B612 Mono.
n.b. I hadn't actually assembled those thoughts into one place before now. I apparently have Opinions about this!
Triplicate looks like Gallant, the font used by old Sun workstations. Looking like Gallant is a point in its favor (but ouch! That license fee is to its detriment.)
As far as serif monospace, NSimSun is still my favorite. It's in Windows. I love Triplicate but can't bring myself to purchase yet. I like Equity, too.
I think Triplicate is the closest to the old Selectric Prestige font, which I loved. But if anyone has NSimSun replacements (paid or free), please let me know.
A sibling post [1] mentioned Xanh Mono, which looks similar to NSimSun IMO. They both have that distinctive "Latin script alongside eastern script" serif look.
I like the true italics - they remind me a bit of the Light Italic typeface on the IBM Selectric (which has been discussed recently on HN I think.) IBM developed a number of beautiful and legible typefaces for its typewriters and I'd love to have them all as screen fonts.
Unless you're programming in something like Brainfuck, ligatures are simply not going to fail because the operators that have ligatures are pretty much universal. The situation of mixing up ligatures and their respective unicode chars is also nonsense, as those characters aren't typable and will only ever be used in strings, so there's no way you'd not know which it is and it's pretty easy to check anyways.
Programming ligatures provide a tangible benefit to many of us, so the author's insistence that they are a terrible idea is simply ridiculous (although, reading through some other articles on the site, not too surprising, as the site is 80% good common-sense advice and 20% poorly explained personal opinions being treated as gospel).
Yep, Triplicate and is far and away my favorite programming font as well, closely followed by Operator Mono. You need to pay for both, but it was easily worth it for me.
There's also CMU Typewriter text if you want another serif monospaced font. Looks wonderful in high dpi I believe. I've hacked mine to put slashed zero.
i can't find any pictures of triplicate with a dark background. could you share any? some hefty fonts (ie, go mono, courier) look so different when you change backgrounds that i am hesitant to buy without looking at a sample.
My own website has a dark theme if you have @media (prefers-color-scheme: dark), or if JavaScript is enabled, there’s a switcher in the top right hand corner. Note however that I use Triplicate T3 in the dark theme (300/700 for regular/bold), compared with Triplicate T4 in the light theme (400/700). You can fiddle with the @font-face declarations in dev tools (the font change happens in 2019b-dark.css) if you want to try swapping it out. https://chrismorgan.info/blog/rust-fizzbuzz/ has a bit of code, some other articles do as well.
thank you! this helps. as i suspected it is the best font i've seen for programming with a light background, and just meh with a dark background. i prefer a dark background though, and the only font that i can tolerate with dark is pragmata pro. sigh being so aware of fonts is a curse.
More and more often, I see ligatures being used on such fonts. E.g. === or != are combined in a visually single character. Personally, I don't like that at all as I think it makes code less readable. It is probably something that you can get used to. But what exactly is the appeal of it anyway?
I suppose some might say the code looks cleaner with ligatures and they better convey the meaning of the code (e.g. ≠ is easier to understand than !=).
Personally, however, I like to see exactly what it is I am typing, exactly which symbols are being used. Ligatures distort that.
Ligatures are fine when reading prose, but I find them too confusing when coding. That's a personal preference, though. I'm sure some people have no problem with them.
I expect a significant proportion of programmers do not like coding using fonts with ligatures, so it's interesting that this website only provides the ability to filter fonts to display only those with ligatures. I would have liked the option to only display fonts WITHOUT ligatures.
Personally, however, I like to see exactly what it is I am typing, exactly which symbols are being used. Ligatures distort that.
I feel the same way.
I do think I would enjoy programming in a language that used a slightly more extended set of real characters, as long as we had solid editor and font support so typing and viewing them wasn’t going to be an issue for anyone. For example, I’d like to finally have ≠, ≤ and ≥ lining up neatly with =, < and > in my code! I could imagine a few other carefully chosen and easily recognisable symbols, such as ∈ and true arrows, being helpful for readability as well.
But the world speaks in Unicode these days, so assuming there was adequate tool and font support, I think writing these characters for real would be much better than relying on ligatures. Even where ligatures are supported, they tend to use awkwardly wide glyphs to replace multi-character combinations so they don’t break alignment in a monospace font, and sometimes the fonts with programming ligatures seem to join certain combinations in bizarre ways just because they can, even when there’s no apparent need for it.
Ligatures in coding fonts is a good workaround for giving people options on what they see. I personally dislike ligatures, but I work with people who do like them.
They want to see ≠, but typing ≠ instead of != in a shared code base is not going to happen, regardless of keyboard layout or language support.
It's unfortunate that keyboard input is an afterthought for most systems.
OS X is probably the best overall, with easy installation (with one gotcha for development) and SIL Ukelele being a decent editor.
XKB is tolerable, overcomplicated in some ways and limited in others (really needing a layout to be paired with an .XCompose), but Linux Desktops™ make it painful to configure any layout that doesn't ship with their system.
I use a great little Windows program called WinCompose[1]. It turns Alt Gr on my keyboard into a “compose” key, so I can press that followed by a short sequence of other keys to quickly type numerous common symbols. As a result, I can type “ or † or ≤ almost as easily as I can type " or * or <. Similar functionality is available on other platforms, and I expect anyone who was typing the same symbols frequently, as programmers do, would internalise the shortcuts for them in a matter of minutes.
Also built in to Windows these days is the Emoji (Soft) Keyboard which you can pull up with Win+. or Win+; (whichever you prefer). Since a few Windows feature updates back it even has a comprehensive math symbols section (under the Omega tab). It just needs a few more shortcuts under the math tab to make it really powerful. For instance, if you keep typing after you bring up the Emoji Keyboard it will search through Emoji and then replace your search word with your final selection, but it currently doesn't let you type search words or shortcuts for math symbols when you switch to the Omega tab.
Interestingly, the scala language previously supported either => or ⇒ and deprecated the Unicode character in favor of instructing developers to use ligatures for that aesthetic effect.
Pre-deprecation, there were formatters which would replace the two characters with the single unicode character if you wanted. If you use a language which supports unicode function names and operator overloading, you could easily add support for your unicode comparison operators.
That's not how ligatures work. You have to explicitly turn open type features on, they aren't automatic. They are additions to the character set.
Edit: Unless your reason for checking is that you explicitly want a marginally smaller file (possibly just at bytes level) to download (in which case just use one of the many online tools providing subsetting to strip unicode ranges and do something like remove everything except basic ascii?) there's no real point filtering for fonts without ligatures because, practically, that's just all of them
To each his own I guess... I find ligatures show intent, are easier to identify and help instantly identify typos (== vs ===). I also find the things that ligatures replace are usually ugly "programming specific" sequences of characters. For instance, arrow functions look much better with their respective ligature because the equals and greater than characters are guaranteed to be aligned perfectly.
I'm primarily working in Javascript, so it may make more sense to use ligatures in my dev environment. And, as others have said, ligatures need to be explicitly enabled in your editor.
It's C notation. Other languages use other notations like ~= or /= or <>. And any conceptual overloading of ≠ is a tiny fraction of the problem with = (it's too bad ASCII'67 dropped the ASCII'63 ← in favor of _).
It looks pretty, that was at least the reason I started using it. And now I’m so used to them that I can’t live without them, and I don’t get the “less readable” argument. Most of the fonts make the ligature the same width as the underlying characters, just making them look prettier. My font of choice, PragmataPro [0], has both variants with and without ligatures if you so desire.
I paid the full price for it (€199), and I've found it to be a worthwhile purchase. It's pay-once-use-forever and since I spend a lot of time staring at code, the price per day of use is very low. Of course, there are free fonts that do the same and look good, I used Iosevka and Fira Code before I found PragmataPro. Honestly, I just adore how the font looks, and that was the primary reason I bought it, the others being the amount of available characters and that the author is a paid professional working on it.
An alternative that looks a lot like this one is Iosevka[0].
My favorite programming fonts are PragmataPro, Iosevka and Jetbrains Mono. In that order. I used to use PragmataPro for everything, but I use Iosevka for everything but my IDE these days.
I'll be honest, I've never grasped the perspective that sees typography as a meaningful aesthetic property of code. I mean, when I look at code, I'm not appreciating it as visual art, I'm reading it. Usually the point at which that stops happening is the point at which my brain is tired enough that it's time to go do something else for a little while and recover.
So, as long as the font I'm using doesn't actively impair legibility, which is a pretty low baseline, it doesn't really matter - and in any case, if it's a visual aesthetic I want, I'll go do it in Illustrator where I can actually have precise control over every aspect of that aesthetic, instead of forcing my programming environment to double as an installation art piece.
(DejaVu Sans Mono, in case anyone cares, or Menlo on Apple hardware since it doesn't want installing. Haven't changed it in what must be close to a couple decades by now; somebody sneakernetted me a copy of Vera Sans Mono in my earliest days of moving up from the helpdesk and I never looked back. Doesn't changing fonts impose a cognitive overhead of its own for a while?)
...all of which is to say I favor brutalism, I guess.
If you're working on code for most of the day, you will absolutely be making decisions that enhance your experience.
Could be an editor, monitor, chair, etc. It might not seem like some of those little things matter -- if I can sit in the chair, it works for me! -- but they do to some and typography is one of those things.
I don't understand folks who don't understand this. I get it if you don't personally care about typography but every developer is making QOL decisions.
I mean sure, I get that it's a QoL thing and that some people care more than others - I'm not arguing it shouldn't matter to anyone, so much as saying I have trouble grasping what specifically about it does make it matter to those who value it highly, I guess.
To answer this question you probably need to start broader with: why do ligatures exist in fonts at all? Then see if that applies to programming.
There's various accounts of the "reasons" ligatures came to be, but of the few I've seen all would (imo) apply equally to code as to language. The obvious one is pure aesthetic preference, but another is that ligatures came about as a way for business people of the time to differentiate letter/symbol-combinations for single repetitious use (as is done for operands: e.g. `===` has a single semantic meaning, it does not represent 3 programmatic operations in a row).
All in all though, I would guess this is about aesthetics mostly.
My own personal preference is to use ligatures in presenting code and avoid them in text editors/IDEs. I think this fits with traditional font use (writers would hand-write or typewrite manuscripts, ligatures would only be used by publishers/printers). It's possible presented code may "suffer" in readability for some unaccustomed to ligatures, so there's a trade-off to consider, but that's also true of books/articles using ligatures in natural language, and I think the problem is overstated in both cases. The nice thing is that copypasting the code doesn't force retention of the ligatures.
I can understand why it might aesthetically please some people, but can't understand how it actually helps with semantics, if one can't stand seeing "!=", it must drive them crazy to see other abstract symbols like "||", "return", "float".. imagine these are all replaced by single non-ascii obscure characters, it might be an interesting research on symbols, but i don't think it'll be a pleasant editing and reading experience for everyone
In typography there are ligatures that exist because they help readability (ex: ff fi tt) and others that are pure ornamental (ex: st).
Personaly I see coding ligatures as ornamental as I can't read === faster if all the lines are merged because I need a precision in the meaning of this symbols that I wouldn't need if I was reading text where I can use, - – — (minus, en dash, em dash) and while it might look a little off no one would lost the intended meaning.
Most of today's coding ligatures merge === such that it has three lines vertically as opposed to just two (evoking a "hamburger menu" icon as others have noted), in addition it's also generally still three character widths versus two. I find it easier to visually spot the difference between the == and === ligatures in Fira Code or Cascadia Code than between the non-ligature forms and counting the spaces in between the lines. Your mileage may vary of course, but in most cases after several years with Fira Code I find the ligatures in general are much faster for "at a glance" precision than some of the non-ligature forms.
I decided to try out ligatures a couple days ago. After about 5 minutes of getting oriented, I liked it better. The whole = == === thing ended up working out as a short = a long = and a three bar (giant hamburger?) were a lot easier to spot than the individual characters side-by-side. != turned into a double-width not equals symbol. So, 50% fun and 50% practical.
For instance != is just a way to write something that looks similar to ≠. With ligatures, you can actually see the symbol you're representing, and not an approximation. I suppose that is the appeal. And it looks neat.
> With ligatures, you can actually see the symbol you're representing, and not an approximation.
I think the flip side (which is why many people don't like them) is that with ligatures you can't see the actual code that you've written, only an approximation.
When I'm reading the code I need to understand what it does, the underlying characters are just a medium. I can see way quicker that a complex boolean expression is wrong when I see ≠ instead of != and ⪖ instead of >=.
I do agree with the Butterick that when presenting code to others, for example as examples, the ligatures are a big no, because in this case you actually need to see what characters you need to input.
In that case it works reasonably well, but how do you represent the difference between `=`, `==` and `===` in javascript. IMO =, == and === is much clearer and more visually distinct than ≔, = and ≡.
Mainly a force of habit. But I agree that for equalities a split sign would be clearer for most people.
I won't be going around and trying to convince people to use or not use ligatures though. I feel that it is a very personal preference much like the choice of syntax colouring theme.
I never use == in any circumstance anyway, but telling the difference between the == and === ligatures are really not hard. The === one, at least with JetBrains Mono, is much larger.
Trouble is, that argument falls apart because != is only akin to ≠ if == is actually =. If you use a language with := for assignment and = for comparison (or something similar), sure, making != appear as ≠ might make sense. But if you’re using almost any C-family language, you’ve already broken the mathematical model of what the equals sign means. After that, I side with nicoburns and say that now you’re obscuring what it actually means (in favour of something that’s more or less incorrect in mathematical notation).
I usually really enjoy customizing my shell and making it look pretty, but my first experience with ligatures was a bad one. I was learning LaTeX and my editor turned on ligatures for me (I think the vim-polyglot plugin was the culprit) and it was very frustrating. Ligatures in an unfamiliar environment make it harder to follow guides and learn from the code that you're reading. Maybe it would be a lot easier if I was using it in my native language, but it just struck me as an abstraction and one more thing to learn and keep track of.
At first I hated them and thought they were pointless and weird, but now I'm so used to them that it feels a little off if I don't see them.
It helps to visually parse things a tiny bit more quickly, I think. And it makes things more aesthetically pleasing, for me. Combined symbols like == and <= really are unique, independent things that make logical sense as their own separate units.
I sort of get the point, but a lot of these fonts squash together == to look like a long =, making it really hard to distinguish == from ===
Can you tell from 'Iosevka Slab' that it is a triple equal sign?
I've tried most of these at some point over the past few years and eventually settled on JetBrains Mono. I love it. The story about how it was created is pretty interesting... https://www.jetbrains.com/lp/mono/ And yes, there's a powerline version.
But be careful: not everyone will agree with what they say in such claims. I myself disagree at least moderately with more than half of what they say:
Increased letter height for better reading experience: this makes the proportions of the letters a little awkward, and makes ascenders, descenders and capitals less distinct. There’s a reason why the height of x should be quite a bit less than the height of d or M. They say “see how much nicer than Consolas this is!” yet I strongly prefer Consolas there.
Code-specific eye movement: again, increasing homogeneity regularly actually decreases reading performance. You do want patterns to be clear, yes, but trying to make everything closer to rectangular may well be taking things too far.
Functional сonstruction: who told you tails on letters like u were “unnecessary details”? The r and g ones are more subjective (Fira Code’s r especially is perhaps unnecessarily complex), but them tails be there for a reason, as they help with orientation of the letters and pattern recognition. Note that the g retained the taily thing at the top right corner.
Distinctiveness of symbols: I certainly have no complaints here—unless it be that the top left taily thing is inconsistent with the rest of the font, as with the letter i; but doing i and l in this way is quite common in monospaces.
Cut strokes: there’s truth to the pixel grid alignment technique, so long as the size is right or hinting is employed (… which it probably isn’t, nowadays). Tech personality, yeah, that’s probably true.
Italic: seems legit.
Ligatures for code: “To reduce noise”? This is an extremely contentious claim that I happen to believe is drivel (largely because your fingers still have to think in terms of the actual characters when you were typing, so even if you’ve reduced one cognitive load—debatable—you’ve certainly introduced another). “To balance whitespace”: fairly subjective, I think; in a proportional font, you do this sort of thing via kerning, where it works easily and naturally; but I don’t much like using ligatures to achieve the effect in a monospace.
This comment - https://news.ycombinator.com/item?id=22054487 - made similar points when the font was released, and I'm in complete agreement. Those decisions feel much more like aesthetic decisions rather than functional / accessible ones.
I switched to coding in a proportional font, Verdana, a couple of years ago and never looked back.
That's the font you are reading this comment in, in fact.
Code is mostly words and words are much easier to read in a proportional font. Symbols are plenty clear enough in Verdana, all letters are distinguishable, and I don't use mid-line alignment so I don't see the point in a monospace font outside of the terminal.
I'm confused. In every modern language I've used apart from go and terraform, only leading indentation matters and autoformatters do not apply mid-line alignment or align subsequent lines against characters in a previous line.
edit: and maybe Haskell? the layout rules are complicated
personally I don't think lining up e.g. variable or parameter names in c style declarations improves readability at all, and it pollutes git diffs.
but I do use a monospace font in the terminal because many command line applications align their output into columns using spaces.
Good point, it is usually the leading indentation that matters most. I guess since I use Clojure mostly, I like to be able to line up pairs in a map, or a let binding. This could potentially be achieved with tabs, but I'm a spaces guy so I think variable-spaced fonts would be problematic.
> but I do use a monospace font in the terminal because many command line applications align their output into columns using spaces
> That's the font you are reading this comment in, in fact.
Wrong. One of my favorite features of Firefox is that I get to choose whether websites can override my fonts. And they can't. Serifed Georgia is default, Ariel if they request sans-serif, and Consolas for monospace.
Yes. I just reloaded the Dev Fonts page with and without locked fonts and it only downloads them when the fonts are unlocked.
I forgot to mention that one may also set a minimum font size. That one does occasionally break a layout here or there, but it's worth it for easier reading.
I've used a ligature font now for a while and I've really grown to like it. It's not a big difference but I especially like how >= and <= turn to the mathematical equivalent which is more readable and different from arrow functions.
Iosevka is highly active and highly customizable set that I've been sticking with after a dozen terminal fonts switching. Every time I try a new font now, I go back to Iosevka. The narrow width makes it stand out significantly from the others and it's much easier to use when having multiple columns open on the screen. I highly recommend it.
You got me when mentioning multiple columns. My setup is that I have half of my external monitor with VSCode (the other half is the browser) and most of the times three columns in there - folder structure and two files on a split screen.
I compared Iosevka with the 3 others just as narrow fonts (Inconsolata, Nanum Gothic Coding, and Ubuntu Mono). Iosevka won for me because it is taller or bolder than the others (felt more easily readable in small fonts for me), but also because it is more unique in its shape compared to regular reading fonts — the “o” is more squared for example.
Thanks for your comment! I will change to it just now!
It is also my favourite. It's just narrow enough for using with multiple columns, but not too narrow that it affects legibility for me, and it's event customizable, for my nitpicky preferences.
It seems the Input fonts are missing (https://input.fontbureau.com) — I found this extensive font family several years ago and (in spite of regularly checking) haven't found anything better yet.
I use Input for about two years and really like it. IMHO you need a high dpi/Retina display, though.
I also like Output, a new font by Input‘s author, but haven‘t tried it yet. Might be a great fonts for usable interfaces
Besides various stylistic choices (most-but-not-all positive, in my opinion), JuliaMono differs from other dev fonts by having _way_ more unicode coverage. (And from other high unicode coverage fonts by being monospaced.)
I've been programming for over three decades, on many different systems with many different fonts. This topic pops up every so often but I cannot help but think that to me, it's the ultimate bikeshedding...
It couldn't be more subjective than that. This, and color schemes. Having any kind of argument over the subject is an utter waste of time indeed, as it ultimately boils down to preference.
I agree, each time I find myself trying new themes or fonts, I realize I've been stuck on a very hard problem for a few days. And my brain is just trying to get something, anything, done. So I start focusing on small unimportant details to feel like something is progressing.
Isn't it kind of silly that you don't have the option to chose font size. I tried a few fonts that looked good on the site but I don't code at 30px font and when I plug them to my IDE they look terrible.
The struggle for me is that browsers have their own font rendering code, so a font that looks great in Chrome, can look absolutely rubbish in Windows when used in say, Visual Studio (not VS Code). Inconsolata is a good example of this - on web pages it looks nice, but in Windows (non HiDPI) it's really badly rendered at any size under 16pt.
> And not because I’m a purist or a grump. (Some days, but not today.) Programming code has special semantic considerations. Ligatures in programming fonts are likely to either misrepresent the meaning of the code, or cause miscues among readers. So in the end, even if they’re cute, the risk of error isn’t worth it.
Bottom line: this is a matter of taste, like syntax highlighting, use of bold/italic/font face, because everyone configures its own editor to their own taste.
There's a certain style of programming font, I think due to narrow strokes and sharp curves that I at least find universally ugly and often hard to read. From this list Monoid, Iosveka, Anonymous Pro, and Share Tech Mono at least fall into that category. I think it's meant to be sort of a callback to bitmap fonts? I know the Linux console font (terminus) looks similar, but that's clearly due to technical limitations. Is there something wrong with my font rendering, or are there people actually liking this style? If you do like this style, what OS do you use? I'm wondering if there's a common trend where such fonts render better on macOS or something.
I've been using Anonymous Pro as my primary code font for at least 5 years now.
I came to Anonymous Pro through the path of previously using tewi [0]. I was big on the whole linux customization / "ricing" scene in my early years of university, and because of how my desk was set up, i was close enough to my computer to be able to read it. I ran Arch, with tewi, at a 9 point font size. I just liked how it looked.
Eventually my desk setup changed and having such a small font was no longer viable. I went with Anonymous Pro because I found it to be similar, but also easier to read at larger sizes. For a while I coded primarily in vim, so maybe there was something about just setting it once in the terminal config and having what I needed. I also picked it because patched versions existed with powerline symbols, which I was into at the time.
I now primarily use VS Code on Windows, but I still use Anonymous Pro. I think the narrow strokes and the sharp cruves that you dislike are actually easier for me to read. They give characters a kind of crisp shape, and I find that helpful in distinguishing which characters are which. When I look at the colleciton of fonts, ones like Cascadia, Ubuntu Mono, and especially Nova Mono all look awful to me, because of how rounded they are. I'm also in the crowd of people who dislike ligatures in programming fonts
If I were to pick any of the fonts from this list to try, I would probably pick Hack or Noto Mono for something a bit more robust, or Source Code Pro for something similar to the slenderness of Anonymous Pro. But I think the more important thing is knowing what you like and picking one and settling on it. It surprised me when I went back to my dotfiles and I was looking at screenshots, just how long I've been using the same font. But it makes things easy.
I love all those fonts! Right now I'm using Iosevka Term at Medium weight since I can cram a reasonable amount of code in horizontal space and the style looks very appealing to me.
This is with monitors at around ~130DPI. For regular old 96 DPI monitors I used tewi, a very small bitmap font.
I'm running Linux so most things are rendering on FreeType, here's a screenshot of Iosevka Term with some random youtube-dl code: https://i.imgur.com/qQHmOX2.png
I still haven't found a font I like better than Terminus. I've tried scores and keep coming back to it. I find most fonts to take up way to much horizontal space compared to Terminus. I might try a couple of those just to see, but I'll probably just end up back on Terminus.
Ligatures are nice but when you want to show the code to someone, or when you're reading a snippet for reference, you need to know exactly what keys to press to make that symbol. Assuming everyone knows the underlying glyphs for a combined ligature is not productive. I wouldn't want reference websites and documentation to use these fonts for example.
Same here. I could spend hours upon hours minimaxing this, but why? Monaco is as close to perfect as makes no difference (with https://github.com/Karmenzind/monaco-nerd-fonts so a nice prompt works).
Nice website but the problem is that it shows the fonts at 18px size when most people use their editors at 11 or 10px sizes. Many fonts look radically different at such small sizes.
I wonder if a survey would hold that to be true - I use my editor at 16 on Linux/18 on Mac. My browser zoom is also on to differing levels for different sites - I have HN at 160%.
I was literally just looking for this two days ago when I had to reinstall my main system and of course ended up searching here. [0]
One thing I noticed: I really want a different font for my terminal than for my editor – for the terminal I went for DejaVu Sans Mono, it's clean but still has some character, especially the dotted 0.
Am I the only one who uses a proportional font for coding? I find it more readable for the same reason it's more readable in books and other printed media.
Which one do you use? I love proportional font but find most of them not suitable for code. Input Serif is the only proportional programming font I can find but it looks too old school.
Georgia, modified to put a slash through the zero, and a small horizontal line, like a serif, on the l. Theory being, letters in serif fonts are easier to distinguish since visually they're more different from each other. Same reason the body text of books uses something like Times New Roman, only headings use a sans serif font.
I've been using Verdana for ~10 years. I've tried others but keep coming back to it. It continues to be a very consistent and elegant design for screen.
Whenever I come across a list like this I hope to find some useful new proportional coding typeface. Nope, not this time either, 100% monospaced. I guess I’ll stick with Input Sans.
I did use proportional fonts with REBOL, Ruby, CoffeeScript and JavaScript. Tried it with tab-indented Clojure code too.
However, 1-2 space indented code becomes just too ambiguous when rendered with proportional fonts, because the spaces are way too thin.
I wish editors would render em or en-sized spaces instead, at least for the line-leading spaces.
That way we would get the same indentation as intended with monospaced fonts, but still save horizontal space, while maintaining readability...
I would like to, but I hate tabs (due to the jumps it causes in horizontal cursor navigation, and also due to the nonlinear behavior when inserting/deleting characters preceding a tab in a line), so I would need an editor that widens spaces at the start of line to get sufficient visual indentation at four spaces.
My favorite recent font discovery is Simplex Roman. Designed in 1967 for early CRT vector displays by Dr. A. V. Hershey (for the US Naval Weapons Laboratory!), and released into the public domain.
Reminds me of vector arcade games like Asteroids and Tempest... By the way, another cool public domain font is the one used on all US interstates — 1948! https://en.wikipedia.org/wiki/Highway_Gothic
I don't see ligatures solving any important problem. If you think they do, I'd rather change syntax highlighting to recognize !== and others as a single token.
It's like multi-select in text editors. When you think about it, it's actually an inferior form of search&replace. Inferior because it interacts badly with off-screen matches. I find arguments of kakoune users unconvincing.
My personal opinion is - and I'm fine taking negative karma for this - that ligatures mostly appeal to the front-end developers among us. To the people who abuse the words "beautiful" and "gorgeous", and admire web pages which have a single text column using up 1/3 of screen width.
> If you think they do, I'd rather change syntax highlighting to recognize !== and others as a single token.
Your syntax highlighter probably already recognizes single tokens as single tokens.
> It's like multi-select in text editors. When you think about it, it's actually an inferior form of search&replace.
I’m thinking about it, and it isn’t. Sometimes search and replace is an inferior form of multiselect. Multiselect is a less flexible form of macros, but provides immediate feedback.
> My personal opinion is - and I'm fine taking negative karma for this - that ligatures mostly appeal to the front-end developers among us. To the people who abuse the words "beautiful" and "gorgeous", and admire web pages which have a single text column using up 1/3 of screen width.
This is an unpleasant statement and apparently even you recognize that.
Some HN users love to look down on front-end development as if it's some sub-par category of developers, for some reason.
Let's do the same kind of pretentious generalization - I'd wager they are the same who think any language of higher level of abstraction than than C++ is an utter waste of time.
Edit: did I hit a nerve? I don't even believe that second statement, but it's a good example of how pretentious that comment sounded.
Sure, some do. I can't speak for them. What annoys me personally is that sometimes they seem to praise very arbitrary stylistic choices as objectively superior. I think front-end developers are more prone to fashions than other kinds of developers. The blogs seem to go through phases.
That's making a lot of assumptions. They simply might be more prone to write, read and react blog posts as a general rule. Their work is also more visible than most developers' work, being customer facing.
Gotta also keep in mind the FE landscape has radically shifted in the last 5-6 years after being almost dormant for a long while - more or less coinciding with ES2015 and the emergence of reactive frameworks ala React/Angular/Vue.
I have to agree with my sibling commenter -- you are taking a pretty strange and rather aggressive stance on this, and throwing out some ad-hominems within that.
Multi-select: Useful if I want to do a find-replace, but only within certain select results for the "find" part. If I know where they are I can use Cmd+D or multi-select to just find those quick rather than crafting a nice regex find-replace query with "only in selection" etc.
Ligatures: It's SUBJECTIVE. I dunno why you're throwing out ad hominems like "only for frontend developers who like <things I think are bad>". I am looking at code for 8-12 hours a day. If ligatures make the code nice to look at, why the heck do you care what my code looks like? My ligatures aren't being pushed into your environment.
This is like judging someone as "lesser" than you because they like a different mouse because it's comfortable for them...
> I don't see ligatures solving any important problem.
I see ligatures as solving, imperfectly, the problem of "my language has clumsy operators because it wasn't designed with support for unicode operators" lining up with the preference of "I prefer less-clumsy operators".
If you don't have the first problem then, even if your language also supports ASCII multicharacter operators, its just an autoformatter issue.
Aside from the ambiguity with similarly-appearing genuine single characters, programming ligatures tend to not really solve the problem they set out to in monospaced fonts, where you end up with a single symbol which invariably preserves the width of the ASCII multicharacter symbol, which either introduces extra empty space or extra visual weight or, often, both.
> My personal opinion is - and I'm fine taking negative karma for this - that ligatures mostly appeal to the front-end developers among us.
I've seen more praise for them from corners of the Haskell/Idris community than from the much larger front-end community. I don't think there is any real correlation between working in front-end and preferring fonts with ligatures.
This is a curious position to take given that it's mostly a personal choice. People will like what they like, and that's perfectly fine! No need to denigrate frontend devs, or anyone, for a stylistic choice.
This is quite literally nothing but a website letting you preview how fonts look. What's "r/unixporn" about that? What a bunch of condescending baloney.
I kind of agree with your statement about multi-select, but even so, I love to use it!
(I "kind of" agree because a sibling comment is right that multi-select is a restricted form of macros, not search and replace. Because the things you can do with the multiple cursors are more than just search and replace.)
I am not sure whether this is a actually feature of this font.
Some ligatures, like => are only active in comments. It works both in Sublime Text and QtCreator: https://imgur.com/nWsZieo
I started using Nouveau IBM a few months ago[0]. Unlike the int10h fonts that protoman3000 mentions, this is reconstructed using vectors; it doesn't emulate individual pixels in the font.
To pile on the nostalgia, I also changed my default terminal text color to monochrome amber (#FFB000) [1], even though I've never used monochrome terminals.
Oh. One of these again. I get the feeling that "coding fonts" are converging on a certain look. There's a little variation, but not much... which is why I use 1980s microcomputer and terminal fonts to code in. See the Ultimate Old School PC Font Pack for a great collection: https://int10h.org/oldschool-pc-fonts/fontlist/
Of the more modern coding fonts, I find Iosevka the absolute prettiest (available under a free license anyway). My Visual Studio Code is set to use Iosevka.
Of course a favorite font is very subjective but to me the perfect monospaced font already exists: Monaco. It’s great for the terminal and IDEs and beautiful enough to use outside of coding.
The language selector doesn't seem to work correctly. I chose "Elixir", entered some elixir code but no highlighting was applied. Seems the highlighting library it's using is a bit iffy.
I've been using the OpenDyslexic font for the last few years and, while I don't believe I'm dyslexic I've found that it does in fact reduce eye strain while sitting in front of a monitor for long periods of time.
> You may use the Apple Font solely in conjunction with Apple-branded applications, including, but not limited to, Xcode, Terminal.app and Console.app.
So no, you really can't. Unless you just don't care since it's so good, which is not something that I would condone, obviously, since that would be morally wrong.
For some reason, this font never surfaces on these threads but I've been using BPmono for 10+ years and none of the dozen or so programming fonts got me to swap.
Additional features that would really elevate this site:
- Votes!
- Sort/Filter by Font Family, Alphabetical, Last Added, (vote count)
- A long shot here... if you're looking for something to do, give yourself a ML project by trying to somehow analyze fonts for similarity and link to most similar fonts and most different fonts.
I tend to use tiny sized font and I don't see any option to change font size. I'm always surprised by the huge default font size in text editors and IDEs.
So I ask: Is there such a "standard" dev font size every dev uses and no one complains?
During the early part of my career, I used to love to design and develop with very tiny fonts. In-fact, there were a time when there was a craze for Bitmap pixel fonts which looks the best at 8px. I used to build apps for Physicians who uses a hand-held device called Pocket PC[1]. My weapon of choice when it comes to fonts were these 8px bitmap fonts for the interfaces.
They look super sleek and smooth but the physicians keep complaining about the font-size. The clinics/hospitals were replacing pen-paper with these Pocket PC Devices and the physicians depend on them for their earnings. I learned my lessons and made the fonts bigger. Designs do not look so nice (at-least to me and my team) but they loved my work. It paid for them, their families. The last time I heard, they were still using the 'programs' (not apps) for over a decade or so.
Of course, my IDE had tiny fonts too. Then I grew and aged. By the time I crossed 30, my IDE's fonts were big enough and I began liking it that way. Today, I occasionally write code with "Monaco" font at 16px on a 5K iMac. One day, I might scale it and even make the text/content bigger.
Enjoy your tiny fonts while it lasts, you will also appreciate BIG text and fonts as you progresses.
I am 47, and still prefer smaller fonts. Not because my vision is perfect! But it seems to have accommodated to looking at small fonts for last 25+ years. I wonder how rare / frequent it may be.
50 is about the age where you get presbyopia, ie. start to get difficulties focusing details due to loss of lens elasticity, circular muscle weakening, and makula degeneration.
Can confirm. I used to love tiny fonts for coding, for everything — more text, less scrolling! 10, maybe 11pt. But as I approached 50, I started bumping font sizes up. When one of my eyes actually started twitching, I gave in and got glasses. My 20 year-old self would shake his head at my 50 year-old self in his glasses, peering at his 15pt code.
> I learned my lessons and made the fonts bigger. Designs do not look so nice (at-least to me and my team) but they loved my work.
That sent me down a nostalgia trail to this[1] book which has similar advice for Pocket PC developers. Drag the buttons and other form controls onto your program, then at least double their size, to make them go from stylus-required to semi-finger-friendly. Implement some custom code to drag empty screen to scroll, avoid the SIP where possible, wow, lots of memories making UX better for mobile users in the pre-always-connected-mobile-device days.
We're still here working, even if the form factor has retreated to serving delivery drivers and warehouse workers more than the general public. Pocket PCs / Windows Mobile 6.5+ embedded devices are a (often barcode-scanner-enabled) tool to get work done, data input, or data referenced in the field, with no VPN or internet access in several cases.
So personally, I tend to size fonts so that I can fit two editor windows of 100-ish lines + editor fluff side by side. This usually lands in the 14-18 point range, though if coding on my work MBP directly I have to sacrifice having the file tree visible to get a comfortable font size.
I used to as a teenager coding on a 1366x768 laptop use a 8px font size, as that was the only way to get 2 editor panes side by side. I'm in my late 20s now, so not an old age issue, but would not describe such a font size as comfortable these days. Part of that is monitors today are higher DPI, and part of it is that I now sit reasonable ergonomic distances from my monitors.
Thank you. Scratches my itch at this particular time, but as a guy who spends a lot of time with monospaced fonts in a code editor this is turning and to be a much more important resource than I thought.
I use Pragmata Pro because it supports monospaced Arabic text very well and I frequently have to work with Arabic. I've never seen a font that supports monospaced Arabic before.
Well, I checked them all out, and I must not be the target audience / a font person / very perceptive, because with a couple of exceptions they all look the same to me.
"This is a personal touch that was left over from the sketching phase. I handwrite my “f”s with a descender so this is one feature that I incorporated into the font." [0]
one of my first checks for a dev font is typing "lst vs 1st" (list vs first).
In some the lowercase "l" looks almost the same as a 1 (one).
Some will make the lower case "l" curved, but then some (like Iosevka) will remove the bottom bar for a one.
Those "Dev Fonts" suck because they are monospace, but English letter is proportional. The inconsistent letter-space of monospace fonts really drive me mad. Now I use Input Serif, it's not a perfect programming font, but it makes my code more readable than any monospace "Dev Font".
(Also note on that page, since people are talking about ligatures a lot in this thread: “No, there are no programming ligatures in Triplicate, and there never will be.” with a link to https://practicaltypography.com/ligatures-in-programming-fon..., which can be distilled to the quote “ligatures in programming fonts are a terrible idea”. I agree.)
Pragmata Pro and Operator are two other well-regarded and popular commercial monospaced fonts that are missing from this list.