My point was not to argue for the removal of \. My point was that there is a measurable way to test the usability of such a key
Brandon > On Jun 22, 2016, at 11:30 AM, Jeremy Pereira > <[email protected]> wrote: > > I find it somewhat disturbing that we are now trying to base language design > around the layout of a US English keyboard. > > “\” on my keyboard (British Macbook Pro Retina) is right next to the return > key. It’s also much closer to the parentheses characters than $ is and (if > you assume we are going to replace parentheses with braces as was suggested > upthread) right next to the brace keys. > > Anyway, your heat map evidence actually negates the argument. If it was a > frequently used key, it would have a hot spot of its own. It’s not (I tried > it on some random samples of my own code), so that implies it is not a key > that is used very often, which further implies it *should* be a little out of > the way. > > *The* escape character for strings is “\”. Please let’s not introduce a > second one. > > >> On 22 Jun 2016, at 00:08, Brandon Knope via swift-evolution >> <[email protected]> wrote: >> >> Actually… we can go pretty scientific on this sort of thing and heat map >> keyboard usage to get a better picture of how “usable” this is. >> >> I pasted a file that contains seven \’s in it and heat mapped it at >> https://www.patrick-wied.at/projects/heatmap-keyboard/ >> >> Even *with* several \’s throughout my source file the majority of my key >> presses take place much closer to the $ key than the \ key. >> >> I think we can all argue about what is clearer or not, but I think for the >> majority of us, the \ key is quite inconvenient compared to the keys around >> where we type the most. >> >> I also ran several of iOS 10’s sample code through the heat map and continue >> to get pretty similar results: the \ is much further from the hottest part >> of the keyboard than the ones closer to where your hand usually rests. >> >> Maybe this is flawed, but I think it is hard to argue that the \ is easy to >> type when there are far more usable alternatives. >> >> Brandon >> >> >> >>> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution >>> <[email protected]> wrote: >>> >>> I also disagree for the same reasons that Gwynne and Brent mentioned: I >>> find '\(...)' easy to read, fine to type, and consistent with other string >>> escaping syntax. >>> >>> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution >>> <[email protected]> wrote: >>>> I find that typing \(var) is very disruptive to my typing flow. The more I >>>> code in Swift, the more I like it, but every time I'm coding and then have >>>> to hiccup while typing \ then ( causes me to be annoyed. I know, it's >>>> minor, but it isn't a key combination that flows quickly. >>>> >>>> I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps >>>> @() to go along with other uses of @ throughout the language. >>> >>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I >>> immediately liked `\(…)`. It's parsimonious: Rather than taking a third >>> character (besides \ and ") to mean something special in a string literal, >>> it reuses one of the existing ones. There's no need to escape a character >>> you wouldn't otherwise have to touch, or to think of another character as >>> "magical" in a string. It fits nicely with the rest of the syntax, with `\` >>> indicating a special construct and then `()` delimiting an expression, just >>> as they do elsewhere in the language. It's an elegant solution to a problem >>> traditionally solved inelegantly. It's very Swifty in that way. >>> >>>> A shifted key, like $ or @, followed by another shifted key like (, allows >>>> for a much faster flow and they are much closer to the home keys than \ >>>> which is nearly as far from home keys as possible (and awkward). >>> >>> >>> I don't have any trouble typing it personally. If you find yourself >>> accidentally typing `\9` or `|(`, we could probably offer an error for the >>> former or warning for the latter with a fix-it. But if you're complaining >>> that it takes a tiny fraction of a second longer to type than `$(` would, >>> then honestly, I just can't bring myself to care. Swift optimizes for code >>> reading. If we wanted to optimize for code typing instead, we'd have a very >>> different style. >>> >>> -- >>> Brent Royal-Gordon >>> Architechies >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
