In general, I think having ligatures in a monospace fonts is a bad idea.
The reason is that in a monospaced font all the glyphs are supposed to the same advance value. This forces the ligatures to always take up the same space as two (or however many glyphs) are involved, which may stretch the ligature glyph in a non-intended way (if it is even possible to rasterise it that way).
Monospace fonts are also often used for programming (because they make sure that the columns line up consistently, regardless of the font being used). I personally don't see the point in showing ligature glyphs that do not correspond to the actual Unicode code points encoded to bytes in the source code.
Just my 2 cents.
I thought the same, but when Berkeley Mono got ligatures I gave them a go and never turned them off.
I think the truth is that any good monospace font is designed with an awareness of the grid those characters are laid out in. The rhythm and stability of that grid is a feature of monospace fonts. It lets us line up text, draw shapes and so on.
You would think not having the underlying characters visible would be an issue, but ligatures are just symbols like any other. In a short time you learn to read them, like you would any contracted word.
Decided to check those ligatures out, but this is pretty much entirely unreadable to me.
https://usgraphics.com/static/products/TX-02/images/TX-02-li...
It is probably a bit easier to start from a language you are familiar with. That image intentionally is a mismatch of random arrows and operators that don't necessarily align to the semantics of real code.
I think that's one of the things Fira Code's Readme [1] does a better job at than Berkeley Mono's page. The top big image breaks down the ligatures in high level categories or the programming language they are most associated with, side by side the version with a ligature. Further down the Readme you can several real examples from programming languages with the ligatures called out, giving you the context clues of what it looks like in a language you may be already familiar with.
Rationally, what you say makes sense, of course. But I love ligatures for programming. First of all, I think they just look nice.
But second, I also feel that for me, they make code a bit more readable. Without ligatures, multiple characters are often used to create one symbol; with ligatures, one symbol is always rendered as one single visual character. So if I read code, it just feels a bit easier for my brain to parse ≥, rather than >=.
> So if I read code, it just feels a bit easier for my brain to parse ≥, rather than >=.
Clearly there's personal preferences involved, so there's no objectively better or worse, but it still blows my mind, because reading ligature symbols like ≥ and ≠ always makes my brain skip a beat, so I need to reread a few times to "get it".
Some of that subjective influence with ≥ and ≠ especially is how much time you've spent in math courses or reading math papers. For some of us those have always been the "real" operators and >= and != the fallback replacements that look "close enough" in easy to type ASCII. We were sort of doing the opposite all along, translating the ASCII breakdowns into the math notation in our heads, and ligatures can feel like a bit of a relief because now you see the "real thing".
At least for programming ligatures, wouldn't they tend to be shown as a single glyph (and occupy the same space)? I don't like them, but for people that do, I expected ≠ to be displayed instead of !=, not a different longer glyph.
In coding fonts with ligatures, ligatures usually have the same width as all of the component characters combined. So if you type !=, you will see a character looking like ≠ that is two advances wide. You will even be able to select the middle of the character, hit backspace, and delete the (invisible) "!".
This is necessary because if all ligatures were one advance wide, you couldn't easily tell the difference between =, ==, and ===, or between != and !==.
I would rather != stay the way it is, and have the language support ≠ as a synonym. 30 years ago, on the mac's HyperCard, the language supported ≠ as an inequality comparator (as well as ≤ and ≥ for <= and >=, respectively). On the mac it's easy to type with the Option key and =.
Back then, those characters weren't easy to type on dos/windows so it seems to be a case of being stuck with the "lowest common denominator" in terms of character input across OSes, reminiscent of C's trigraphs where "??<" was used because keyboards didn't have "{"—thankfully those are long gone. Ligatures are a hack around that but it always struck me as an inelegant solution.
