3 ms·

Using inequality signs as angled brackets really is a mistake isn't it...

by nialv7 2y ago

klodolph 2y ago
I’ll flip this around… reusing comparison as angle brackets is the mistake. C++ ran into some issues too. I think Rust made the really smart move of putting :: before any type parameters for functions. Go made the good move of using square brackets for type parameters.
- zarzavat 2y ago
  The problem can be traced back to ASCII/typewriters only including three sets of paired characters, plus inequality signs, which is not enough for programming languages. We really need five sets: grouping, arrays/indexing, records, type parameters, and compound statements. Curly braces {} are also overloaded in JS for records and compound statements, leading to x => {} and x => ({}) meaning different things. Square brackets wouldn't work for parametric functions because f[T](x) already means get the element at index T and call it.
  - xigoi 2y ago
    I think the D syntax would work: f!T(x)
  - behnamoh 2y ago
    Everytime a standardization happens, part of human creativity gets suppressed. Before ASCII, people were inventing all sorts of symbols and even the alphabet was flexible to changes. After ASCII, we got stuck with a certain set of letters and symbols. Heck, even our keyboards haven't changed that much since then. I really think we need more symbols than just &@$#%^*}{][<>()/\_~|
  - parasense 2y ago
    Paired characters... That's an interesting topic. Do you happen to know if UTF-8 contains more "pair" characters? In Latex we call these delimiteres, but that's just my limited experience coming in from math side. I tend to agree that it would be helpful to have more kind of nesting/pairing/grouping/delimiting characters. The problem is my imagination is limited to what I know from the ASCII world, and so it goes... no idea what new sets would look like.
    - pshc 2y ago
      So many different pairs are available. I like Asian corner brackets 「」and French guillemets « ». The angle brackets 〈〉 are popular in CS/math papers I think, though they might be confused with <>.
      - butwhynotTSR 2y ago
        I have had access to « » before, which led me to doing a double take when I first encountered a << on a work station with font ligatures. It was funny. Which brings us to the philosophical question about paired characters: If we were to pick paired characters from a key set not available on everyone's keyboard, why must the paired characters even be used in real languages? Is that not actually actively detrimental when we end up needing the characters for real? Is this not why we even have escape characters to begin with? Plus, must they be a part of anyone's real keyboard to begin with? What makes 「」any more valid than ¿? Could we not have saved ourselves a lot of mental strain if we solved it earlier on with a full set of truly uncommon characters? I can imagine an alternate history, where some programming language in the late 70's made their editors with simple shortcuts (such as Ctrl+A for "array block") to input barely-if-ever-used yet low code character such as † or ‡, which would never be used outside of a string. And nowadays, with modern IDE's, we wouldn't even see those characters half the time. It would be syntax sugar, with blocks types stated in gutters and data types represented with colors or text.
    - IshKebab 2y ago
      Sure, you can use Canadian Aboriginal Syllabics! https://www.reddit.com/r/rust/comments/5penft/comment/dcsq64p/ https://www.reddit.com/r/rust/comments/5penft/comment/dcsq64...
    - paulddraper 2y ago
      Nit: UTF-8 is a particular encoding. Unicode is a character system. UTF-8, UTF-16, UTF-32 all have the same characters.
  - klodolph 2y ago
    Five sets, but at any given place in the syntax, not all five are possible. (I would add function calls to the list—so, six.) In most languages, (grouping and compound statements) cannot syntactically appear in the same place as (indexing, records, type parameters, function calls). So we are immediately down to four. Rust takes the approach that you use :: before type parameters, so they are easily distinguished from comparison operators at a syntactic level. Go takes the approach that [] is just fine for type parameters—which seems pretty reasonable to me. In Go, there’s nothing that can be both indexed *and* take a type parameter.
    - zarzavat 2y ago
      > In Go, there’s nothing that can be both indexed and take a type parameter. True, but TypeScript has a rule against type-dependent emit - it’s not allowed. Code must always do the same thing regardless of what the types are. And in any case JavaScript does allow indexing on functions, since functions are just objects.
  - jenadine 2y ago
    There is also the possibility to use digraphs such as <: :> or other combinations. (And they could even converted to unicode by the code formatter)
- lolinder 2y ago
  I don't think you're flipping it around, I think that's exactly what OP was saying, just clearer.
jmull 2y ago
Mistake isn't the right word. It's just a tradeoff. There was no perfect solution available, so a tradeoff was necessary. You can disagree with this particular tradeoff, but had they gone another way some people would disagree with that as well. To be a mistake there would have had to have been an option available that was clearly better at the time. Anyway, the idea that TS 5 should be backwards compatible with TS 1 is probably a bad one. Personally, I think packages with wide usage break backwards compatibility far too easily -- it puts everyone who uses it on an upgrade treadmill, so it should be done very judiciously. But even I wouldn't argue that TS 1 should have been its final form.
SomeCallMeTim 2y ago
It's not a TypeScript mistake. You could argue that it was a C++ mistake. It makes parsing harder, but otherwise seems to work as expected, so I don't consider it a mistake, but you could at least argue that way. But regardless if it was a mistake in C++, it's now a complete standard, used in C++, Java, C#, and other languages to denote type parameters. I would argue that it would have been a mistake to break that standard. What would you have used, and in what way would that have been enough better to compensate for the increased difficulty in understanding TypeScript generics for users of almost every other popular language?
- vips7L 2y ago
  It's definitely the right choice for Typescript. You could have gone the Scala route and used [] for generics, but that is so heavily used in ts/js as arrays it would not have made any sense.

Using inequality signs as angled brackets really is a mistake isn't it...

by nialv7 2y ago

Using inequality signs as angled brackets really is a mistake isn't it...

I’ll flip this around… reusing comparison as angle brackets is the mistake. C++ ran into some issues too. I think Rust made the really smart move of putting :: before any type parameters for functions. Go made the good move of using square brackets for type parameters.

zarzavat 2y ago
The problem can be traced back to ASCII/typewriters only including three sets of paired characters, plus inequality signs, which is not enough for programming languages. We really need five sets: grouping, arrays/indexing, records, type parameters, and compound statements. Curly braces {} are also overloaded in JS for records and compound statements, leading to x => {} and x => ({}) meaning different things. Square brackets wouldn't work for parametric functions because f[T](x) already means get the element at index T and call it.
- xigoi 2y ago
  I think the D syntax would work: f!T(x)
- behnamoh 2y ago
  Everytime a standardization happens, part of human creativity gets suppressed. Before ASCII, people were inventing all sorts of symbols and even the alphabet was flexible to changes. After ASCII, we got stuck with a certain set of letters and symbols. Heck, even our keyboards haven't changed that much since then. I really think we need more symbols than just &@$#%^*}{][<>()/\_~|
- parasense 2y ago
  Paired characters... That's an interesting topic. Do you happen to know if UTF-8 contains more "pair" characters? In Latex we call these delimiteres, but that's just my limited experience coming in from math side. I tend to agree that it would be helpful to have more kind of nesting/pairing/grouping/delimiting characters. The problem is my imagination is limited to what I know from the ASCII world, and so it goes... no idea what new sets would look like.
  - pshc 2y ago
    So many different pairs are available. I like Asian corner brackets 「」and French guillemets « ». The angle brackets 〈〉 are popular in CS/math papers I think, though they might be confused with <>.
    - butwhynotTSR 2y ago
      I have had access to « » before, which led me to doing a double take when I first encountered a << on a work station with font ligatures. It was funny. Which brings us to the philosophical question about paired characters: If we were to pick paired characters from a key set not available on everyone's keyboard, why must the paired characters even be used in real languages? Is that not actually actively detrimental when we end up needing the characters for real? Is this not why we even have escape characters to begin with? Plus, must they be a part of anyone's real keyboard to begin with? What makes 「」any more valid than ¿? Could we not have saved ourselves a lot of mental strain if we solved it earlier on with a full set of truly uncommon characters? I can imagine an alternate history, where some programming language in the late 70's made their editors with simple shortcuts (such as Ctrl+A for "array block") to input barely-if-ever-used yet low code character such as † or ‡, which would never be used outside of a string. And nowadays, with modern IDE's, we wouldn't even see those characters half the time. It would be syntax sugar, with blocks types stated in gutters and data types represented with colors or text.
  - IshKebab 2y ago
    Sure, you can use Canadian Aboriginal Syllabics! https://www.reddit.com/r/rust/comments/5penft/comment/dcsq64p/ https://www.reddit.com/r/rust/comments/5penft/comment/dcsq64...
  - paulddraper 2y ago
    Nit: UTF-8 is a particular encoding. Unicode is a character system. UTF-8, UTF-16, UTF-32 all have the same characters.
- klodolph 2y ago
  Five sets, but at any given place in the syntax, not all five are possible. (I would add function calls to the list—so, six.) In most languages, (grouping and compound statements) cannot syntactically appear in the same place as (indexing, records, type parameters, function calls). So we are immediately down to four. Rust takes the approach that you use :: before type parameters, so they are easily distinguished from comparison operators at a syntactic level. Go takes the approach that [] is just fine for type parameters—which seems pretty reasonable to me. In Go, there’s nothing that can be both indexed *and* take a type parameter.
  - zarzavat 2y ago
    > In Go, there’s nothing that can be both indexed and take a type parameter. True, but TypeScript has a rule against type-dependent emit - it’s not allowed. Code must always do the same thing regardless of what the types are. And in any case JavaScript does allow indexing on functions, since functions are just objects.
- jenadine 2y ago
  There is also the possibility to use digraphs such as <: :> or other combinations. (And they could even converted to unicode by the code formatter)
lolinder 2y ago
I don't think you're flipping it around, I think that's exactly what OP was saying, just clearer.

jmull 2y ago

Mistake isn't the right word. It's just a tradeoff. There was no perfect solution available, so a tradeoff was necessary. You can disagree with this particular tradeoff, but had they gone another way some people would disagree with that as well. To be a mistake there would have had to have been an option available that was clearly better at the time. Anyway, the idea that TS 5 should be backwards compatible with TS 1 is probably a bad one. Personally, I think packages with wide usage break backwards compatibility far too easily -- it puts everyone who uses it on an upgrade treadmill, so it should be done very judiciously. But even I wouldn't argue that TS 1 should have been its final form.

SomeCallMeTim 2y ago

It's not a TypeScript mistake. You could argue that it was a C++ mistake. It makes parsing harder, but otherwise seems to work as expected, so I don't consider it a mistake, but you could at least argue that way. But regardless if it was a mistake in C++, it's now a complete standard, used in C++, Java, C#, and other languages to denote type parameters. I would argue that it would have been a mistake to break that standard. What would you have used, and in what way would that have been enough better to compensate for the increased difficulty in understanding TypeScript generics for users of almost every other popular language?

vips7L 2y ago
It's definitely the right choice for Typescript. You could have gone the Scala route and used [] for generics, but that is so heavily used in ts/js as arrays it would not have made any sense.