Sent from my iPad
> On Jun 21, 2016, at 8:07 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > (Whoops, reply to list; also adding a reply.) > > On Tue, Jun 21, 2016 at 6:55 PM, Kenny Wyland <[email protected]> wrote: >>> On Tue, Jun 21, 2016 at 4:40 PM, Xiaodi Wu via swift-evolution >>> <[email protected]> wrote: >>>> On Tue, Jun 21, 2016 at 6:25 PM, Brandon Knope <[email protected]> wrote: >>> >>>> How can it be unpersuasive? I can *show* you that keys that are easier to >>>> type/reach exist for a large majority of user’s. >>> >>> As I pointed out, your results are flawed because there are two keys >>> frequently reached for in the vicinity of \ which are excluded from your >>> analysis. Those keys are delete/backspace and return/enter. >> >> True, however, both of those keys (delete/backspace and return/enter) are >> over-sized for the specific reasons that they are difficult to hit in that >> position and we use them a lot so we compensate by making them larger. > > If you google some pictures of typewriter keyboards, you'll see that the > backspace key was once the same size as all other keys (whereas the shift > keys and space bar were not). Moreover, if you check out international > keyboards, you'll find that several of these keys vary in size based on > country, so clearly their specific size is not considered to be very important Are you surprised that usability isn't taken into consideration for a lot of products? Brandon > (even though (I presume) people delete things and advance lines at similar > frequencies regardless of language). So I don't really buy the idea that > these keys are sized "for the specific reason that they are difficult to hit." > >>>> I am not saying it is a good idea or not to replace \, but to pretend that >>>> there isn’t an inconvenience there is unfair when every other part of the >>>> language is put under a magnifying glass for the sake of grammar, newbie >>>> friendliness, or this or that, etc... >>>> >>> >>> We've discussed why it's sensible grammar; there is no argument to be made >>> here about whether pressing one labeled key or another is friendlier to a >>> beginner. >> >> The idea that \ is already a special character inside strings isn't a valid >> argument for it being the -best- choice, it's simply an argument for it >> being the -easiest to code for- in the compiler. Backslashes in strings are >> used for special characters like \n, but I don't know of any language, other >> than Swift, that uses them for variable interpolation. >> >> So, if we're also talking about being friendlier to a beginner, I think that >> using blackslash is a disservice to them because it teaches them a pattern >> that isn't used by any other language for intra-string variable >> interpolation. > > Gwynne's argument here was persuasive to me, which is that each major > C-family language takes a different approach to interpolation. There is no > symbol which can be said to be widely used. Which is not to say that there > aren't poor choices and better ones. > >> >> Kenny Wyland >> >>> >>>> This is measurable…it just depends on whether it bothers people or not >>>> enough. Most other things are based on opinion, but this *can* be based on >>>> numbers and usability. >>> >>> See above; you measured wrong... >>> >>>> This is something used by everyone. The usability cost is there and it is >>>> real. Just because “well it is easy for me to type” does not mean that it >>>> is ideal. It also doesn’t mean that the current choice is the wrong choice >>>> either. But it still is important to discuss while we can. >>>> >>>> And yes a keyboard IS only so big, but the range to that bigness can be >>>> pretty… big. >>>> >>>> Also, $ is not the only option. There are still far easier keys to type >>>> than \. >>>> Brandon >>>> >>>>> On Jun 21, 2016, at 7:15 PM, Xiaodi Wu <[email protected]> wrote: >>>>> >>>>>> On Tue, Jun 21, 2016 at 6:08 PM, 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. >>>>> >>>>> I'm rather unpersuaded by this line of argument. The keyboard is only so >>>>> big; it's a stretch to say that any key is less than absolutely usable. >>>>> Moreover, \ is next the delete key, which I presume you use frequently >>>>> and find no difficulty in reaching. >>>>> >>>>> You know what *is* unusable though? Try finding the $ key on an >>>>> international keyboard. >>>>> >>>>>> 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 >>> >> > > _______________________________________________ > 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
