Much ado about nothing. It's a matter of personal taste. An actual ≠ has a low chance to sneak into the source code, even lower chance to somehow type it by hand. Either way, it would be a syntax error highlighted by any editor. I'd like my code to look nice and I accept the risks.
It's probably fine for you reading your code. It's not impossible it causes others reading your code some confusion when they render it with ligatures or receive eg pdf of it in ligatures, distinct from how it looks when they edit it.
Minor issue mostly.
I tend to "no", but for no very good reason: Aesthetically they're lovely.
Other people reading your code... on your laptop, using your editor? Because on anyone else's computer it's going to be based on their personal viewing preferences. Setting your tab spacing size too large will also make your code unreadable. But only on your computer.
> Other people reading your code... on your laptop, using your editor?
No, rather in your web page, in the slides that you're projecting, in the paper that you typeset into PDF...
The point is not about how you edit your own code. You could even write comments in sanskrit, if they are for your eyes only, but please don't dostribute them!
As an aside, I have seen literate French perlcode some time ago that had very good French language comments alongside quite normal western variable and function naming, which I suspect was in everyone's interests.
It's only a matter of personal taste because it's not statistically examined, so there is no hard evidence in the form of numbers that the yea or nay side could use.
If it were properly studied, and it turned out that ligatures have an effect on the rate of mistakes, then one side of the debate would have to concede that though they choose persist in their personal taste, it is in conflict with what is good for their work.
> An actual ≠ has a low chance to sneak into the source code,
Hmm...my programming language supports ≠ directly ...
> even lower chance to somehow type it by hand.
... and my keyboard lets me type it (almost) directly, via Alt-=.
I think the author is spot on in that the current state is not the correct end-state, though given path-dependencies it is understandable how we got here.
I've witness many a question after/during technical slides where the audience was confused by symbols. At a bare minimum, don't use ligatures in slides or blog posts or anything meant for a broad audience.
Ideally, languages would support Unicode as well so you can mean what you say when you type—some folks will naturally prefer this to “keyboard-compatible” options and this should be fine (though ask many non-Anglophone users where the `$` key is and they won't be able to tell you). With Vim digraphs, Kitty unicode input, extra layers on a keyboard… there are many ways to tackle the ‘input hard’ problem. A good example of this is Dhall where Unicode is optional, but could be enforced with a built-in formatter option.
The initial presentation of Kotlin at Google I/O used fonts with ligatures. As a result, many people in the audience were confused about what the actual syntax of the language was.
I've personally never heard of anyone having a problem with my ligature preferences (other than "they're weird"). People know ≠ and != mean the same thing.
But a presentation introducing syntax? That's just silly. I can't believe someone would get that wrong.
TBH, remote pairing in my experience is best done with a tool like upterm or tmate so the user can bring their own terminal toolbox (fonts, colors, settings) and it saves a lot of bandwidth too while remaining crisp, especially when text becomes compressed and hard to read.
This isn’t a viable option because a) it forces a specific editor on users and b) it’s buying into Microsoft’s proprietary ecosystem (tracking, plugins, etc.).
There was one occasion when, by some unknown reason, >= rendered as > for me in browser. You increase/decrease font size and everything was ok, but I was extremely confused when colleague sent me a screenshot when after I commented in code review. Also there were issues with formatting of ligatures of some fonts in kitty terminal.
Other than that, ligatures are great and I will never turn them off.
Practical Typography is a really good website that is worth reading end to end. It's exactly what the name says: a short, straightforward introduction to typography for practical use.
I gotta say I’m a little tired of using * for multiplication. It’s time for programming languages that use Unicode characters for operators, and let the editor replace != with the Unicode slashed equals character. No ligatures, just operators.
There are really two separate issues here - ligatures in the classic typographic sense, such as æ, and having some way to type mathematical symbols useful in programming, such as ≠ and ⨯, without having cntl-alt-meta-super keyboard combos to remember.
The former doesn't help in programming. The latter is fairly standard for ideographic languages, and has been well worked out for Chinese and Japanese.
> has been well worked out for Chinese and Japanese.
Not really. Typing CJK text is a tedious and frustrating experience. People cope with it because no one has come up with a better alternative.
Both Chinese and Japanese alphabets have way too many characters to fit on a keyboard. To deal with this, CJK users type in the English spelling and convert it to CJK characters using software called input method editors (IMEs).
The problem is, this conversion process is often not straightforward. Unlike English, CJK sentences don't have spaces in them so IMEs have to guess how to split sentences into words. Then, it has to identify the right words, which is complicated due to the existence of homophones.
To deal with all the ambiguity involved in this conversion process, IMEs rely on predictions to provide users with a list of possible conversion candidates.
This leads to an awful typing experience in which users have to constantly choose from the IME-provided list for every little snippet of text. This is distracting, slows down typing, and makes key presses non-deterministic. To make matters worse, IMEs sometimes get things wrong and users have to get "creative" to work around it.
In comparison, typing English text is a breeze. You can just type what you want directly.
Maybe programmers just need to know that ligatures exists. If you are programming in Java or Kotlin you know that intelliJ tend to use it.
Of course, if you have code, coping it to an ide with ligatures disabled will be rendered there old way just add it will use your preferred font or color highlighting schema.
So most of the problems are for images like slides.
No you don’t have a code base with both operators. Either the editor catches it, or you transform the data at commit time, the same with other code formatters. This isn’t a new idea I’m presenting, just a new wrinkle on a very old one.
> let the editor replace != with the Unicode slashed equals character
Julia editor plugins let you do that - not an automatic replacement, but you can type the Latex for a symbol and press <Tab>, for eg. `\ne<Tab>` to get `≠`.
I suppose there could be an automatic-replacement mode, for those that have exact ASCII equivalents. So that, for eg., the editor replacing `!=` in your code with `≠` doesn't affect anyone else, because they're exactly equivalent and others can continue using `!=` if they prefer that.
I have absolutely no idea how many people might share print screens of their code, and how often some beast looking at these images might, because of that, find a way to discover how to type a similar looking symbol in unicode, enter it in their editor, and compile it without error, therefore introducing a subtle bug.
Luckily I rarely share my code through pdf, but mostly through git. Therefore, that hypothetical beast will read the code through its own editor, so the risk is mostly avoided. There is still the risk that this beast might appear behind my shoulders, see the pretty symbols and start that process anyway, but I have no idea how often that might happen too.
It's a weird thing that this beast can do such an elaborate process, but not ask a question about what the symbols are.
For better arguments, there's a long history of problems with programming languages that use non-ASCII symbols as default, and it has been considered a mistake.
That crazy idea of 'letters' that look alike and thus introduce bugs is much worse with unicode than ligatures:
>>> a = "hello world"
>>> b = "hеllо wоrld"
>>> a == b
False
Example from "Unicode text spoofer":
>This browser-based utility fakes regular characters in text and replaces them with Unicode characters from other alphabets. The text that you paste or enter in the input text area automatically gets all possible characters replaced with Unicode homoglyphs in the output. You can spoof letters, punctuation marks, spaces, and even insert zero-width spaces between individual symbols.
Now imagine instead of doing this, you use hello_world as variable name. You can thus interleave use of different variables that look alike, and have really buggy code.
Last argument, which is the one most important to me. Typing <= or != is ugly as shit.
That is not how these symbols are supposed to look like, it's just a practical kludge.
Ligatures are a simple solution to have both, that do not require a revolutionary way to change programming languages, and only engage yourself.
To share print screens of code without ligature maybe configure a second editor with another font. That does not sound really hard...
You don't kill good design just because it can be misused, you improve tooling design to deal with misuse
For example, the text spoofer issue can be resolved in the text tools, like having variables with different names can be colored differently (this coloring scheme is better than having color just denote variable even without spoofing as it allows you to catch typos easily)
Also you can have zero-width spaces highlighted
> having variables with different names can be colored differently
This, too, is entirely personal preference. I've tried it and found it resulted in too many colors for my brain to assign individual meanings to, and then I couldn't even benefit from syntax highlighting anymore because those colors also blended into the rainbow of text.
The differentiation benefit is not. Personal preference is what tool you choose to deal with spoofing, eg, you could also use a different font for different symbol ranges instead of colors.
> I've tried it and found it resulted in too many colors for my brain to assign individual meanings to
Well, you don't assign individual meaning to individual colors, but to color ranges which a given type can vary over. For example, going from green to yellow could be the range for variable names, so you associate that range with variables
The ones that just look like regular code with fine tuned spacing are nice.
The rest are terrible. Especially if you don't have a math background. If you come from coding, the symbols are meaningless new inventions. To me, >= IS exactly the right symbol. It's the one I learned, the one I actually encounter in daily life, anything else looks like a math paper, not code.
Even emoji aren't the best if you didn't type them explicitly. :) is mostly similar to although not exactly the same, but :P is definitely nothing like any of .
Edit: apparently emoji don't work here again? I thought they added them?
I don’t agree. I find that ligatures in Fira Code make it rather more pleasant to read contrived pieces of JavaScript (I’m looking at you, “===“). But to each his own.
=== and !== are definitely the main reason I tried out ligatures in the first place.
The author has hidden their point all the way at the end of the article, though. They're mostly talking about sharing code, such as in screenshots, printed works, slides, etc.
People who don't know fonts commonly use ligatures (plenty of fonts that mess with fi or other commonly custom kerned characters) so they don't realise I'm not actually using the ≠ or ≥ characters in my code.
I don't mind the look of ligatures too much in most monospace fonts that have them. However, I use my editor and terminal emulator for a lot more than just editing source code in common programming languages. In every single ligature-supporting font I've tried, there are edge cases where glyphs are combined in a way that don't make sense in context, which is jarring enough to not be worth it for me.
I don't think that needs to be the case. Text editors already do syntax highlighting, and if using treesitter they have accurate understanding of the syntax. So there isn't major blockers for applying ligatures selectively based on syntax.
It might be possible in code because it's more constrained enviroment but well it hasn't been solved in general typesetting. The rules are very hard to hardcode because it is subjective and often requires broad context (like understanding line above or what you do with names). Thats why it has been always done by humans if you want good results. And its not like smart people havent tried (like Knuth for example).
> “What do you mean, it’s not a matter of taste? I like using ligatures when I code.” Great! In so many ways, I don’t care what you do in private. Although I predict you will eventually burn yourself on this hot mess...
I've been using programming fonts with ligatures for years. I had wasted several hours because of those stupid bugs when I mixed up O and 0, - and _, but ligatures never caused me any problem. It is obvious when they are there, and you rarely see non-ascii characters when programming (unless you are writing Lean).
> Whereas ligatures are going the opposite direction: making distinct characters appear to be others.
Yes. On my computer. In my editor. That I am using…because I like ligatures, because they make my code easier to read. For me.
Use of ligatures on my setup does not force anyone else to use them? They’re not “viral” like a language feature.
“Oh but what if the >= Unicode symbol ends up in your source code and you don’t notice because you’re using ligatures?”
Is this the most contrived issue ever? Yeah and what if someone runs “find and replace” using Unicode confusables on my codebase? That’s arguably worse and requires no special font features. Plus I suspect most programming languages would throw an error immediately if you used the >= symbol instead of the pair.
If you don’t like ligatures, that’s fine, but there are those of us that do, and our font preference isn’t a threat to you.
> Yes. On my computer. In my editor. That I am using…because I like ligatures, because they make my code easier to read. For me.
Later in the submission, Butterick addresses this directly, and doesn't disagree:
> “What do you mean, it’s not a matter of taste? I like using ligatures when I code.” Great! In so many ways, I don’t care what you do in private. Although I predict you will eventually burn yourself on this hot mess, my main concern is typography that faces other human beings. So if you’re preparing your code for others to read—whether on screen or on paper—skip the ligatures.
Later, in the "by the way" section after the article. After an article that in no way suggests it's talking about printed and shared code exclusively. After paragraphs such as this
> Bottom line: this isn’t a matter of taste. In programming code, every character in the file has a special semantic role to play. Therefore, any kind of “prettifying” that makes one character look like another—including ligatures—leads to a swamp of despair. If you don’t believe me, try it for 10 or 15 years.
The submission reads very much like an attack on any use of ligatures in code. The comment in the end reads, to me, more like a resignation of responsibility over his claims.
It's not an "attack". It's an argument against. "Attack" implies some sort of animus directed against the recipient; e.g. an attack on unhoused people, etc. An attack implies violence.
An argument, even one with strong language, can be about whether or not a tool is fit-for-purpose. This is allowed. This is discourse.
Right now, politically, a lot of arguments are actually attacks (on specific groups of people) in disguise, and I sympathize with your confusion. But arguments do exist. Not every argument is an attack.
When I check someones your code and edit it, I get plain text - no ligatures, fonts, highlighting, themes, etc are included. I don't know what dev setup forces visual choices on coders, but that sounds like bad idea...
> ... if you’re preparing your code for others to read—whether on screen or on paper—skip the ligatures.
Here he's referring to code in books, slide decks, and during presentations, not for editing.
Just below the section the above quote is pulled from, Butterick explains
> One inspiration for this piece was the LaTeX crowd, who would routinely write me to insist their typography was infallible. And yet. I kept seeing LaTeX-prepared books that incorrectly substituted curly quotes for backticks.... “But code samples like these aren’t really ambiguous, because everyone knows that you don’t type the curly quotes.” ... But many of today’s programming languages (e.g., Racket) accept UTF-8 input.... So ambiguity is a real possibility. Same problem with ligatures.
Hmm, maybe suboptimal for publishing. That said most publications i read have no code but beautifully rendered equations. I find these more efficient at getting the point across than code… but i guess mileage vary
I tried coding in a variable font. It was horrible. I couldn't read the code. I was shocked at how much my brain made use of the spacing to parse code.
It's weird in a way, because there isn't all that much alignment going on in my code[1]. There's indentation, but that still works with a proportional font. And yet, it still looks wrong and hard to read. I can't really figure out why.
[1] I know some people align assignments in multiple lines, or comments at the end of the line, or similar things. I've been working under code style directives that prohibited those because lines changed more often because of whitespace than because of content. Since my work requires me not to do that, I don't have the habit at home either.
Code really is not prose! We use so many skinny punctuation marks that have big structural significance, and variable-width fonts de-emphasize them. I want my commas and brackets made clear and obvious, please.
I did actually spend a year or two coding in a variable-width font, back in the '90s, but I switched back after the novelty wore off.
> Btw., anyone still using monospaced fonts in their editors?
Tell me you've never programmed without telling me you've never programmed… Almost all code editors and IDEs in current use are set with a monospaced font by default, and the overwhelming majority of programmers keep it that way.
Ligatures don't change the spacing. Those 2 monospaced characters still take up 2 spaces but are rendered as 1 glyph. Your code is still monospaced in all the ways that matter.
I think that is a stylistic decision to make it appear as if, but again, this ain't monospace any longer.
In monospace one letter/symbol (printable character) has constant width.
The ligature is one letter/symbol. so while the stylistic decision retains the monospace style of the replaced symbols, the ligature itself is double (or triple) sized compared with other symbols.
Whether that is considered an issue or not is merely in the eye of the beholder.
E.g. a compacting ligature for "www" seems to be welcome in some typefaces for coding. But again, only to stress the reminder: It ain't monospace any longer.
We do still may prefer for the typesetting pleasantry that it still is styled as monospace (or fixed width). but those ligatures aren't fixed width any longer as with the letter A, that's all.
This is the difference between what it looks like (two or three glyphs) and what it is (a single glyph). So we break monospace to keep it appearing fixed-width even with the ligatures.
Would be interesting if there is more typesetting theory about the width of ligatures in a monospace font.
Here's how monospace ligatures work in real life: the width of a glyph is strictly proportional to how many ASCII bytes it represents. A 1-byte glyph like `m` gets 1 cell. A 2-byte glyph like `->` gets 2 cells. A 3-byte glyph like `===` gets 3 cells.
1 ASCII byte, 1 cell. That way ligatures don't change the width of the original text. If a line used to require 42 columns, it still requires 42 columns. That's why we call them "monospace": each ASCII byte requires the exact same width, even when it's part of a ligature.
> a compacting ligature for "www" —
Is obviously out of scope. We're discussing monospace ligatures here, not compacting ones.
The only people I've ever seen or heard of using proportional fonts for programming were utterly clueless freshmen newbs who mistook MS Word for a text editor...
Flash also come with a proportional font by default in the ActionScript
editor if I remember correctly. I believe
Adobe has changed its mind for other products with scripting support.
Ligatures in a fixed width programming context still take up the full width of the separate characters, so a unicode symbol of the ligature has a different width from the ligature itself, and this is immediately obvious.
Exactly. I recently started to write some LEAN which uses a ton of Unicode characters and I still use JetBrains Mono with ligatures on. ≠ is 1 unit wide but != is 2 units wide, so it's not that confusing as one might think.
Besides, if someone insists, it's also possible to make a language-specific setting in the editor to disable ligatures in those languages :)
On the other hand, this is one aspect that makes those ligatures typographically jarring to me. It replaces one compromise with another bad compromise.
> The other inspiration for this piece were the people who repeatedly asked me when Triplicate would get ligatures, Powerline characters, and so on. Answer, as nicely as possible: never.
So the answer is, for the same argument. Not going to happen with that typeface, by the authors design.
(2) context is super easy to apply, an editor can very reasonably enable or disable ligatures depending on where they are in the code: sublime text does this already
> For instance, the example below is from Kent Dybvig, The Scheme Programming Language, 4th ed. In this chunk of Scheme code, the opening-quote marks are supposed to be backticks; the closing-quote mark is supposed to be a single straight quote:
Sorry, as a Lisp person, I don't see the problem. In Dybvig's typography, it's evident that an opening quote which looks like a 6 is the quasi-quoting backquote, and the closing quote is the regular quote.
It is legitimate for the apostrophe to appear as either a vertical tick or a 9 shape:
Evidently, the 9 shape is the "typographic form" whereas the straight tick is "typewriter". The last paragraph of that section claims that this was a simplification for typewriters so that the glyph could fulfill multiple roles at the same time (including, possibly, simulating an exclamation mark, if overlaid over a period!)
In the USASCII system, there is only one character code for this, so in a given font, you get only one or the other. In a font where the ' character looks like a 9, you want ` to look like a 6. Or else if ' looks like a vertical stroke, then ` looks like a backward-slanted stroke of a size which harmonizes with that one.
It looks like the printed version of Dyvbig's book has a font which is typewriter-like, but uses the typographic form for these glyphs (thus undoing the hack that was perpetrated for the sake of typewriters). It's quite readable; there is no mistaking the forward tick for the backtick.
I think it's deeply personal and some fonts just do it better than others.
I tried for a while and it had pros and cons. Unfortunately it made me be confused one time too many so I reverted to not using ligatures.
Point is, find what works for you, we don't have to debate about this, and thankfully, we don't commit that stuff so that it becomes flame wars like tabs and spaces.
Ligatures are an interesting contrast to Julia programmers' habit of using actual (non-Latin) Unicode characters in their code. It seemed to me that the use of Greek letters and symbols is actively encouraged in the Julia documentation. I think they advise using editors that allow inputting special characters through their LaTeX equivalent (but source files are then saved to disk with the Unicode characters).
I am not very familiar with the latest trends, could anyone else chime in here? Do Julia coders use fonts with ligatures? That could indeed be one case where confusion is possible. Or maybe not?
I'm not familiar with Julia, but I think a useful distinction can be made between input methods and ligatures. An input method is what you have to type to get a particular "code point" or character. Japanese, for example, is often typed using a latin keyboard, and as latin characters are typed, the application substitutes the appropriate Japanese character code point. For example, if I type the characters "n" (U+006E) and "i" (U+0069) using a Japanese input method, a に (U+306B HIRAGANA LETTER NI) (or 二 U+4E8C CJK UNIFIED IDEOGRAPH-4E8C or ニ U+30CB KATAKANA LETTER NI, or others as the case may be) can be selected to be entered. The actual character bytes will be substituted. You typed "n" and "i" but what gets stored is U+306B.
This is in contrast to ligatures: say if there's a fi ligature, I type "<" "=", and the "≤" character is substituted during rendering, but the individual characters are still the "character string". (You could also choose to directly insert the "≤" character directly, and that would then be a single code point, but I think for the purposes of this discussion, people are mostly talking about cases such as when the character string "<=" is rendered as "≤".
If Julia (like APL) uses characters outside the ASCII range as syntax, I suspect that there are input methods to assist in entering them as opposed to ligatures representing them on screen. But that's just naïve supposition on my part.
Another interesting case is TLA+ [1], where the language shares some LaTeX operators which can be rendered for display.
A lot of Julia folks use the JuliaMono font, which has a minimal set of ligatures: https://juliamono.netlify.app/#contextual_alternates (just above this segment, they mention this very article as something they agree with).
I personally don't like any ligatures, especially when people use them in presentations to public like the article mentions. Confusion between operators is rare, but possible, for eg. when using Catalyst (https://docs.sciml.ai/Catalyst/stable/catalyst_functionality...).
> It seemed to me that the use of Greek letters and symbols is actively encouraged in the Julia documentation.
I don't remember getting that sense from the docs, but I may be wrong. The general convention is that Unicode at the level of user code is fine, and a lot of the community (including me) likes it because it makes it much closer to the actual equations and scientific notation we're working with. For libraries, it's strongly encouraged to have ASCII equivalents for any Unicode operators, keywords, etc. that you expose, and all the major libraries do this. The same is true in base Julia as well, every non-ASCII Unicode name has an ASCII equivalent too.
You know what, I'd tried JuliaMono in my editor (gVim) and for some reason didn't like it there, but making it my console font makes my terminal look so much better. Thanks for the recommendation.
It's definitely a slightly quirky font. It took me a bit to decide that I like it, but after a bit, I've gotten pretty used to it and it has become my default mono font.
> if you’re preparing your code for others to read—whether on screen or on paper—skip the ligatures.
The article should have led with this. Instead this main caveat is buried in a paragraph, where it is preceded by, what boils down to, "do what you want, but you will recognize its wrong someday." Of course people will focus on that part and on the most prevalent use of ligatures in programming: In their own local editor. (Where people usually have strong opinions about what's the right thing to do.)
The tangent in (1) on how they contradict unicode could have been skipped as well, just go straight to the "the problem is" part. Why? Unicode already "contradicts" itself: △ is WHITE UP-POINTING TRIANGLE (trine) or U+25B3, which I am sure everyone can easily distinguish from the mentioned Δ Greek Capital Letter Delta U+0394 especially when used outside a clear context. (There are other symbols that are easier confused, but I find them close enough for the point, especially because fonts might render them differently.)
For private use, I find ligatures make spotting negations and reading comparisons easier more often than they are wrong. But I see why ligatures might not be a good choice for a presentation or code blocks on a website.
You don't even have to go as far as a triangle. There are two sets of the latin alphabet in unicode and two sets of the greek. The normal one and the maths one. And the mu on your keyboard is not the same on a windows machine and a linux machine.
Yes, exactly, and Unicode has more encodings than UTF-8 so stating it explicitly makes clear which encoding of Unicode that is. Writing only ASCII would not be relaying on Unicode, but on ASCII only. IMHO a bit shortsighted today.
Using UTF-8 but only the ASCII bits, and using ASCII are the exact same activity, however. I don't see how the first is any different to the latter, other than which document you look up to tell you that 00110000 is "0". The difference between an "ASCII subset of UTF-8" parser and ASCII parser is whether the error message on encountering a high bit set to 1 is "Invalid character" or "Character not in permitted ranges".
If your point is that your program should use Unicode internally, this is already true for most programming languages but is independent of your input, plenty of languages routinely converting UTF-16 to UTF-8 to work with Linux or the web when they use UTF-16 internally, or UTF-8 to UTF-16 to work with Windows when they use UTF-8 internally. But I'd argue if you've done that work already, what harm is there in allowing your users to type € or á or 風?
> Using UTF-8 but only the ASCII bits, and using ASCII are the exact same activity, however.
Which was my point. The encoding might be different. For ASCII 7 bit is fine, for UTF-8 and only ASCII, 8 bits are required and, as you also already point out, the high bit must be set to zero with it.
So the point is to name the encoding (UTF-8) of the ASCII characters.
And the input was portable code, not user input of a program.
> The tangent in (1) on how they contradict unicode could have been skipped as well
Not only because confusables already exist, but also because (as I said[1] the previous time this was posted) covering all ligatures used in all typographical styles is very much a non-goal of Unicode. The official position is that the font shaping layer[2] sits atop Unicode’s semantic representation and is free to ligate, spindle, or mutilate it for display however it prefers (at least for Latin, Greek, and Cyrillic it’s a preference; other scripts can’t be rendered at all without doing it, such as Arabic—barring the legacy presentational forms—or Burmese[3]).
The only reason Unicode even has those ligatures is that some IBM encodings (which were more presentational in nature) encoded them, and the IBM employees who wrote a large part of the early standard (based on the decades of i18n experience they had at that point) wanted roundtripping.
Vscode highlights characters that might be confused for other characters if you use anything other than the common variant.
I'm not sure if this is default behavior or something I did to it over the years.
I can see it being helpful but it feels way too trigger happy. It's always notifying me about Hebrew letters that only look similar to other things if you take off your glasses, squint, and change the font.
Just reading all of this (I haven't used ligatures when coding), but the confusion between a ligature of >= and the Unicode ≥ (U+2265) could be handled by the language parser accepting either to mean "greater than or equal to".
Would moving beyond ASCII be that much of a stretch for modern languages?
Most modern languages already use Unicode for variable names and such. But why would you want to type a Unicode lte/gte character? I’m sure it’s not that hard on a Mac keyboard, but can’t be easier than <=
> Most modern languages already use Unicode for variable names and such
I've never actually thought about using comparative characters, but that actually makes a lot of sense. I think people will disagree if you use them, but there's no reason why you wouldn't be able to call a variable x≥y≤z…
You could make “>“ a dead character that combines with “=“ to “≥”. Then it’s just as easy to type (at the price of a verbatim “>=“ becoming slightly harder to type).
Note that the Raku Programming Language has pure ASCII equivalents for all operators as well, for the Unicode challenged. E.g. ≠ vs !=, ≤ vs <=, ≥ vs >= etc. etc.
A Compose key is the best general-purpose way. For example:
• ≥: Compose > =
• ≠: Compose / =
You can define your own sequences too, if you want. I like to type exactly what I mean, including curly quotes and dashes and narrow no-break spaces and emoji and so on, but often didn’t like the default mappings (if there were any). As an example, I use this for curly quotes (look at the keys’ locations on the keyboard to understand—it’s coherent):
(The only thing I can think of where I don’t normally type what I’d theoretically like to is hyphens, where I use ASCII’s HYPHEN-MINUS instead of the proper HYPHEN. I’ve never come up with a mapping I like—what with en dash, em dash, minus, &c.—and it’s also too common for fonts to lack a HYPHEN glyph.)
When you’re used to this sort of thing, it comes completely naturally.
When you’re used to it, and given the comparative infrequency of the characters you use it for, it’s not much of a burden—just ~three key presses instead of one.
> Really dont need an extra modifier key.
Note that Compose isn’t a modifier key in the most common understanding of the word: you don’t hold it down while you press the others (which would certainly be awful for its ergonomics), but you press keys in sequence.
> Not to mention there isnt one on your regular keyboard.
On my current laptop I map RAlt to Compose. On my previous laptop, it was RMenu. There’s always at least one key there that you literally never need to use, and I find the ergonomics for thumb usage very comfortable. (But I really wish Space was split into at least two keys. It’s so stupidly large.)
Microsoft's clumsy extension of IBM's short-sighted PC keyboard (and CUA) has a lot to answer for. It's too bad they didn't do a better job of ripping off either Apple keyboards or Unix workstation keyboards.
I personally use AltGr (Mac Option) more than compose, since it's tractable to have almost the same layout on *nix and Mac. IIRC the default Mac layout has ≠ and ≤ ≥ in the obvious places, and they are just as easily touch-typed as shifted characters.
Compose is nice (on xkb systems) in that it's very easy to add personal customization to ~/.XCompose for task-specific characters.
It’s not a modifier key, it’s a separate key you type before, like an escape character. I use the Caps Lock key for it.
For very common sequences that you always want to have mapped you can use a tool like AHK so that you don’t have to press Compose before.
The beauty of Compose though is that it works everywhere, and that it gives you access to a much larger character set in a very mnemonic way. For example, “ga” can map to “α” (“greek a”), “gb” to “β”, and so on. “2-” can map to “–“ (en dash), “3-“ to “—“ (em dash), “3.” to “…”, “c,” to “ç”, “i,” to “į”, “e,“ to “ę”, and so on. There are a lot of patterns that apply to a whole range of characters, it’s a bit like how commands combine in Vim.
This is a problem insofar as when searching for “>=“ or “≥“ you will only match one of them, and you are prone to getting a mix of both in your codebase. Ligatures effectively create a non-canonical rendering, and then adding a non-canonical alternate encoding doesn’t really improve the situation.
A proper way would arguably be for the programming language to only understand “≥“, and for editors to provide support for entering such characters (or the user can configure a system-wide Compose key or similar). IMO we should work on standardizing keyboard input for those symbols instead of de-standardizing code display via ligatures.
200 comments
[ 0.23 ms ] story [ 142 ms ] threadMinor issue mostly.
I tend to "no", but for no very good reason: Aesthetically they're lovely.
No, rather in your web page, in the slides that you're projecting, in the paper that you typeset into PDF...
The point is not about how you edit your own code. You could even write comments in sanskrit, if they are for your eyes only, but please don't dostribute them!
If it were properly studied, and it turned out that ligatures have an effect on the rate of mistakes, then one side of the debate would have to concede that though they choose persist in their personal taste, it is in conflict with what is good for their work.
Hmm...my programming language supports ≠ directly ...
> even lower chance to somehow type it by hand.
... and my keyboard lets me type it (almost) directly, via Alt-=.
I think the author is spot on in that the current state is not the correct end-state, though given path-dependencies it is understandable how we got here.
Ideally, languages would support Unicode as well so you can mean what you say when you type—some folks will naturally prefer this to “keyboard-compatible” options and this should be fine (though ask many non-Anglophone users where the `$` key is and they won't be able to tell you). With Vim digraphs, Kitty unicode input, extra layers on a keyboard… there are many ways to tackle the ‘input hard’ problem. A good example of this is Dhall where Unicode is optional, but could be enforced with a built-in formatter option.
But a presentation introducing syntax? That's just silly. I can't believe someone would get that wrong.
This seems a much more reasonable take
Or if you're screensharing while pairing, or if a coworker is looking over your shoulder when you're sharing something, or...
Ligatures in programming fonts: hell no (2019) - https://news.ycombinator.com/item?id=29637876 - Dec 2021 (195 comments)
Ligatures in Programming Fonts: Hell No - https://news.ycombinator.com/item?id=19805053 - May 2019 (86 comments)
Ligatures in programming fonts - https://news.ycombinator.com/item?id=14830797 - July 2017 (82 comments)
Other than that, ligatures are great and I will never turn them off.
The former doesn't help in programming. The latter is fairly standard for ideographic languages, and has been well worked out for Chinese and Japanese.
Not really. Typing CJK text is a tedious and frustrating experience. People cope with it because no one has come up with a better alternative.
Both Chinese and Japanese alphabets have way too many characters to fit on a keyboard. To deal with this, CJK users type in the English spelling and convert it to CJK characters using software called input method editors (IMEs).
The problem is, this conversion process is often not straightforward. Unlike English, CJK sentences don't have spaces in them so IMEs have to guess how to split sentences into words. Then, it has to identify the right words, which is complicated due to the existence of homophones.
To deal with all the ambiguity involved in this conversion process, IMEs rely on predictions to provide users with a list of possible conversion candidates.
This leads to an awful typing experience in which users have to constantly choose from the IME-provided list for every little snippet of text. This is distracting, slows down typing, and makes key presses non-deterministic. To make matters worse, IMEs sometimes get things wrong and users have to get "creative" to work around it.
In comparison, typing English text is a breeze. You can just type what you want directly.
- A character harder to type
- The same potential confusion
- Code bases with both operators
Maybe programmers just need to know that ligatures exists. If you are programming in Java or Kotlin you know that intelliJ tend to use it.
Of course, if you have code, coping it to an ide with ligatures disabled will be rendered there old way just add it will use your preferred font or color highlighting schema.
So most of the problems are for images like slides.
Julia editor plugins let you do that - not an automatic replacement, but you can type the Latex for a symbol and press <Tab>, for eg. `\ne<Tab>` to get `≠`.
I suppose there could be an automatic-replacement mode, for those that have exact ASCII equivalents. So that, for eg., the editor replacing `!=` in your code with `≠` doesn't affect anyone else, because they're exactly equivalent and others can continue using `!=` if they prefer that.
U+2062 is the obvious solution.
Luckily I rarely share my code through pdf, but mostly through git. Therefore, that hypothetical beast will read the code through its own editor, so the risk is mostly avoided. There is still the risk that this beast might appear behind my shoulders, see the pretty symbols and start that process anyway, but I have no idea how often that might happen too. It's a weird thing that this beast can do such an elaborate process, but not ask a question about what the symbols are.
For better arguments, there's a long history of problems with programming languages that use non-ASCII symbols as default, and it has been considered a mistake.
That crazy idea of 'letters' that look alike and thus introduce bugs is much worse with unicode than ligatures:
Example from "Unicode text spoofer": >This browser-based utility fakes regular characters in text and replaces them with Unicode characters from other alphabets. The text that you paste or enter in the input text area automatically gets all possible characters replaced with Unicode homoglyphs in the output. You can spoof letters, punctuation marks, spaces, and even insert zero-width spaces between individual symbols.Now imagine instead of doing this, you use hello_world as variable name. You can thus interleave use of different variables that look alike, and have really buggy code.
Last argument, which is the one most important to me. Typing <= or != is ugly as shit. That is not how these symbols are supposed to look like, it's just a practical kludge. Ligatures are a simple solution to have both, that do not require a revolutionary way to change programming languages, and only engage yourself. To share print screens of code without ligature maybe configure a second editor with another font. That does not sound really hard...
For example, the text spoofer issue can be resolved in the text tools, like having variables with different names can be colored differently (this coloring scheme is better than having color just denote variable even without spoofing as it allows you to catch typos easily) Also you can have zero-width spaces highlighted
This, too, is entirely personal preference. I've tried it and found it resulted in too many colors for my brain to assign individual meanings to, and then I couldn't even benefit from syntax highlighting anymore because those colors also blended into the rainbow of text.
The differentiation benefit is not. Personal preference is what tool you choose to deal with spoofing, eg, you could also use a different font for different symbol ranges instead of colors.
> I've tried it and found it resulted in too many colors for my brain to assign individual meanings to
Well, you don't assign individual meaning to individual colors, but to color ranges which a given type can vary over. For example, going from green to yellow could be the range for variable names, so you associate that range with variables
Which color ranges have you tried?
The rest are terrible. Especially if you don't have a math background. If you come from coding, the symbols are meaningless new inventions. To me, >= IS exactly the right symbol. It's the one I learned, the one I actually encounter in daily life, anything else looks like a math paper, not code.
Even emoji aren't the best if you didn't type them explicitly. :) is mostly similar to although not exactly the same, but :P is definitely nothing like any of .
Edit: apparently emoji don't work here again? I thought they added them?
The author has hidden their point all the way at the end of the article, though. They're mostly talking about sharing code, such as in screenshots, printed works, slides, etc.
People who don't know fonts commonly use ligatures (plenty of fonts that mess with fi or other commonly custom kerned characters) so they don't realise I'm not actually using the ≠ or ≥ characters in my code.
In text editors you can only go all in or not. It is not really intended for that.
I don't think that needs to be the case. Text editors already do syntax highlighting, and if using treesitter they have accurate understanding of the syntax. So there isn't major blockers for applying ligatures selectively based on syntax.
I've been using programming fonts with ligatures for years. I had wasted several hours because of those stupid bugs when I mixed up O and 0, - and _, but ligatures never caused me any problem. It is obvious when they are there, and you rarely see non-ascii characters when programming (unless you are writing Lean).
Yes. On my computer. In my editor. That I am using…because I like ligatures, because they make my code easier to read. For me.
Use of ligatures on my setup does not force anyone else to use them? They’re not “viral” like a language feature.
“Oh but what if the >= Unicode symbol ends up in your source code and you don’t notice because you’re using ligatures?”
Is this the most contrived issue ever? Yeah and what if someone runs “find and replace” using Unicode confusables on my codebase? That’s arguably worse and requires no special font features. Plus I suspect most programming languages would throw an error immediately if you used the >= symbol instead of the pair.
If you don’t like ligatures, that’s fine, but there are those of us that do, and our font preference isn’t a threat to you.
Later in the submission, Butterick addresses this directly, and doesn't disagree:
> “What do you mean, it’s not a matter of taste? I like using ligatures when I code.” Great! In so many ways, I don’t care what you do in private. Although I predict you will eventually burn yourself on this hot mess, my main concern is typography that faces other human beings. So if you’re preparing your code for others to read—whether on screen or on paper—skip the ligatures.
But it is interesting still, how many seem to read the text it feels to them touching their privates and need to make themselves vent off.
Not dissimilar to those choosing to highlight the worst aspects of comments rather than addressing them in good faith. Please don't make things worse.
> Bottom line: this isn’t a matter of taste. In programming code, every character in the file has a special semantic role to play. Therefore, any kind of “prettifying” that makes one character look like another—including ligatures—leads to a swamp of despair. If you don’t believe me, try it for 10 or 15 years.
The submission reads very much like an attack on any use of ligatures in code. The comment in the end reads, to me, more like a resignation of responsibility over his claims.
An argument, even one with strong language, can be about whether or not a tool is fit-for-purpose. This is allowed. This is discourse.
Right now, politically, a lot of arguments are actually attacks (on specific groups of people) in disguise, and I sympathize with your confusion. But arguments do exist. Not every argument is an attack.
I can't link to this book often enough: https://www.goodreads.com/book/show/29363252-conflict-is-not...
But metaphor is imprecision and unnecessary colour. Be clear and precise. Use specific language.
This is admittedly prescriptive usage, but I am prescribing this antidote for an overheated era, full of overwrought language.
Here he's referring to code in books, slide decks, and during presentations, not for editing.
Just below the section the above quote is pulled from, Butterick explains
> One inspiration for this piece was the LaTeX crowd, who would routinely write me to insist their typography was infallible. And yet. I kept seeing LaTeX-prepared books that incorrectly substituted curly quotes for backticks.... “But code samples like these aren’t really ambiguous, because everyone knows that you don’t type the curly quotes.” ... But many of today’s programming languages (e.g., Racket) accept UTF-8 input.... So ambiguity is a real possibility. Same problem with ligatures.
All right, oh my captain, keep the indents and spacing tight on the monospace and sail along!
Btw., anyone still using monospaced fonts in their editors?
The question is aren't you?
I'm not so sure if I want that, maybe I get dumb by it?!
It's weird in a way, because there isn't all that much alignment going on in my code[1]. There's indentation, but that still works with a proportional font. And yet, it still looks wrong and hard to read. I can't really figure out why.
[1] I know some people align assignments in multiple lines, or comments at the end of the line, or similar things. I've been working under code style directives that prohibited those because lines changed more often because of whitespace than because of content. Since my work requires me not to do that, I don't have the habit at home either.
I did actually spend a year or two coding in a variable-width font, back in the '90s, but I switched back after the novelty wore off.
Tell me you've never programmed without telling me you've never programmed… Almost all code editors and IDEs in current use are set with a monospaced font by default, and the overwhelming majority of programmers keep it that way.
No judgement if that is good or bad or at all. Just a reminder that it ain't monospace any longer.
> Your code is still monospaced in all the ways that matter.
Just it ain't monospace any longer. (reminder)
In monospace one letter/symbol (printable character) has constant width.
The ligature is one letter/symbol. so while the stylistic decision retains the monospace style of the replaced symbols, the ligature itself is double (or triple) sized compared with other symbols.
IIRC this is commonly called "monospaced ligatures" ref https://github.com/tonsky/FiraCode/issues/712
E.g. a compacting ligature for "www" seems to be welcome in some typefaces for coding. But again, only to stress the reminder: It ain't monospace any longer.
We do still may prefer for the typesetting pleasantry that it still is styled as monospace (or fixed width). but those ligatures aren't fixed width any longer as with the letter A, that's all.
This is the difference between what it looks like (two or three glyphs) and what it is (a single glyph). So we break monospace to keep it appearing fixed-width even with the ligatures.
Would be interesting if there is more typesetting theory about the width of ligatures in a monospace font.
1 ASCII byte, 1 cell. That way ligatures don't change the width of the original text. If a line used to require 42 columns, it still requires 42 columns. That's why we call them "monospace": each ASCII byte requires the exact same width, even when it's part of a ligature.
> a compacting ligature for "www" —
Is obviously out of scope. We're discussing monospace ligatures here, not compacting ones.
My fav sites on this topic: https://pixelambacht.nl/2015/sans-bullshit-sans/ https://www.sansbullshitsans.com/
Besides, if someone insists, it's also possible to make a language-specific setting in the editor to disable ligatures in those languages :)
Undoubtedly he made an argument for ligatures, but why are Powerline characters in the same basket?
> The other inspiration for this piece were the people who repeatedly asked me when Triplicate would get ligatures, Powerline characters, and so on. Answer, as nicely as possible: never.
So the answer is, for the same argument. Not going to happen with that typeface, by the authors design.
(2) context is super easy to apply, an editor can very reasonably enable or disable ligatures depending on where they are in the code: sublime text does this already
Sorry, as a Lisp person, I don't see the problem. In Dybvig's typography, it's evident that an opening quote which looks like a 6 is the quasi-quoting backquote, and the closing quote is the regular quote.
It is legitimate for the apostrophe to appear as either a vertical tick or a 9 shape:
https://en.wikipedia.org/wiki/Apostrophe
Particularly this section:
https://en.wikipedia.org/wiki/Apostrophe#Typographic_form
Evidently, the 9 shape is the "typographic form" whereas the straight tick is "typewriter". The last paragraph of that section claims that this was a simplification for typewriters so that the glyph could fulfill multiple roles at the same time (including, possibly, simulating an exclamation mark, if overlaid over a period!)
In the USASCII system, there is only one character code for this, so in a given font, you get only one or the other. In a font where the ' character looks like a 9, you want ` to look like a 6. Or else if ' looks like a vertical stroke, then ` looks like a backward-slanted stroke of a size which harmonizes with that one.
It looks like the printed version of Dyvbig's book has a font which is typewriter-like, but uses the typographic form for these glyphs (thus undoing the hack that was perpetrated for the sake of typewriters). It's quite readable; there is no mistaking the forward tick for the backtick.
I now want a programming font which has those.
I tried for a while and it had pros and cons. Unfortunately it made me be confused one time too many so I reverted to not using ligatures.
Point is, find what works for you, we don't have to debate about this, and thankfully, we don't commit that stuff so that it becomes flame wars like tabs and spaces.
"Huh? Why isn't this >= rendering as ligature?"
I am not very familiar with the latest trends, could anyone else chime in here? Do Julia coders use fonts with ligatures? That could indeed be one case where confusion is possible. Or maybe not?
This is in contrast to ligatures: say if there's a fi ligature, I type "<" "=", and the "≤" character is substituted during rendering, but the individual characters are still the "character string". (You could also choose to directly insert the "≤" character directly, and that would then be a single code point, but I think for the purposes of this discussion, people are mostly talking about cases such as when the character string "<=" is rendered as "≤".
If Julia (like APL) uses characters outside the ASCII range as syntax, I suspect that there are input methods to assist in entering them as opposed to ligatures representing them on screen. But that's just naïve supposition on my part.
Another interesting case is TLA+ [1], where the language shares some LaTeX operators which can be rendered for display.
[1]: https://lamport.azurewebsites.net/tla/tla.html
I personally don't like any ligatures, especially when people use them in presentations to public like the article mentions. Confusion between operators is rare, but possible, for eg. when using Catalyst (https://docs.sciml.ai/Catalyst/stable/catalyst_functionality...).
> It seemed to me that the use of Greek letters and symbols is actively encouraged in the Julia documentation.
I don't remember getting that sense from the docs, but I may be wrong. The general convention is that Unicode at the level of user code is fine, and a lot of the community (including me) likes it because it makes it much closer to the actual equations and scientific notation we're working with. For libraries, it's strongly encouraged to have ASCII equivalents for any Unicode operators, keywords, etc. that you expose, and all the major libraries do this. The same is true in base Julia as well, every non-ASCII Unicode name has an ASCII equivalent too.
The article should have led with this. Instead this main caveat is buried in a paragraph, where it is preceded by, what boils down to, "do what you want, but you will recognize its wrong someday." Of course people will focus on that part and on the most prevalent use of ligatures in programming: In their own local editor. (Where people usually have strong opinions about what's the right thing to do.)
The tangent in (1) on how they contradict unicode could have been skipped as well, just go straight to the "the problem is" part. Why? Unicode already "contradicts" itself: △ is WHITE UP-POINTING TRIANGLE (trine) or U+25B3, which I am sure everyone can easily distinguish from the mentioned Δ Greek Capital Letter Delta U+0394 especially when used outside a clear context. (There are other symbols that are easier confused, but I find them close enough for the point, especially because fonts might render them differently.)
For private use, I find ligatures make spotting negations and reading comparisons easier more often than they are wrong. But I see why ligatures might not be a good choice for a presentation or code blocks on a website.
(Alt Gr + m, at least in my language)
Unicode is a different code.
(and as I learned today, Julia code might be exclusive here)
If your point is that your program should use Unicode internally, this is already true for most programming languages but is independent of your input, plenty of languages routinely converting UTF-16 to UTF-8 to work with Linux or the web when they use UTF-16 internally, or UTF-8 to UTF-16 to work with Windows when they use UTF-8 internally. But I'd argue if you've done that work already, what harm is there in allowing your users to type € or á or 風?
Which was my point. The encoding might be different. For ASCII 7 bit is fine, for UTF-8 and only ASCII, 8 bits are required and, as you also already point out, the high bit must be set to zero with it.
So the point is to name the encoding (UTF-8) of the ASCII characters.
And the input was portable code, not user input of a program.
(Not making you look: U+0394 GREEK CAPITAL LETTER DELTA vs U+2206 INCREMENT)
Not only because confusables already exist, but also because (as I said[1] the previous time this was posted) covering all ligatures used in all typographical styles is very much a non-goal of Unicode. The official position is that the font shaping layer[2] sits atop Unicode’s semantic representation and is free to ligate, spindle, or mutilate it for display however it prefers (at least for Latin, Greek, and Cyrillic it’s a preference; other scripts can’t be rendered at all without doing it, such as Arabic—barring the legacy presentational forms—or Burmese[3]).
The only reason Unicode even has those ligatures is that some IBM encodings (which were more presentational in nature) encoded them, and the IBM employees who wrote a large part of the early standard (based on the decades of i18n experience they had at that point) wanted roundtripping.
[1] https://news.ycombinator.com/item?id=29639966
[2] https://github.com/n8willis/opentype-shaping-documents
[3] https://r12a.github.io/scripts/mymr/my.html#compositeV
I'm not sure if this is default behavior or something I did to it over the years.
I can see it being helpful but it feels way too trigger happy. It's always notifying me about Hebrew letters that only look similar to other things if you take off your glasses, squint, and change the font.
Would moving beyond ASCII be that much of a stretch for modern languages?
Unclear if it will ever be ubiquitous, but I'm betting on widespread in a couple decades.
And the most basic reason is because a dedicated symbol looks much better (and doesn't break vertical alignment since it's one glyph)
I've never actually thought about using comparative characters, but that actually makes a lot of sense. I think people will disagree if you use them, but there's no reason why you wouldn't be able to call a variable x≥y≤z…
[1] https://docs.julialang.org/en/v1/manual/mathematical-operati...
[2] https://docs.raku.org/language/operators.html
• ≥: Compose > =
• ≠: Compose / =
You can define your own sequences too, if you want. I like to type exactly what I mean, including curly quotes and dashes and narrow no-break spaces and emoji and so on, but often didn’t like the default mappings (if there were any). As an example, I use this for curly quotes (look at the keys’ locations on the keyboard to understand—it’s coherent):
(The only thing I can think of where I don’t normally type what I’d theoretically like to is hyphens, where I use ASCII’s HYPHEN-MINUS instead of the proper HYPHEN. I’ve never come up with a mapping I like—what with en dash, em dash, minus, &c.—and it’s also too common for fonts to lack a HYPHEN glyph.)When you’re used to this sort of thing, it comes completely naturally.
Somewhat more information: https://en.wikipedia.org/wiki/Compose_key
Not to mention there isnt one on your regular keyboard.
When you’re used to it, and given the comparative infrequency of the characters you use it for, it’s not much of a burden—just ~three key presses instead of one.
> Really dont need an extra modifier key.
Note that Compose isn’t a modifier key in the most common understanding of the word: you don’t hold it down while you press the others (which would certainly be awful for its ergonomics), but you press keys in sequence.
> Not to mention there isnt one on your regular keyboard.
On my current laptop I map RAlt to Compose. On my previous laptop, it was RMenu. There’s always at least one key there that you literally never need to use, and I find the ergonomics for thumb usage very comfortable. (But I really wish Space was split into at least two keys. It’s so stupidly large.)
If you can stand the tiny distant Return, get a Japanese keyboard.
I personally use AltGr (Mac Option) more than compose, since it's tractable to have almost the same layout on *nix and Mac. IIRC the default Mac layout has ≠ and ≤ ≥ in the obvious places, and they are just as easily touch-typed as shifted characters.
Compose is nice (on xkb systems) in that it's very easy to add personal customization to ~/.XCompose for task-specific characters.
For very common sequences that you always want to have mapped you can use a tool like AHK so that you don’t have to press Compose before.
The beauty of Compose though is that it works everywhere, and that it gives you access to a much larger character set in a very mnemonic way. For example, “ga” can map to “α” (“greek a”), “gb” to “β”, and so on. “2-” can map to “–“ (en dash), “3-“ to “—“ (em dash), “3.” to “…”, “c,” to “ç”, “i,” to “į”, “e,“ to “ę”, and so on. There are a lot of patterns that apply to a whole range of characters, it’s a bit like how commands combine in Vim.
You could even compile a bunch of them into a header file.
life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}
A proper way would arguably be for the programming language to only understand “≥“, and for editors to provide support for entering such characters (or the user can configure a system-wide Compose key or similar). IMO we should work on standardizing keyboard input for those symbols instead of de-standardizing code display via ligatures.