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 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.
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.
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'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.
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).
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.
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 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.
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.
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
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 _).
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.
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.
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.
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.
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.
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.
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 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
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 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.
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'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.
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.
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.
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.
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.
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.
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.
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).
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.
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.)
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.
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 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.
“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?)
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.
"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.
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
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.
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.
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.
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.
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'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...
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 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.
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.
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.
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.
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:
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.
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.
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.
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.)
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!
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.
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.
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.
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)
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).
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.
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).
> 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.
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 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.
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.
"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]
341 comments
[ 3.8 ms ] story [ 275 ms ] threadLike you, I would have expected it to also update the example code to show the actual language.
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?
Even when physical panel size/resolution/scaling/panel type is the same, a different model can present different text clarity... e.g. https://www.rtings.com/monitor/reviews/dell/ultrasharp-u2720...
And we haven't even mentioned eyesight yet!
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.
1. https://en.wikipedia.org/wiki/Pocket_PC
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.
[1] https://www.apress.com/gp/book/9781590590959
https://fontlibrary.org/th/font/anka-coder-narrow#Anka/
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.
Also it looks pretty If you're staring a text editor for 8+ hours a day, it is important what you are staring at is pleasing to you.
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.
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 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.
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.
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.
Iosevka has several presets, or can be completely configured: https://github.com/be5invis/Iosevka#ligations
[0]: https://fsd.it/shop/fonts/pragmatapro/
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.
[0]: https://typeof.net/Iosevka/
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.
If I want to use ligatures, I have to explicitly enable it in my code editor.
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
I respectfully disagree with this claim.
It's conventional code notation that != is a Boolean test for (in)equality; that convention doesn't apply to ≠, which is overloaded in mathematics.
But, taking your point, a ligature ≠ would be overloaded in representing != and ~= and /= and <> and becomes potentially very risky.
And if you go a bit beyond top 20, there's Haskell: /=
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 are a poor workaround for bad keyboard layouts. If you want to see ≠ then type ≠.
Julia is the only ‘major’ language I know that supports most such characters.
[1] https://wiki.haskell.org/Unicode-symbols [2] https://4.bp.blogspot.com/_EKfCI8QuAaM/S7L-baZ-ZVI/AAAAAAAAD...
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.
[1] http://wincompose.info/
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.
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.
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.
It also introduce a ton of (unnecessary) complexity on top of the text formatting system, which in most cases are already a mess.
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.
(Not affiliated with JetBrains in any way)
There's so many subliminal things that I had never thought about/considered.
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.
(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.
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.
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.
[0] https://practicaltypography.com/ligatures.html
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.
It is nice to read. That's not the only thing we do with code. Ligatures are fine for yourself in a private setting.
It's popularity is alarming.
Copy and paste it in a different font.
Sun Gallant Demi is another one. Libertine/Libertinus Mono as well.
(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.)
[1] https://practicaltypography.com/triplicate.html
> They are licensed under the same open source license as the rest of the Go project's software
Which I assume is this one: https://golang.org/LICENSE
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?)
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.
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
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.
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.
"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."
(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.
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.
Apparently it's a way to negate and convert to boolean.
(eta: didn't finish the thought - I'd assume SQL influenced Excel, since it's older.)
This is a much more readable cast.
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:
Gives false.It's brain training - you find "!" hard to spot, and I don't. And vice versa for ligatures. Thank goodness we both have choices!
Of course not
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...
Obligatory digraphs/trigraphs reference: https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C
> 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).
(The ligatures in fonts such as Fira Code take up the same amount of space as the non-ligatured versions.)
(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 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:
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.
Also: https://github.com/yellow-type-foundry/xanhmono / https://fonts.google.com/specimen/Xanh+Mono
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!
TIA
thanks again.
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.
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)
/rant
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.
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)
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).
Raku wants to have a word with you. https://docs.raku.org/language/unicode_ascii https://docs.raku.org/language/unicode_entry
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.
[1] https://news.ycombinator.com/item?id=25161756
> 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.
Incredibly pleasant looking even today: http://paulbourke.net/dataformats/hershey/
OpenType conversions: https://github.com/scruss/AVHershey-OTF/tree/master/otf
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
https://abrudz.github.io/APL386/
I’ve always liked the look, but I use Fira Code in practice because it is more readable and narrower.
https://int10h.org/oldschool-pc-fonts/fontlist/font?ibm_vga_...
However, you should disable bold fonts in your terminal as it really does not look good in bold.
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.
[0] https://www.dafont.com/nouveau-ibm.font
[1] https://retrocomputing.stackexchange.com/questions/12835/exa...
I really liked Consolas in the example but it's not free so there's that.
What I didn't get is why the syntax highlighting option is so limited. Java didn't work for me at all even though it's in the dropdwon.
I also didn't understand why the width of the code area so artificially limited.
https://int10h.org/oldschool-pc-fonts/fontlist/
Also, the list needs Dina [1] in its TTF version [2]
[1] https://www.dcmembers.com/jibsen/download/61/
[2] https://chrisrickard.blogspot.com/2010/05/geenatcom-dina-ttf...
It has the perfect thickness and clarity imho.
https://madmalik.github.io/mononoki/
From the blog pos announcing the font.
[0] https://medium.com/@philpl/what-sets-dank-mono-apart-1bbdc1c....