
Ligatures in programming fonts - matiasz
http://tinyletter.com/mbutterick/letters/q-ligatures-in-programming-fonts-a-hell-no
======
panic
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
([http://unicode.org/faq/ligature_digraph.html](http://unicode.org/faq/ligature_digraph.html)):

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

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

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.

~~~
robert-boehnke
Isn't the choice of font inherently an editor feature like syntax
highlighting?

~~~
gvx
I don't think they're talking about the choice of font, but instead the choice
of replacing certain character sequences (e.g. ->) with glyphs (e.g. →).

------
wmil
The article lists a bunch of non-issues. Yes, you can create confusion by
abusing unicode.

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.

Yes, they are guaranteed to be wrong sometimes. The big one is the <<<
ligature makes the merge conflict zipper look strange.

But it's incredibly obvious when they are wrong. So it's not an issue in
practise.

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.

~~~
sneak
I gifted that guy gold for the sheer audacity of the thing.

~~~
jwilk
How much gold?

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

~~~
gboudrias
Wow you weren't kidding. I have no opinion on the matter but that's just
arrogant.

~~~
andyfleming
This isn't just some blogger though. Matthew Butterick wrote
[http://practicaltypography.com/](http://practicaltypography.com/) .

~~~
OJFord
A self-published eBook that acknowledges a lack of funding on the main page?

Maybe it is required reading in typography circles, but to someone reading the
submission who merely uses a font, this doesn't seem much of a credential.

~~~
kennethfriedman
"A self-published eBook that acknowledges a lack of funding on the main page?"
is kind of a low blow.

He's doing something really interesting with the funding model of
practicaltypography, that I believe should be praised.

~~~
OJFord
I'm not meaning to deal any blows at all, low or otherwise.

I'm merely explaining that to the reader not a student of typography, there's
not really any indication that this should be taken with more authority than
'some blog author' per comments above.

~~~
cmyr
From a brief bit of clicking around, the author has: designed several
typefaces[1], written a long text on typography[cited previously], and has
done enough programming to have developed the publishing framework he uses in
his books[2], and to have written another book on a programming topic[3].

While I don't agree with much of this blog post, I certainly think the author
has put in enough work to have their work taken seriously in this particular
domain, and generally seems like a pretty interesting person.

1\.
[http://practicaltypography.com/equity.html](http://practicaltypography.com/equity.html)

2\. [http://docs.racket-lang.org/pollen/](http://docs.racket-lang.org/pollen/)

3\. [http://beautifulracket.com](http://beautifulracket.com)

~~~
OJFord
I'll state just once more, in order to be absolutely clear that I harbour no
ill intent: I have no reason to doubt, having been told, that the author can
be regarded an authority on the matter. I'm simply saying that, approaching it
fresh, it's not obviously the case, and other commenters' disregard should not
be treated as that for a household name.

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

~~~
Libbum
> they should never be used for showing code in an public or explanatory
> context

This I can definitely agree with.

The readability issue, in my opinion, is fine and coarse grained.

If I'm scanning my _own_ code, having ligatures on is quicker for me to
understand and is ultimately more readable. But (and this is a large but),
when editing my own code, ligatures are useless and in the way. Thus I set my
editor to remove all ligatures on active/highlighted lines.

~~~
OJFord
I do this too, and with other 'prettifiers' like indent line characters.

I use vim, so I find it great to have them in normal mode, and then disabled
(set conceal =0) on entering insert mode.

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

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.

The author has a very subjective opinion that they try and present as fact.

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

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.

~~~
crazygringo
Wow, that's fascinating -- do you have a reference for that? I'd love to learn
more, especially as to why -- it seems like that would just result in ugly
typography. Or is it solely about the bar of the initial "f" connecting to the
next letter?

~~~
Johnny_Brahms
Well, typography is often about readability. Removing the word boundary in
compound nouns isn't really helpful since it removes a boundary that conveys
meaning.

There were some examples of nouns where you should avoid ligatures in the TeX
docs iirc. Shelfful and selffullfilling are the only ones I remember.

In German (every single fff on any page that bothers to set their own fancy-
pants font) and swedish text you see it all the time, often coming from self-
proclaimed typesetting/font nerds.

------
idle_zealot
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 ⇒.

~~~
pdkl95
> they're more expressive of intent.

You don't control which font will be used when viewing your source, so nothing
extra is being _expressed_ to other people about your intent. Using a font
with ligatures in your editor when you program doesn't record anything extra
in the source code.

> ⇒

I find it strange that you include the proper way of doing this instead of
using font ligatures: use the proper Unicode code point. Some languages
already support Unicode operators, such as Perl 6 which, for example, accepts
« » as a synonym for << >>.

[https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-p...](https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-
perl-6-and-you/)

~~~
seanmcdirmid
Unicode sucks for this kind of thing, since it would go on disk. Even if they
don't go on disk, you have to figure out how to break them up into multiple
characters so they can be edited (so ⇒ must be two characters, which is
messy). No, Unicode isn't the answer. It is the answer to deali with someone
who isn't using a specific font, like readers on hackernews.

Ligatures are a cake and eat it to. To those who don't care for them, they
simply don't see them. As they are under control of the font, editors don't
need special support either.

~~~
emn13
The fact that they go on disk is a pro, not a con; and the fact that they're
one character not multiple is also a pro and a not a con: what's the point of
the individual characters? Those were merely introduces as a necessary
workaround to cope with input limitations. Kind of like C trigraphs - and
nobody uses those because they want to.

~~~
MrQuincle
Unicode is a disadvantage for someone who wants to contribute to your code.
That person now has to figure out how to write down Unicode arrows, taking
her/him out of her/his flow.

~~~
kps
Sure, and the Dane has to figure out how to write down ø, taking them out of
their flow — until they learn to apply the correct tool for the job.

~~~
MrQuincle
I'm not sure if you're sarcastic or not. However, I'm Dutch, and we have
similar tokens.

Nobody minds if you write Danish code, but if you like contributors, it is
asking a lot of them to change their editor or tools to collaborate with you.
I hope you didn't mean your collaborators have to adjust to you like that.

~~~
kps
Not at all; the point is that a Dane isn't actually taken out of their flow to
type _ø_ in Danish, because they're using a suitable keyboard layout. Likewise
a programmer need not be taken out of their flow to type _(a→t ≠ 0)_ or _a ← b
∧ ¬c_ or _(2=0+.=T∅.|T) /T←ιN_.

------
SCdF
Honestly, this sounds like the kind of argument you could present about how
syntax highlighting is a terrible idea. It might be wrong!

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.

~~~
eridius
If your syntax highlighting is wrong, it's buggy. Proper syntax highlighting
is 100% correct.

~~~
falcolas
Depending on your language, proper syntax highlighting (without parsing the
entire program) is nearly impossible.

For example, in C, what highlight category do you give to '*c'? A declaration,
a dereference, or a multiplication call?

In Lisp, is the first element of a list a macro or a function (or a value)? If
there's a reader macro, it gets even harder.

~~~
oneeyedpigeon
Syntax highlighting doesn't necessarily have to work at the lowest
granularity, though; for some uses, merely distinguishing between comments and
non-comments is acceptable, and that's still 'syntax highlighting'. Of course,
as you point out, true 100% syntax highlighting needs to fully parse the
entire program; why not do that, though? I guess it would be too
computationally expensive for certain sizes of program, but it could still
update in near-realtime, no?

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

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.

~~~
ordu
Yes, I hate seeing code any way except precisely tuned emacs. I like small
sized characters, but most of fonts looks ugly, you'll need use antialiasing
to preserve shape, but some chars becomes unreadable with antialiasing. Except
of font choosing I'd like to see familiar color theme. And when I see code in
someone's else editor its hard to read.

But, you know, others didn't like my emacs setup, they says that its hard to
read in such small sizes, and my color theme with dark background is bad for
their eyes. Strange people, what on earth make them think, that I should be
considering their eyes health while choosing font and color theme for myself?

------
captainmuon
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, ...

~~~
kd5bjo
That's a hard one to get right; for a long time, C++ compilers would tokenize
'vector<vector<int>>' incorrectly and throw a syntax error -- the final two
angle brackets had to be separated by a space for the code to compile.

------
frou_dh
Ligatures in programming fonts really seem like something you'd only get into
in the midst of a hardcore procrastination bout.

------
sk0g
Q: Should random people on the internet dictate what you do and like? A: Hell
no

I quite like the ligatures that come with Fira Code, and most of the author's
issues are not applicable to it.

Maybe they should spend more than 5 minutes trying things out.

------
Arcanum-XIII
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)

~~~
yorwba
I'm sure the author is well aware of the difference between encoding and
display, since they have apparently designed their own fonts.

However, their argument seems to be that since ligatures are just a hack to
make plain text look like something fancy, you end up with confusing
interactions due to the lack of context.

Now I don't think this is likely to cause lots of problems in practice, since
most people won't use both ligatured => and Unicode ⇒ in the same Haskell
code; but in principle the potential for confusion is there. Imagine if some
clever font designer made ' look like ` when between a space and a letter, the
font would be unusable in any language where that is an important distinction.

Personally, I'm not going to use ligatures for coding, firstly because I'm
accustomed to the "normal" look and secondly because fcitx makes it really
easy to type arbitrary Unicode when I want it.

~~~
rossy
I'm aware that Butterick is the author of several fonts, but this article has
a surprising amount of vitriol from someone who should know that the choice of
a programming font doesn't affect anyone but the programmer who chose it.
During the article, he takes several opportunities to point out that his
opinions are actually facts.

Typographers usually have a lot of responsibility because their decisions can
affect the readability of text for many other people, and this is why sage
advice from experienced typographers is usually very handy, but in this case,
he's complaining about something that each individual developer has to
manually opt into. This is outside the realm of normal typography that he has
authority in. The editor settings of an individual developer are extremely
personal. Developers don't follow trends just for the sake of it. They set up
their environment in the way they believe is most productive for them, because
they know only their output matters. If an individual developer believes they
are more productive with Fira Code, that's nothing a typographer should lose
sleep over. If I believe that I'm ten times more productive when I code in
_Papyrus_ , that's no one's business but my own.

~~~
yorwba
> Developers don't follow trends just for the sake of it.

I disagree with this. The problem with lots of programming tools is the
difficulty of judging which options are the best for your use case, _before_
you have the experience of using them for a long time. So there is a real
temptation to just go along with what everyone else seems to be doing; since
they presumably know the benefits. There doesn't even have to be a real trend;
it's enough when there's one in your perception.

I have certainly done quite a lot of trend-following myself. I have used
relative line numbering in vim ever since I started using it, simply because
the first person I ever saw using vim had that option active. Later, when I
found myself doing mental arithmetic to get absolute line numbers, I was
simply too lazy to make the switch. I have actually only just now gotten
around to changing my config.

So someone who is thinking about switching to a ligatured code font might
benefit from an article like this, if it turns out that the issues raised
would be too annoying for them. If they don't think those will be a problem,
however, they can just go right ahead and make the switch.

------
VeejayRampay
Am I the only one thinking that "www" using Fira Code is unreadable?

------
ktpsns
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
([http://reference.wolfram.com/language/ref/character/Rule.htm...](http://reference.wolfram.com/language/ref/character/Rule.html))
or ∞ indicating Infinity
([http://reference.wolfram.com/language/ref/Infinity.html](http://reference.wolfram.com/language/ref/Infinity.html)).

As Mathematica inherits the homoiconicity from LISP, ie. the paradigm "code is
data", it abstracts the code representation (called "Forms",
[http://reference.wolfram.com/language/tutorial/FormsOfInputA...](http://reference.wolfram.com/language/tutorial/FormsOfInputAndOutput.html)).
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.
[http://reference.wolfram.com/language/tutorial/SpecialCharac...](http://reference.wolfram.com/language/tutorial/SpecialCharacters-
MathematicalAndOtherNotation.html)).

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

~~~
MarkMMullin
Been awhile since I used MM, but I do remember this - personally, I like using
Fira with my code, but that's because there's a disgusting amount of math in
it and it makes the reading a lot easier - your implicit separation between
representation and presentation is spot on IMO

------
jstewartmobile
Somewhat off-topic, but the explosion Unicode glyphs can lead to problems more
serious than aesthetics:

Punycode exploit: [https://www.xudongz.com/blog/2017/idn-
phishing/](https://www.xudongz.com/blog/2017/idn-phishing/)

Greek question mark: [https://stackoverflow.com/questions/26965331/javascript-
pran...](https://stackoverflow.com/questions/26965331/javascript-prank-joke)

Shameless plug: [https://github.com/BourgeoisBear/A-E-S-T-H-E-T-
I-C](https://github.com/BourgeoisBear/A-E-S-T-H-E-T-I-C)

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

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.

------
mikelward
Premise: don't make => look like ⇒, because ⇒ is already a separate thing.

Then later: check out this font I made where 0 looks like Ø.

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

------
broxp
Fortress (a dead JVM programming language by Guy Steele) had an interesting
approach for special characters:

[https://de.wikipedia.org/wiki/Fortress_(Programmiersprache)#...](https://de.wikipedia.org/wiki/Fortress_\(Programmiersprache\)#Darstellung_des_Quelltextes)

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

~~~
oneeyedpigeon
Some of the ligatures in Fira Code are so radically different from the
characters they're substituting, that single-character selection would be
incredibly confusing. How would it behave for the characters on the final line
of the sample, for example?

------
qarioz
Ligatures are for personal usage only. If you are doing presentation to me and
use ligatures, I will judge you.

~~~
MarkMMullin
I would argue it's not a one size problem - I use Fira for machine learning
heavy code, which is primarily math, and ligatures for the various
multicharacter operators make it more readable. Judge me, fine. But judge me
in context please :-)

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

------
warrenm
I didn't even know those were a thing

But in a monospace font? No. No. No. no. No.

Epicly bad plan to use something like that to display code

~~~
detaro
What's bad about them? (I find the arguments in the link interesting, but not
all that convincing)

~~~
zepolen
Can't guarantee 80 characters length easily.

~~~
rossy
This isn't a problem with ligatures that are designed to take up as much space
as the characters they replace. Fira Code seems to have been designed with
this in mind, so for example, the === ligature is exactly three times as wide
as a normal character.

------
ktpsns
mnm

