6 ms·

Await is a keyword, syntax highlighters will most likely paint it differently.

kbenson 7y ago
I find the syntax highlighting argument odd. It's like arguing a road surface is acceptable because the dangerous conditions it causes are mitigated by traction control.
- burntsushi 7y ago
  I find the don't-consider-syntax-highlighting-at-all argument odd. It's like arguing traffic lights shouldn't use colors to indicate stop-and-go because some people either cannot perceive the color difference or choose to wear glasses that negate the color difference. (Analogies here suck. Instead, consider that the vast majority of programmers read code that has been syntax highlighted. To completely discount that experience at all would be odd.)
  - kbenson 7y ago
    > It's like arguing traffic lights shouldn't use colors to indicate stop-and-go because some people either cannot perceive the color difference or choose to wear glasses that negate the color difference. There is a reason that we have three separate lights still instead of one (that is, there's more reasons than just inertia), and that's because some people can't tell the color differences. Specifically, my father can't easily tell the color difference between green and yellow. I've had friends that also had this problem. It's not uncommon. > To completely discount that experience at all would be odd I'm not saying to discount it entirely, but consider it in context. I think it's a somewhat elitist argument, because it assumes everyone both has syntax highlighting set up and that their highlighting will work as well as yours. I accept that syntax highlighting helps, and is a positive if it can be applied well to a solution, I just think it's far from sufficient. Put another way, an optional, environment specific configuration setting is not sufficient to offset the negative aspects of an official language level feature, if we're able to weigh things prior to being implemented. If Rust were required (or even officially expected) to be written in an environment where that was always available and easily configurable, I would think different. E.g. if we're talking about Visual Basic, or Smalltalk with it's IDE (IIRC, not that I have experience with it), then I would think different, but as long as the Rust compiler is expected to take in files of text and not some rich format that includes extra metadata, I don't think language design choices should weigh non-text considerations too heavily.
    - pjmlp 7y ago
      Given that my first syntax highlighting experience was Turbo Pascal 7.0 for MS-DOS, it always feels odd to see it disabled. And we aren't in the late 70's anymore, where languages had design decisions (keywords always caps) due to printing limitations.
    - burntsushi 7y ago
      > but consider it in context Which is exactly what has been done. So I don't understand what you're complaining about. The rest of your comment is a giant straw man. I've never heard of or seen implied that anyone in any decision making position in the Rust project is "assuming everyone has syntax highlighting set up." When you make ridiculous assumptions about the decision procedures of other people, then it's easy to derive ridiculous conclusions. But reality is always more nuanced than that: https://news.ycombinator.com/item?id=20031706 https://news.ycombinator.com/item?id=20031706
      - kbenson 7y ago
        I never made an argument about the Rust project assuming that. I'm talking about people using the availability syntax highlighting to dismiss a negative aspect of a possible choice. I was making that argument in general, but spurred by a specific comment here. I used the context of the Rust community discussion as an example, but never did I assume Rust was using this as a metric (just noting that it has been put forth in arguments from the community). My argument at this point (as illustrated by the Rust discussion) is simply: - Rust/rustc takes in unicode text as source - Since it has no knowledge at the source level of syntax highlighting, using that to mitigate the downside of a language level syntax for a feature is problematic - We as the public should keep that in mind when discussing the relative merits of one possible implementation or another of a feature. That's not denigrating or assuming Rust actually did this, it's a note about the community level discussion and how some people approached it, as evidenced by a very specific comment in this thread, and how I thought it had some problems when applied to language level decisions.
        burntsushi 7y ago
- dllthomas 7y ago
  I think it's totally reasonable to judge a road surface based on how effective it is, in practice, with the kinds of traffic that will be travelling on it. Traction control is a part of that landscape. Designing with awareness of syntax highlighting makes sense. But we should also keep an awareness that it won't always be there.
  - kbenson 7y ago
    > I think it's totally reasonable to judge a road surface based on how effective it is, in practice, with the kinds of traffic that will be travelling on it. Yes, and if we outlawed the use of cars without traction control on certain roads, then I would be fine with designing with the assumption traction control will be on. But as long as you allow older cars without traction control to still drive on the road, you are making the roads less safe for a certain percentage or class of drivers. I view that as different that just making the road safer for some. > But we should also keep an awareness that it won't always be there. Exactly. And this is why I think it doesn't make sense as a mitigation to a language level feature which will always be there. Specifically, I think syntax highlighting is a useful feature and a plus for a comparison, I just don't think it works as a mitigation for a negative for something that pervasive. All other things being equal, syntax highlighting abilities might push me towards one solution over another, but they won't make me ignore a problem I perceive with a solution.
    - dllthomas 7y ago
      I'm not sure if you read me as slightly more critical than I had intended or if I'm reading you as slightly more defensive than you'd intended, but I think we more-or-less agree: readability is important both with and without syntax highlighting, and tradeoffs should be considered in that light. A nitpick: > But as long as you allow older cars without traction control to still drive on the road, you are making the roads less safe for a certain percentage or class of drivers. Probably. But if a sufficient fraction of cars have traction control, and we sufficiently improve the performance of traction controlled tires at sufficiently small damage to the performance of other tires, the reduction in the threat of being hit by cars with traction control will outweigh the increase in risk of losing control for those cars without, even before trading off risk between cars (which is certainly more complicated). I don't think there's a direct mapping back to syntax and highlighting.
JoshTriplett 7y ago
Speaking as a member of the Rust language team: we specifically evaluated all syntax proposals on the assumption that many people may end up reading them without syntax highlighting. People read code in many places outside of a programmer's text editor or a code-highlighting web page, including logs, diffs, and emails.
- Touche 7y ago
  Hopefully you didn't make a decision based on some exception use case.
  - kibwen 7y ago
    The parent commenter does not suggest that this syntax was chosen based on assuming users don't have syntax highlighting, only that they did take into consideration that not all users have syntax highlighting.
    - Touche 7y ago
      I understand that, but how much into consideration? Let's just make up some numbers, if 1% of reading of Rust code takes place in environments without code highlight, then it should have been 1% of the consideration. Is that the case?
      - jcranmer 7y ago
        I don't think you should weight it like that. If you have multiple proposed syntaxes, and both are equally effective with code highlighting but one is moderately ineffective without highlighting, then it makes sense that you should go for the latter. The weighting controls how much of an effectivity loss in the code highlighting case you would be willing to trade off against effectivity improvements in the other case.
        Touche 7y ago
        It sounds like you're agreeing with me. If two options are indeed essentially equal on all fronts, then one minor use case can be enough to push it towards a winner.

I find the syntax highlighting argument odd. It's like arguing a road surface is acceptable because the dangerous conditions it causes are mitigated by traction control.

burntsushi 7y ago
I find the don't-consider-syntax-highlighting-at-all argument odd. It's like arguing traffic lights shouldn't use colors to indicate stop-and-go because some people either cannot perceive the color difference or choose to wear glasses that negate the color difference. (Analogies here suck. Instead, consider that the vast majority of programmers read code that has been syntax highlighted. To completely discount that experience at all would be odd.)
- kbenson 7y ago
  > It's like arguing traffic lights shouldn't use colors to indicate stop-and-go because some people either cannot perceive the color difference or choose to wear glasses that negate the color difference. There is a reason that we have three separate lights still instead of one (that is, there's more reasons than just inertia), and that's because some people can't tell the color differences. Specifically, my father can't easily tell the color difference between green and yellow. I've had friends that also had this problem. It's not uncommon. > To completely discount that experience at all would be odd I'm not saying to discount it entirely, but consider it in context. I think it's a somewhat elitist argument, because it assumes everyone both has syntax highlighting set up and that their highlighting will work as well as yours. I accept that syntax highlighting helps, and is a positive if it can be applied well to a solution, I just think it's far from sufficient. Put another way, an optional, environment specific configuration setting is not sufficient to offset the negative aspects of an official language level feature, if we're able to weigh things prior to being implemented. If Rust were required (or even officially expected) to be written in an environment where that was always available and easily configurable, I would think different. E.g. if we're talking about Visual Basic, or Smalltalk with it's IDE (IIRC, not that I have experience with it), then I would think different, but as long as the Rust compiler is expected to take in files of text and not some rich format that includes extra metadata, I don't think language design choices should weigh non-text considerations too heavily.
  - pjmlp 7y ago
    Given that my first syntax highlighting experience was Turbo Pascal 7.0 for MS-DOS, it always feels odd to see it disabled. And we aren't in the late 70's anymore, where languages had design decisions (keywords always caps) due to printing limitations.
  - burntsushi 7y ago
    > but consider it in context Which is exactly what has been done. So I don't understand what you're complaining about. The rest of your comment is a giant straw man. I've never heard of or seen implied that anyone in any decision making position in the Rust project is "assuming everyone has syntax highlighting set up." When you make ridiculous assumptions about the decision procedures of other people, then it's easy to derive ridiculous conclusions. But reality is always more nuanced than that: https://news.ycombinator.com/item?id=20031706 https://news.ycombinator.com/item?id=20031706
    - kbenson 7y ago
      I never made an argument about the Rust project assuming that. I'm talking about people using the availability syntax highlighting to dismiss a negative aspect of a possible choice. I was making that argument in general, but spurred by a specific comment here. I used the context of the Rust community discussion as an example, but never did I assume Rust was using this as a metric (just noting that it has been put forth in arguments from the community). My argument at this point (as illustrated by the Rust discussion) is simply: - Rust/rustc takes in unicode text as source - Since it has no knowledge at the source level of syntax highlighting, using that to mitigate the downside of a language level syntax for a feature is problematic - We as the public should keep that in mind when discussing the relative merits of one possible implementation or another of a feature. That's not denigrating or assuming Rust actually did this, it's a note about the community level discussion and how some people approached it, as evidenced by a very specific comment in this thread, and how I thought it had some problems when applied to language level decisions.
      - burntsushi 7y ago
dllthomas 7y ago
I think it's totally reasonable to judge a road surface based on how effective it is, in practice, with the kinds of traffic that will be travelling on it. Traction control is a part of that landscape. Designing with awareness of syntax highlighting makes sense. But we should also keep an awareness that it won't always be there.
- kbenson 7y ago
  > I think it's totally reasonable to judge a road surface based on how effective it is, in practice, with the kinds of traffic that will be travelling on it. Yes, and if we outlawed the use of cars without traction control on certain roads, then I would be fine with designing with the assumption traction control will be on. But as long as you allow older cars without traction control to still drive on the road, you are making the roads less safe for a certain percentage or class of drivers. I view that as different that just making the road safer for some. > But we should also keep an awareness that it won't always be there. Exactly. And this is why I think it doesn't make sense as a mitigation to a language level feature which will always be there. Specifically, I think syntax highlighting is a useful feature and a plus for a comparison, I just don't think it works as a mitigation for a negative for something that pervasive. All other things being equal, syntax highlighting abilities might push me towards one solution over another, but they won't make me ignore a problem I perceive with a solution.
  - dllthomas 7y ago
    I'm not sure if you read me as slightly more critical than I had intended or if I'm reading you as slightly more defensive than you'd intended, but I think we more-or-less agree: readability is important both with and without syntax highlighting, and tradeoffs should be considered in that light. A nitpick: > But as long as you allow older cars without traction control to still drive on the road, you are making the roads less safe for a certain percentage or class of drivers. Probably. But if a sufficient fraction of cars have traction control, and we sufficiently improve the performance of traction controlled tires at sufficiently small damage to the performance of other tires, the reduction in the threat of being hit by cars with traction control will outweigh the increase in risk of losing control for those cars without, even before trading off risk between cars (which is certainly more complicated). I don't think there's a direct mapping back to syntax and highlighting.

JoshTriplett 7y ago

Speaking as a member of the Rust language team: we specifically evaluated all syntax proposals on the assumption that many people may end up reading them without syntax highlighting. People read code in many places outside of a programmer's text editor or a code-highlighting web page, including logs, diffs, and emails.

Touche 7y ago
Hopefully you didn't make a decision based on some exception use case.
- kibwen 7y ago
  The parent commenter does not suggest that this syntax was chosen based on assuming users don't have syntax highlighting, only that they did take into consideration that not all users have syntax highlighting.
  - Touche 7y ago
    I understand that, but how much into consideration? Let's just make up some numbers, if 1% of reading of Rust code takes place in environments without code highlight, then it should have been 1% of the consideration. Is that the case?
    - jcranmer 7y ago
      I don't think you should weight it like that. If you have multiple proposed syntaxes, and both are equally effective with code highlighting but one is moderately ineffective without highlighting, then it makes sense that you should go for the latter. The weighting controls how much of an effectivity loss in the code highlighting case you would be willing to trade off against effectivity improvements in the other case.
      - Touche 7y ago
        It sounds like you're agreeing with me. If two options are indeed essentially equal on all fronts, then one minor use case can be enough to push it towards a winner.