3 ms·

Because for some reason terminals are stuck in the 70ies and don't accept those characters as quotes. Anything but ASCII trips them up. Seems such an obvious i

by brnt 7y ago

Because for some reason terminals are stuck in the 70ies and don't accept those characters as quotes. Anything but ASCII trips them up. Seems such an obvious interface to innovate, but it seems to run into terminal wizards sense of purity.

JdeBP 7y ago
The idea that "terminal wizards" reject this is rather undermined by the fact that "terminal wizards" made open and close double quotation marks accessible as simply [Group2]+[B04] and [Group2]+[B05] on an ISO 9995-3 conformant keyboard. Or [Shift]+[Option] [B04] and [Shift]+[Option] [B05] if there's no explicit [Group2] shift. Open and close single quotation marks use the same keys. "terminal wizards" have done quite the opposite of rejecting this.
samatman 7y ago
The problem, such as it is, is with languages. Terminals (mine at least) handle most of Unicode just fine; admittedly I've seen it choke on emoji, but punctuation, nah. The vast majority of programming languages are defined in terms of ASCII and only ASCII. I don't care for this, personally. I've given some thought to how to do quoting right in a programming language, and implemented «guillemets» as an experiment. But it's challenging, you need to decide what to do with all of “”‟„"″ and there aren't obvious pairings, like „this is a sentence” and “this is a sentence” and »this is a sentence» and «this is a sentence» and »this is a sentence«, it ends up feeling like rather a lot of effort for what you get in return. Oh, one of those characters I typed isn't a quotation mark, did you catch which one? Hacker news won't even let me type two of them!
- Santosh83 7y ago
  A language or interface is defined by the set of symbols mutually agreed upon. If you allow Unicode that number simply explodes, thus bloating and complicating the language/interface and its implementation as well. In effect it is no longer the same language but becomes a different, more complex one. The tradeoff is not worth it for programming languages the same way as learning all the scripts of the world is not worth it for one human being, just to accomplish tasks that don't need all these symbols in the first place.
- bmn__ 7y ago
  > I've given some thought to how to do quoting right in a programming language Already fully designed and implemented in Raku: https://docs.raku.org/language/unicode_entry#Smart_quotes https://docs.raku.org/language/unicode_entry#Smart_quotes Test online: https://tio.run/##K0gtyjH7//9Rw7ySjMxiBSBKVChOzStJzUtOfdQw9/9/AA https://tio.run/##K0gtyjH7//9Rw7ySjMxiBSBKVChOzStJzUtOfdQw9/...
- brnt 7y ago
  It is a solved problem however. We chose not tot use it (in terminals).
- emn13 7y ago
  Having multiple almost identical ways of achieving things is a bug magnet in programming languages. Differing programmers will presumably use different styles (why else even support differences?), and if you mix code like that, bugs ensue. This a hassle not just because autoformatters are liable to make churny changes (which distract from real changes, which makes history harder to understand: bug magnet), but also because people will make mistakes e.g. when find-replacing (another minor bug magnet!). Then there's the fact that some of those quotes aren't symmetric - so you need to think of something to have happen when they're unpaired or used incorrectly, and it wouldn't surprise me if no matter what you did, you surprise somebody (bug magnet!). Sure: these are all quibbles, and a language wouldn't die from all these minor cuts. But they're definitely downsides, not upsides. So: where is that upside? Why would you ever support something like this? "It looks a little nicer" sounds like a pretty weak argument compared to "it's inconsistent, hard to machine process, and may cause a few bugs"...
  - samatman 7y ago
    Many programming languages, certainly not all, offer single and double-quoted strings already. Which is, granted, a perennial source of annoyance for those of us trying to have a consistent formatting style. I want «guillemet strings» because they use a matched pair, so you can «quote a string «within a string» without escaping» and I think that's a nice property. I'm not really interested in supporting all the forms in which they're used in European languages, though, that would be a real hassle. Just the one that looks like the other matched pairs we use in programming. “smart quotes” have ‟at least two styles” and really „three styles”, and the first two are really easy to confuse with "normal double-quotes". I don't want my users to have to deal with "why doesn't this compile”?, and if I allowed it to compile, now you have to escape all the quote characters inside any string, which is messy. Raku, as a sibling points out, has bitten down on this bullet, and I respect that. I keep meaning to give it a spin, I'm fond of Parsing Expression Grammars and have good feelings about Perl from the early days.
    - zzo38computer 7y ago
      PostScript has something like the «guillemet strings», but it uses parentheses instead. The parentheses can be nested without escaping.
diffeomorphism 7y ago
That seems like an obviously bad solution. That is like writing [a(b{c]d}e) except that the quote characters look even more similar.
- brnt 7y ago
  Its easy (solved) to map Unicode to control characters such as quotes (and when you think about it, quotes are often there to deal with ambiguities stemming from the limited number of allowed characters in ASCII). So to could have a terminal accepting such input, and a few helper function that normalize it into ASCII and so on. After all, users of non-ascii languages (which is nearly everyone) already know how to deal with it without ambiguity. Its only ambiguous if you don't use encodings, and that should never happen anyway.
  - diffeomorphism 7y ago
    > and a few helper function that normalize it into ASCII and so on If you are going to get rid of it anyways, why bother with it in the first place? Also, you then have the ambiguity/problem whether some symbols are mapped to the same ones or not. > already know how to deal with it without ambiguity I wish. Just dealing with ü vs ue vs \"u and ascii, win something, utf8 and utf16 is still annoying in practice. Or latex choking on accents, non-breaking whitespace or similar fun stuff.
    - brnt 7y ago
      The argument to do it is it democratizes users with their scripts around the world (and solve the issue of having 'the wrong' quote). Normalization solves the latter. It's really solved, but you would never know if you live exclusively on the command line. Which I think is unfortunate.
      - diffeomorphism 7y ago
        I disagree, it simply tells everyone they are wrong and the "normalized" one is the right one. Oh, you used foo and föö as variable names, too bad those are the same now by normalization. > It's really solved, but you would never know if you live exclusively on the command line. Which I think is unfortunate. Tone down the condescension and insults, please.
pjc50 7y ago
The terminal can usually handle it, provided it's UTF-8. Most of the editors can handle it. It's very specifically the programming language specifications which don't include them. Even the ones that allow Unicode identifiers. Also, they're difficult to type - my keyboard has a " key but not a “ or ” character. I had to copy and paste those from the unicode website since I don't have a suitable input method set up.

by brnt 7y ago

JdeBP 7y ago

The idea that "terminal wizards" reject this is rather undermined by the fact that "terminal wizards" made open and close double quotation marks accessible as simply [Group2]+[B04] and [Group2]+[B05] on an ISO 9995-3 conformant keyboard. Or [Shift]+[Option] [B04] and [Shift]+[Option] [B05] if there's no explicit [Group2] shift. Open and close single quotation marks use the same keys. "terminal wizards" have done quite the opposite of rejecting this.

samatman 7y ago

The problem, such as it is, is with languages. Terminals (mine at least) handle most of Unicode just fine; admittedly I've seen it choke on emoji, but punctuation, nah. The vast majority of programming languages are defined in terms of ASCII and only ASCII. I don't care for this, personally. I've given some thought to how to do quoting right in a programming language, and implemented «guillemets» as an experiment. But it's challenging, you need to decide what to do with all of “”‟„"″ and there aren't obvious pairings, like „this is a sentence” and “this is a sentence” and »this is a sentence» and «this is a sentence» and »this is a sentence«, it ends up feeling like rather a lot of effort for what you get in return. Oh, one of those characters I typed isn't a quotation mark, did you catch which one? Hacker news won't even let me type two of them!

Santosh83 7y ago
A language or interface is defined by the set of symbols mutually agreed upon. If you allow Unicode that number simply explodes, thus bloating and complicating the language/interface and its implementation as well. In effect it is no longer the same language but becomes a different, more complex one. The tradeoff is not worth it for programming languages the same way as learning all the scripts of the world is not worth it for one human being, just to accomplish tasks that don't need all these symbols in the first place.
bmn__ 7y ago
> I've given some thought to how to do quoting right in a programming language Already fully designed and implemented in Raku: https://docs.raku.org/language/unicode_entry#Smart_quotes https://docs.raku.org/language/unicode_entry#Smart_quotes Test online: https://tio.run/##K0gtyjH7//9Rw7ySjMxiBSBKVChOzStJzUtOfdQw9/9/AA https://tio.run/##K0gtyjH7//9Rw7ySjMxiBSBKVChOzStJzUtOfdQw9/...
brnt 7y ago
It is a solved problem however. We chose not tot use it (in terminals).
emn13 7y ago
Having multiple almost identical ways of achieving things is a bug magnet in programming languages. Differing programmers will presumably use different styles (why else even support differences?), and if you mix code like that, bugs ensue. This a hassle not just because autoformatters are liable to make churny changes (which distract from real changes, which makes history harder to understand: bug magnet), but also because people will make mistakes e.g. when find-replacing (another minor bug magnet!). Then there's the fact that some of those quotes aren't symmetric - so you need to think of something to have happen when they're unpaired or used incorrectly, and it wouldn't surprise me if no matter what you did, you surprise somebody (bug magnet!). Sure: these are all quibbles, and a language wouldn't die from all these minor cuts. But they're definitely downsides, not upsides. So: where is that upside? Why would you ever support something like this? "It looks a little nicer" sounds like a pretty weak argument compared to "it's inconsistent, hard to machine process, and may cause a few bugs"...
- samatman 7y ago
  Many programming languages, certainly not all, offer single and double-quoted strings already. Which is, granted, a perennial source of annoyance for those of us trying to have a consistent formatting style. I want «guillemet strings» because they use a matched pair, so you can «quote a string «within a string» without escaping» and I think that's a nice property. I'm not really interested in supporting all the forms in which they're used in European languages, though, that would be a real hassle. Just the one that looks like the other matched pairs we use in programming. “smart quotes” have ‟at least two styles” and really „three styles”, and the first two are really easy to confuse with "normal double-quotes". I don't want my users to have to deal with "why doesn't this compile”?, and if I allowed it to compile, now you have to escape all the quote characters inside any string, which is messy. Raku, as a sibling points out, has bitten down on this bullet, and I respect that. I keep meaning to give it a spin, I'm fond of Parsing Expression Grammars and have good feelings about Perl from the early days.
  - zzo38computer 7y ago
    PostScript has something like the «guillemet strings», but it uses parentheses instead. The parentheses can be nested without escaping.

diffeomorphism 7y ago

That seems like an obviously bad solution. That is like writing [a(b{c]d}e) except that the quote characters look even more similar.

brnt 7y ago
Its easy (solved) to map Unicode to control characters such as quotes (and when you think about it, quotes are often there to deal with ambiguities stemming from the limited number of allowed characters in ASCII). So to could have a terminal accepting such input, and a few helper function that normalize it into ASCII and so on. After all, users of non-ascii languages (which is nearly everyone) already know how to deal with it without ambiguity. Its only ambiguous if you don't use encodings, and that should never happen anyway.
- diffeomorphism 7y ago
  > and a few helper function that normalize it into ASCII and so on If you are going to get rid of it anyways, why bother with it in the first place? Also, you then have the ambiguity/problem whether some symbols are mapped to the same ones or not. > already know how to deal with it without ambiguity I wish. Just dealing with ü vs ue vs \"u and ascii, win something, utf8 and utf16 is still annoying in practice. Or latex choking on accents, non-breaking whitespace or similar fun stuff.
  - brnt 7y ago
    The argument to do it is it democratizes users with their scripts around the world (and solve the issue of having 'the wrong' quote). Normalization solves the latter. It's really solved, but you would never know if you live exclusively on the command line. Which I think is unfortunate.
    - diffeomorphism 7y ago
      I disagree, it simply tells everyone they are wrong and the "normalized" one is the right one. Oh, you used foo and föö as variable names, too bad those are the same now by normalization. > It's really solved, but you would never know if you live exclusively on the command line. Which I think is unfortunate. Tone down the condescension and insults, please.

pjc50 7y ago

The terminal can usually handle it, provided it's UTF-8. Most of the editors can handle it. It's very specifically the programming language specifications which don't include them. Even the ones that allow Unicode identifiers. Also, they're difficult to type - my keyboard has a " key but not a “ or ” character. I had to copy and paste those from the unicode website since I don't have a suitable input method set up.