I don't use ligatures only because the font is the wrong level of the stack for doing cute things like this. I could totally get behind e.g. combining `->` into a Unicode arrow, but if I'm writing the string `"->"` then I want that to be displayed verbatim. That requires parsing (or at least lexing) the code, which fonts can't do (and if they could, I'd be horrified). IMO, it should be the responsibility of editors and IDEs to do this sort of visual substitution.
While I realize '…' and '...' are syntactically equivalent, it means that if someone is writing $foo³ and I need to change that to $foo² - I can't do that without changing it to $foo**2 ... and that results in two different styles of code (unicode and ascii) in the same file which means that future maintainer me has more difficulty.
(note: I still don't know how to type ³ - that's me copying out of another file)
That feels to me that you're blaming a poorly implemented editor / IDE for a language feature.
If you use ² and ³ a lot in your work, I'm sure you can install a macro / keybinding / whatever to access them quickly.
And in any other case, https://docs.raku.org/language/unicode_ascii is a bit of a Rosetta stone in the cases you don't know how to type them, because you can copy / paste them from there.
I'm ok with APL doing all its special characters, but if you can write the same syntax in two ways, one of which is much more accessible than the other, then the less accessible way was a poor design choice.
Allowing for two styles for the same syntax can (and will) lead to multiple styles depending on who wrote that line. Conflicting styles (mixing tabs and spaces anyone?) in turn makes the maintenance of the code more difficult and time consuming which is something that is often forgotten in the rush to write code.
Totally agree. The worse is those long equal signs, with my eyesight going as I age I have to take close to a second to decipher if it's =, ==, or ===.