Hacker News Reader

Comment by uallo | Hacker News Reader

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?

View on HN

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.

I believe all of these fonts can be used without ligatures.

If I want to use ligatures, I have to explicitly enable it in my code editor.

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

> ≠ is easier to understand than !=

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.

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 _).

The != notation has become pretty standard in most common programming languages. What exceptions are there in the top 20 development languages? VBA?

But, taking your point, a ligature ≠ would be overloaded in representing != and ~= and /= and <> and becomes potentially very risky.

SQL for one.

Also MATLAB: ~= Delphi: <>

And if you go a bit beyond top 20, there's Haskell: /=

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.

I feel the same way.

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.

Haskell has a language extension that does the same thing [1]. Now all you need is a keyboard with good unicode coverage [2].

[1] https://wiki.haskell.org/Unicode-symbols [2] https://4.bp.blogspot.com/_EKfCI8QuAaM/S7L-baZ-ZVI/AAAAAAAAD...

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.

[1] http://wincompose.info/

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.

Raku / Perl 6 has been supporting unicode for operators, quotes, rational numbers, etc. for more than a decade.

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.

This is also the same reason why tabs are better than spaces.

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.

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.

[0]: https://fsd.it/shop/fonts/pragmatapro/

How much did you pay for it? I love typography but this looks quite pricey

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.

[0]: https://typeof.net/Iosevka/

It's $19 if you just pick the regular weight desktop version.

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.

The thing that made the difference for me is the hinting, it's an absolute game changer on lower resolution screens.

Well I guess the idea is that the ligatures represent the concepts that the combination of symbols are trying to represent.

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.

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.

> But what exactly is the appeal of it anyway?

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.

Why would copy-pasting force retention of ligatures? Ligatures don't change the underlying characters, only the graphical representation of them.

It doesn't. That's what I said.

Ah, so you did. My apologies, I misread.

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 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).

So, use the right ligatures for what you're doing.

Iosevka has several presets, or can be completely configured: https://github.com/be5invis/Iosevka#ligations

I consider editor not showing or changing what you exactly type as rude (I can accept autocompletion because it at least prompts).

It also introduce a ton of (unnecessary) complexity on top of the text formatting system, which in most cases are already a mess.

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.

I’m with you. It’s source code, and as such I prefer seeing... well, only the source. I don’t get why it’s so polarizing, it seems obvious to me haha

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?

Reply on news.ycombinator.com