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.