4 ms·

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 meaningf

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 9y ago
> 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-perl-6-and-you/ https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-p...
- seanmcdirmid 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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 9y ago
        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 9y ago
        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.
  - pdkl95 9y ago
    > Unicode sucks for this kind of thing, since eh go on disk It going to be hard to express the intent when programming if you never write that expression onto non-volatile storage. > break them up into multiple characters so they can be edited Several different methods exist for editing Unicode. (e.g. [1]) > As they are under control of the font, editors don't need special support either. That's exactly the problem. Most editors used for programming already understand the full syntax for many programming languages, while font-ligatures only match short character sequences. As the article mention, this will incorrectly replace some things that happen to share the same sequence of characters. There are also problems[2] in editors with storage or drawing boundaries in the middle of a ligature. Mapping the correct characters to a replacement glyph is a lot easier when you understand the surrounding grammar. [1] https://docs.perl6.org/language/unicode_entry https://docs.perl6.org/language/unicode_entry [2] The bug tracker for FiraCode has several reports of
- deleted 9y ago
  [deleted]
- Avshalom 9y ago
  Yeah, the APLer in me is strongly pro unicode, it's not like it would even be that hard for an editor to find di/tri/quadgraphs and replace it with a unicode glyph for when you just don't want to remember what incantation causes your keyboard to produce ⌹ (I'd go |:| for the trigraph).
  - pdkl95 9y ago
    > APL ... ⌹ I really wanted to learn APL after seeing Conway's Life implemented[1] as one expression with no loops or temporary variables (using ⌹). Then I realized I would never remember how to type all of the {di,tri}graphs. [1] https://www.youtube.com/watch?v=a9xAKttWgP4 https://www.youtube.com/watch?v=a9xAKttWgP4
    - Avshalom 9y ago
      it's... easier than you might think? about half of them are relatively mnemonic and most of the others are close to a mnemonic (∩ is on 'c' but ∪ is on 'v'). If your on linux you can say set the windows key to shift over to an APL key binding (it's always present in KDE, in gnome enter gsettings set org.gnome.libgnomekbd.desktop load-extra-items true at a terminal then it will show up in the input menu) and both Dyalog (free now for non-commercial use) and GNU APL (via Emacs) have secondary input methods until you get comfortable.

pdkl95 9y ago

> 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-perl-6-and-you/ https://perl6advent.wordpress.com/2015/12/07/day-7-unicode-p...

seanmcdirmid 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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 9y ago
        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.
- pdkl95 9y ago
  > Unicode sucks for this kind of thing, since eh go on disk It going to be hard to express the intent when programming if you never write that expression onto non-volatile storage. > break them up into multiple characters so they can be edited Several different methods exist for editing Unicode. (e.g. [1]) > As they are under control of the font, editors don't need special support either. That's exactly the problem. Most editors used for programming already understand the full syntax for many programming languages, while font-ligatures only match short character sequences. As the article mention, this will incorrectly replace some things that happen to share the same sequence of characters. There are also problems[2] in editors with storage or drawing boundaries in the middle of a ligature. Mapping the correct characters to a replacement glyph is a lot easier when you understand the surrounding grammar. [1] https://docs.perl6.org/language/unicode_entry https://docs.perl6.org/language/unicode_entry [2] The bug tracker for FiraCode has several reports of
deleted 9y ago
[deleted]
Avshalom 9y ago
Yeah, the APLer in me is strongly pro unicode, it's not like it would even be that hard for an editor to find di/tri/quadgraphs and replace it with a unicode glyph for when you just don't want to remember what incantation causes your keyboard to produce ⌹ (I'd go |:| for the trigraph).
- pdkl95 9y ago
  > APL ... ⌹ I really wanted to learn APL after seeing Conway's Life implemented[1] as one expression with no loops or temporary variables (using ⌹). Then I realized I would never remember how to type all of the {di,tri}graphs. [1] https://www.youtube.com/watch?v=a9xAKttWgP4 https://www.youtube.com/watch?v=a9xAKttWgP4
  - Avshalom 9y ago
    it's... easier than you might think? about half of them are relatively mnemonic and most of the others are close to a mnemonic (∩ is on 'c' but ∪ is on 'v'). If your on linux you can say set the windows key to shift over to an APL key binding (it's always present in KDE, in gnome enter gsettings set org.gnome.libgnomekbd.desktop load-extra-items true at a terminal then it will show up in the input menu) and both Dyalog (free now for non-commercial use) and GNU APL (via Emacs) have secondary input methods until you get comfortable.