Hacker News Reader

Comment by 9dev | Hacker News Reader

The author points out two problems, which both are ridiculously obscure edge cases: if there’s really a Unicode arrow in code you deal with, it likely won’t matter much if there’s an arrow or something closely resembling an arrow. The second point recommends getting rid of ligatures entirely just because they may, in some situations, do not display the right thing.

Both arguments ignore the 99.9999999999% of times ligatures do what they’re supposed to, and help me identify some symbols quicker. I’ll happily accept being confused once in a year about a strange-looking arrow in a debug log output, or from a weirdly rendered arrow in some ASCII art print.

People complain about weird stuff.

View on HN

Why on Earth one would want in a character-oriented text (i.e. where every character matters separately) to have some of them collapsed into one is beyond me. Why not take it further and have IDE render all occurrences of "cat" with an emoji.

Because in the cases ligatures are used most prominently, a "logical" character is made from multiple characters.

But the programming language is token-oriented.

But keyboards are not. Even if I’d be able to convince the maintainers of my favorite programming language to also accept some Unicode glyph as synonym to ‘==‘ how do I type it? Ligatures might not be ‘the right’ solution, but they are a highly efficient approximation. Also the cost of reversing the decision to use them is basically zero.

That's what I said. To the programming language it's just a token and representing that with a single ligature is fine.

I replied to a comment, that the document is character-based and therefore ligatures are inherently wrong.

Nobody expects mathematicians to write all their formulae in ASCII either, they are allowed to use special markup to denote specific things. Why can't developers use more specific notation for displaying code? We use `==` for equality checks due to a limitation of typewriters, not because it's the only sensible way to do this. Give ligatures a chance for a single afternoon, and you'll see the value of purpose-specific glyphs. They aren't replaced by arbitrary hieroglyphs, but actually self-explanatory, helpful representations of the thing a bunch of characters are supposed to tell you.

The last place where you want to have to mentally apply any decoding rules is in "debug log output".

Are we still talking about the same thing..? Fira code has like 20 ligatures which enhance the rendering of arrows and equality signs. There’s no „decoding rules“ to apply. This is just way, way overblown. Are you really stumped and confused if there’s „=>“ vs. „⇒“ in a piece of text..?

I never understood the justification though, beyond "it's pretty". When I see '<=' in a conditional, I see one symbol and attach its meaning. I've never needed to 'encode' that either.

I think the author failed to state the primary issue I have with ligatures: code listing using ligatures tend to be harder for me to read because the symbols are unfamiliar to me.

I first ran into this issue trying to learn Haskell, where some beginner websites used fonts like Fira Code in their listing. The "weird" operators I saw in the listings were unclear to me. In some cases I simply wasn't sure how to even reproduce the code in my editor. I think it is something I could grow used to and someday perhaps even enjoy, but as a beginner it was a barrier.

In most cases "copy and paste" still just work (unless the code listing was a screenshot, which is a bad idea anyway for teaching code) and you can learn it that way.

Also most of the lists of intentionally ligatured operators are pretty small and easy to find reference materials for. For instance Fira Code's big first chart in this section: https://github.com/tonsky/FiraCode#whats-in-the-box

In the case of a "real Unicode arrow", I'd just as soon use a Unicode literal if the language supports it, like '\u2192'.

Even better if your language supports it: use named escape sequences so you don't have to look it up. "\N{RIGHTWARDS ARROW}" vs "\u2192"

Or I could type -> and get on with my life.

How does that give you the unicode character you need in the output? Or are you saying there is just never a reason to have those in strings?

If your computer is set up properly you just type <mod>-> to get →.

Unfortunately, there’s a small amount of relatively common things you might want in literals that can be very confusing in monospace display: tabs, of course, but also all the other spaces (en, em, hair, etc., legitimately needed if you want your typography to be up to 18th-century standards and not argue about the “single vs double space” typewriter-age nonsense), hyphens and dashes and minuses (aka “why I’m still using -- and --- in my TeX code”), and so on.

I do use dashes and real (not pseudo-quotes, i.e. `"` and `'`) quotes in code comments but I only use the space symbol for whitespace.

I use the proper dashes, too, in prose (but when using TeX I use Unicode input these days). But even though some programming languages (such as Julia) would allow one to use the different dashes for different purposes, I don’t think that would be a good idea: they look too similar in, as you say, in monospace fonts.

The author is also very clear about that they’re not talking about what you use in your local editor. It’s about when you make decisions impacting others. It’s a kind of accessibility.

Reply on news.ycombinator.com