Live data from Hacker News

Ligatures in Programming Fonts: Hell No

practicaltypography.com

31–40 of 89 posts

Re: Ligatures in Programming Fonts: Hell No

#31
I use Fira Code constantly and consistently, with punctuation-rich language (Scala); haven’t found any practical problems yet. Theoretically, there can be inconsistencies; practically, it doesn’t happen.

If it is consistency and perfection everywhere you are looking to find, software engineering in general might not be the best job for you.

Re: Ligatures in Programming Fonts: Hell No

#32
Usually, the author is spot-on with his recommendations and I really enjoy reading his website. So I was a bit surprised about this:

> When we’re using a serifed text font in ordinary body text, we don’t have the same considerations. An fi ligature always means f followed by i. In that case, ligature substitution that ignores context doesn’t change the meaning.

Maybe this is different in English typography - I'm a bit more proficient in German - but ligatures do have semantic meaning. At least in German, they should never cross a word boundary in composite words, for example Kaufleute (merchants) is Kauf-leute (buy-people), so you would not use a "fl" ligature. There are actually words where this resolves an ambiguity, I think. Historically, this is the reason sometimes ss and sometimes ß is used. I always assumed there were similar subtle rules in English.

As to the "ligatures" in programming fonts - I would not call them such, problem solved. Rather, they are substitutions in the tradition of APL or vim conceal mode - to get mathematical notation with a standard keyboard.

Re: Ligatures in Programming Fonts: Hell No

#34
Setting aside the article for one second, I just want to mention that the author is a hell of a font designer, and his Triplicate Code is my favorite programming font at the moment [0]. It has all the styles you would want (light strokes, heavy strokes, bold, italic, ...) as well as lovely serifs. Most serif programming fonts are slab serifs, but not Triplicate. These ones are lovely and light things. It's a real pleasure to work in. Well worth the cost if you care about such things.

[0]: https://practicaltypography.com/triplicate.html

Re: Ligatures in Programming Fonts: Hell No

#35

Usually, the author is spot-on with his recommendations and I really enjoy reading his website. So I was a bit surprised about this: > When we’re using a serifed text font in ordinary body text, we don’t have the same considerations. An fi ligature always means f followed by i. In that case, ligature substitution that ignores context doesn’t change the meaning. Maybe this is different in English typography - I'm a bi…

The whole point of ligatures is that they are visually subtle enough that you don't consciously notice them, while removing distracting collisions of adjacent glyphs. The German rule seems entirely pointless and counterproductive.

That said, OP is wrong that ligatures would "break Unicode". The only ligatures that are directly encoded exist for historical reasons. Fonts can and should make contextual alternatives, and this is a normal part of typesetting for several languages.

Unicode breaks Unicode, it's not meant to be consistent, only compatible.

Re: Ligatures in Programming Fonts: Hell No

#36

Usually, the author is spot-on with his recommendations and I really enjoy reading his website. So I was a bit surprised about this: > When we’re using a serifed text font in ordinary body text, we don’t have the same considerations. An fi ligature always means f followed by i. In that case, ligature substitution that ignores context doesn’t change the meaning. Maybe this is different in English typography - I'm a bi…

The whole point of ligatures is that they are visually subtle enough that you don't consciously notice them, while removing distracting collisions of adjacent glyphs. The German rule seems entirely pointless and counterproductive. That said, OP is wrong that ligatures would "break Unicode". The only ligatures that are directly encoded exist for historical reasons. Fonts can and should make contextual alternatives, an…

Yes. I learned from this article that there are code points for ligature glyphs in unicode and it seems like a pretty bad idea, tbh.

Re: Ligatures in Programming Fonts: Hell No

#37

Usually, the author is spot-on with his recommendations and I really enjoy reading his website. So I was a bit surprised about this: > When we’re using a serifed text font in ordinary body text, we don’t have the same considerations. An fi ligature always means f followed by i. In that case, ligature substitution that ignores context doesn’t change the meaning. Maybe this is different in English typography - I'm a bi…

For an English example, some typographers would consider it better to avoid an "ff" ligature in "shelfful" (see The TeXbook, p.19).

Re: Ligatures in Programming Fonts: Hell No

#38

Used judiciously, ligatures can help make code more readable, not less. Consider JavaScript's == and ===, and their inverses != and !==. I personally find them difficult to visually distinguish on occasion (especially the negative forms). Fira Code [0] replaces them with two-bar and three-bar equals signs (something like =, ≠, ≡, and ≢, only wider; see the link for a screenshot). I personally find these easier to dis…

Well, at this point, `store` (=), `equal` (==), `equiform` (===) are even more readable, meaningful and accurate. Of course other terms such as `equivalent`, `equiquantal` `equireference`, `equieffective` and more are also possible.

Don't forget people read whole words, so they most likely don't spend much time on "==" recognition than they would with "equivalent". And with text completion, token length is an irrelevant metric on productivity as well.

Any non literal symbol used in code is an incentive to use more of them and turn code bases into harder to maintain "smart" obfuscated trick stacks.

On an historical perspective, how much people using "=" know where it comes from (nothing is more equal than two parallel lines), compared to how many people are able to make a good guess of the etymology of "equivalent" (same value)? Add to this observation that in the mid-time with the raise of non-euclidian geometry and topology the former insight is far less relevant nowaday.

Re: Ligatures in Programming Fonts: Hell No

#39

Fira Code's main problem is that it tries to be a font for all programming languages which results in some weird behaviours here and there. Unfortunately, there's no good way to have a font have sets of ligatures per . That said, however, the article fails to provide a compelling argument against ligatures. 1. Fonts have nothing to do with Unicode. It's exactly the font's job to provide any glyphs or ligatures it wan…

> Unfortunately, there's no good way to have a font have sets of ligatures per .

If your IDE (or text editor) can highlight and indent languages differently then it can certainly switch font or toggle a font property to select a ligature variant set.

Post reply on HN