The first problem isn't really a problem, since ligatures are provided by fonts, not character encodings. From the Unicode FAQ on ligatures and digraphs (<a href="http://unicode.org/faq/ligature_digraph.html" rel="nofollow">http://unicode.org/faq/ligature_digraph.html</a>):<p><i>"The existing ligatures exist basically for compatibility and round-tripping with non-Unicode character sets. Their use is discouraged. No more will be encoded in any circumstances.</i><p><i>"Ligaturing is a behavior encoded in fonts: if a modern font is asked to display “h” followed by “r”, and the font has an “hr” ligature in it, it can display the ligature. Some fonts have no ligatures, some (especially for non-Latin scripts) have hundreds. It does not make sense to assign Unicode code points to all these font-specific possibilities."</i><p>The second problem still stands, though, especially since these sequences of characters can be tokenized differently in different programming languages. IMO, if you're going to have character replacement like this, it should be a configurable editor feature like syntax highlighting.
The article lists a bunch of non-issues. Yes, you can create confusion by abusing unicode.<p>But that's not new. C++ allows zero width spaces in identifiers. There's a guy on reddit who uses characters from Canadian Aboriginal Syllabics block to have angle braces in Go identifiers.<p>Yes, they are guaranteed to be wrong sometimes. The big one is the <<< ligature makes the merge conflict zipper look strange.<p>But it's incredibly obvious when they are wrong. So it's not an issue in practise.<p>The reality is that no one is making anyone use a ligature font, and some people like them. If it's causing a problem then you can spend ten seconds changing your font.
Ugh to answer the last line of the author: I have been using them for that long and the up and downsides are very well known to me. He has an subjective opinion about them, states them as facts 'and everyone who thinks differently is just stupid' OK author...
I agree with the article, but the arguments the author gives are not quite spot-on.
Ligatures render code unreadable, there is no way to see how to enter a particular character sequence that is shown as a ligature. They might beautify code for some individuals, but they should never be used for showing code in an public or explanatory context, like on the web. Some operators are no longer recognisable, a few just look wrong - a clear case where simplicity and functionality is sacrificed for style.
I use ligatures in atom and they are 100% aware of context. I disable them in contexts where they don't make sense e.g comments and I disable them on the line the cursor is on.<p>I've not had any issues. The => ligature looking like the right arrow character is just like a cyrillic A looking like a latin A - it's a problem that never manifests itself.<p>The author has a very subjective opinion that they try and present as fact.
The author's point about "dumb" ligatures doesn't really hold up: While the "fi" ligature will always mean "f followed by i" its use is not always correct.<p>For example, in German compound nouns, you do not set a ligature between the two nouns. For instance, "Kaufläche" (Kau: chewing, + Fläche: area) should be written with ligature, while in "Kaufleute" (Kauf: purchase, + Leute: people, = merchants) the ligature should be avoided.
I use fonts with ligatures while programming because they're more expressive of intent. Many languages use a combination of characters to form a single meaningful token, such as JS with =>. This token is meant to appear similar to an arrow, and has nothing to do with = or >. In this case, I find it preferable to draw a ⇒.
Honestly, this sounds like the kind of argument you could present about how syntax highlighting is a terrible idea. It might be wrong!<p>I don't use ligatures, but I really don't see a problem with other people using them. It's fine, it's a style preference thing, that, like fonts and colour schemes, is as much fashion and personal preference as it is anything. But it's fine.
I work with someone who uses ligatures. Everytime I need to see his screen is a problem, I can never recognize what exactly the characters mean. Yes, you get used to it if you use it, but if you don't, working with other people becomes a problem.<p>I thought it was a bad idea the first time I saw it, and after seeing it in real code I still think the same thing.
I think ligatures can be a great feature, but they should not be decided by the font, but by the editor. So you can can destinguish between 'input >> var' and 'vector<vector<int>>' and render the literature in one case but not the other. This and more creative text decorations can be really helpful to read code. Other examples are rendering css colors inline, rendering of tables and formulas in emacs, ...
Q: Should random people on the internet dictate what you do and like? A: Hell no<p>I quite like the ligatures that come with Fira Code, and most of the author's issues are not applicable to it.<p>Maybe they should spend more than 5 minutes trying things out.
It seems there is some confusion for the author between the display part and the on disk part. text will not be saved with the ligature, it will still be pure unadorned text when saved... and for the confusion that could arise between a simple quote and a typographic one, it's not coming from the font but from the editor rendering engine (word does those kind of change, IntelliJ does not for example, but both can display correctly ligature)
Interestingly, nobody mentioned Mathematica's (Wolfram langauge) approach of getting Unicode characters into code. "High level" mathematical symbols can be used in Wolfram language all over the place, for instance the arrow → indicating a Rule (<a href="http://reference.wolfram.com/language/ref/character/Rule.html" rel="nofollow">http://reference.wolfram.com/language/ref/character/Rule.htm...</a>) or ∞ indicating Infinity (<a href="http://reference.wolfram.com/language/ref/Infinity.html" rel="nofollow">http://reference.wolfram.com/language/ref/Infinity.html</a>).<p>As Mathematica inherits the homoiconicity from LISP, ie. the paradigm "code is data", it abstracts the code representation (called "Forms", <a href="http://reference.wolfram.com/language/tutorial/FormsOfInputAndOutput.html" rel="nofollow">http://reference.wolfram.com/language/tutorial/FormsOfInputA...</a>). Every shortened code full of greek symbols can be written in a completely similar form in ASCII. Thus it is solely to the Mathematica notebook (a Qt-based GUI) to render the Unicode. The GUI also allows to quickly enter any named symbols with an approach like typing "[ESC] alpha [ESC]" and an α appears (cf. <a href="http://reference.wolfram.com/language/tutorial/SpecialCharacters-MathematicalAndOtherNotation.html" rel="nofollow">http://reference.wolfram.com/language/tutorial/SpecialCharac...</a>).<p>I think this is the right approach: Let the beautification to be done by the code viewers. The approach to enter named symbols probably stems from (La)TeX where one writes "$\alpha$" to get α and is typical to Computer Algebra Systems. For instance, SageMath as well as SymPy allow to define something like a=var("alpha") and render it like α.
Somewhat off-topic, but the explosion Unicode glyphs can lead to problems more serious than aesthetics:<p>Punycode exploit: <a href="https://www.xudongz.com/blog/2017/idn-phishing/" rel="nofollow">https://www.xudongz.com/blog/2017/idn-phishing/</a><p>Greek question mark: <a href="https://stackoverflow.com/questions/26965331/javascript-prank-joke" rel="nofollow">https://stackoverflow.com/questions/26965331/javascript-pran...</a><p>Shameless plug: <a href="https://github.com/BourgeoisBear/A-E-S-T-H-E-T-I-C" rel="nofollow">https://github.com/BourgeoisBear/A-E-S-T-H-E-T-I-C</a>
> The problem is that ligature substitution is “dumb” in the sense that it only considers whether certain characters appear in a certain order. It doesn’t have any awareness of the semantic context.<p>True, which is why Iosevka has language-specific ligatures that a sufficiently smart editor (I think the "JS types", like Atom/VSCode, have CSS for this) can use to ligate (?) intelligently.
Ignoring the Unicode issues, I installed all of these, switched to the retina version of each in my editor and I found none of them any better than what I had been using (Menlo). I'm certain that YMMV but at least for me, there was no improvement (languages tested with were Ruby, and ERB formatted HTML).
Fortress (a dead JVM programming language by Guy Steele) had an interesting approach for special characters:<p><a href="https://de.wikipedia.org/wiki/Fortress_(Programmiersprache)#Darstellung_des_Quelltextes" rel="nofollow">https://de.wikipedia.org/wiki/Fortress_(Programmiersprache)#...</a>
Do ligatures really act like one character? I've never encountered not being able to select only the f ro the i in a 'fi'-ligature, but I don't really use ligatures outside of word processing.
They call it ligatures, but prettifying --> to a long arrow is quite out of scope of historical and practical meaning of typographic ligature. It's abuse of typesetter to scratch one's typography / graphic design itch, no less.