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.
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.
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?
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.
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.
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.)
> 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.
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
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.
All someone said was "Await is a keyword, syntax highlighters will most likely paint it differently." Which is a perfectly cromulent thing to say, and isn't contradictory of anything you're saying. Now if someone said, "it's impossible to read the await keyword due to its placement, but since everyone uses syntax highlighting, it will be okay since it will be colored differently," then you'd have a point.
I guess I'm just so tired of folks piping up with the "not everyone uses syntax highlighting" crap almost every single time anyone even hints at the notion that syntax highlighting can help a particular piece of syntax. I guess you're probably tired of the opposite.
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.
> 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.
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.
> I'm not sure ... or if I'm reading you as slightly more defensive than you'd intended
That one. :)
> 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
That's a slightly different scenario, where the change is to increase safety. Then it is, as you say, a trade-off. It could just as easily be a trade-off because material is cheaper though, in which case different calculations are important.
Also, it's important to be careful not to exclude important information from the calculation even if it's about a relative safety increase. For example, if you increase the safety for 90% of the people but decrease it for 10%, and that 10% is mostly comprised a population that is unable to switch and benefit (e.g. poor people with little choice in the vehicle they drive, as they drive what's available and cheap), you might not only be forcing that risk on an already captive population, but they might also be a population that is resistant to change that would mitigate this danger (they can't afford new cars and they can't afford better cars). Conversely, shifting risk to the wealthier (more elastic) part of the market might yield more of a net reduction in risk as they are capable and willing to respond to the increased risk (or more likely, increased annoyance).
> I don't think there's a direct mapping back to syntax and highlighting.
There isn't, we're getting into the weeds, but conceptually I think there are some interesting points that apply at least partially. For example, not all changes are felt and valued by the populations they affect similarly. E.g. not relying on syntax highlighting for a language feature does not affect a person that uses syntax highlighting that much one way or another (it will likely still be highlighted in some way), but it can impact those that don't or can't fairly heavily. If I'm stuck trying to review some bug while on vacation through some crappy online git interface that isn't highlighting code well, or maybe even at all, I'm going to curse the heavens if there's a feature that's easily missed or hard to follow in monochromatic output if it's causing me problems in my stressful moment.
Perhaps that's my sysadmin history coming through, but I want stuff to be simple, reproducible, and obvious. Complexity, fragility and obscurity are the enemy, and I fight them wherever I see them. ;)