<div dir="ltr">On Sat, Oct 29, 2016 at 8:42 PM, Jonathan Hull <span dir="ltr"><<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class="gmail-"><blockquote type="cite"><div>On Oct 29, 2016, at 2:56 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="gmail-m_1165986060681498449Apple-interchange-newline"><div><div dir="ltr">On Sat, Oct 29, 2016 at 4:14 PM, Jonathan Hull <span dir="ltr"><<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="gmail-m_1165986060681498449gmail-"><br><div><blockquote type="cite"><div>On Oct 29, 2016, at 8:11 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="gmail-m_1165986060681498449gmail-m_2994120279952585700Apple-interchange-newline"><div><span style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline">However, *my* main point is that the Swift's standard library APIs (and the keywords and syntax at the core of the language) should use a character set that *requires no discovery whatsoever* for the vast majority of users. It is difficult enough to master a programming language, more difficult still to master one's first programming language (and--per the core team--Swift aims to be a great first programming language to learn); it is _bonkers_ to pile onto that the need to "discover" (however smoothly that goes) how to physically input the characters required to invoke some method.</span></div></blockquote></div><br></span><div>I am always amazed at this caricature of users as somehow simultaneously complete idiots (unable to figure out the option key) and experts in archaic computer architecture (…and they use vim). It is extremely disrespectful to the actual user. A good rule of thumb is to think of the user as extremely intelligent, but too busy and important to deal with your interface.</div></div></blockquote><div><br></div><div>This is a completely unfair characterization of my argument. I'm not sure how you conclude from the text that I've written above that I believe Swift users to be "complete idiots." On the contrary, I am saying that the user is indeed too busy with important matters to want to deal with figuring out how to type some weird symbol they've never seen before.</div></div></div></div></div></blockquote><div><br></div></span><div>Because your arguments are assuming that the user can’t figure things out, when they totally can. It is an extremely common (almost subconscious) caricature of “The User”. As a young designer, I was yelled at once by Don Norman for doing the same thing. I was complaining about the design of a room key (The arrow on the key needed more salience to afford how to use it). He replied, “Sure, it could be better. Things can always be better… but were you able to get into your room?”. Yes, I had. He then asked several other people nearby if they were able to get into their rooms. Everyone had. “How many people in the entire hotel do you think were not able to get into their room because of this? Tell me again why the hotel should spend thousands of dollars to reprint their keys to solve this thing which may be an annoyance, but hasn’t caused an actual problem?”. He then told me that people were much more capable than I was imagining them to be, and that I should give them the credit they deserve because failing to do so is ultimately harmful not just to the user of my designs, but to the design profession in general. It took me several years to really truly understand what he meant… but he was (as usual) right.</div></div></div></blockquote><div><br></div><div>Perhaps he was right about your room key. But we're not designing room keys here. (Also, have you *never* been annoyed by room keys and wondered to yourself who the !@#$ designed that piece of crap? But I digress.)</div><div><br></div><div>Figure out how to use your room key and the task is done. You're in your room. Figure out how to type and you're at step 0 of a long list of steps towards writing anything remotely useful in Swift. Make every step slightly annoying and you've got an infuriating language.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>I was being slightly hyperbolic, but you are arguing that figuring out how to use autocomplete (or even use the option key to type a symbol) is too difficult for beginners.</div></div></div></blockquote><div><br></div><div>I'm not arguing that it's "too difficult" a challenge to surmount--I'm arguing that if we stick to ASCII the challenge would not exist in the first place, and that we should not challenge the user to any degree whatsoever with regards to typing. There are other, more salient challenges already.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>You have also argued that having both ‘formsUnion’ and the union symbol would be too much of a burden on someone learning the language. You are assuming they will fail, no matter how well the UI is designed. I am saying, there might be a brief moment where they are learning, but once they get it… they will get it… and they will be able to express themselves much more as a result.</div><div><br></div><div>Also, I don’t think I have ever talked about requiring anyone to figure out the symbols. Rather I have talked about building on-ramps to teach them to be able to use the symbols freely where they want to.</div></div></div></blockquote><div><br></div><div>I understand. There's a mini-argument here that I didn't write out. It's been said that Swift is an "opinionated" language, not a to-each-their-own/design-by-committee kind of language. Thus, afaict, the modus operandi is that what's decided to be the best way is adopted as the *only* way.</div><div><br></div><div>Other than for compatibility reasons, perhaps, there are few if any aliases in the standard library. If we decide that the less-than-or-equal-to symbol is the best way to invoke that particular operation, then `<=` would be deprecated and then in the next version removed. If that's too much to stomach, then it's a hint that perhaps the less-than-or-equal-to symbol isn't good enough to replace `<=`. I don't see room for an in-between solution where the same function is named two or three ways.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>And while I do find myself using vim sometimes, I hardly consider it a paragon of discoverability, and I've never mentioned vim in any conversation. Not sure why you're throwing that into the discussion here.</div></div></div></div></blockquote></span><div>Apologies, it was someone else who wrote me about vim.</div><span class="gmail-"><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>From today’s Daring Fireball:</div><div><blockquote type="cite"><span style="color:rgb(238,238,238);font-family:verdana,'bitstream vera sans',sans-serif;font-size:10px;background-color:rgb(74,82,90)">Apple has always been very good at this — designing software and hardware where complexity is encapsulated rather than hidden. The genius of the original Mac wasn’t that it was suitable for dummies but that it was the first system that wasn’t confusing. Smart people flocked to the Mac.</span></blockquote><br></div><div><br></div><div>There is, by definition, always discovery. I think what you are really arguing is that there is forward transfer from things like word processing, and there is… it is important. But there are also still tradeoffs forced by your limitations that harm discovery in other ways (not to mention that I often use ≠ and ≤ in word processing).</div></div></blockquote><div><br></div><div>Why does not having the less-than-or-equal-to sign "harm discovery"? FWIW, it has been observed numerous times on this very list that operators are _less_, not more, discoverable than other functions.</div></div></div></div></blockquote><div><br></div></span><div>I actually just finished teaching a Swift class for people who had never programmed before. They had trouble with <= (“Why does the arrow mean less than or equal? Why can’t I use ≤?") and != (“But the ! has to do with optionals”… I think they thought it was unwrap and assign like *= is multiply and assign). They were able to solve these issues, of course, as they are intelligent people… but let’s not pretend that ASCII is magically free of confusion.</div></div></div></blockquote><div><br></div><div>If only you'd read as many documents as I have where the less-than-or-equal-to sign is written by underlining <, you would see that your proposed solution to these issues is not nearly as obvious as you make it out to be. (I'm a biologist by training; the number of manuscripts in that field where one sees it written as "<u><</u>" [note to non-rich-text readers: that's "<" with an underline] is very near 100%.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Having fewer available symbols means we are forced to chain the symbols we do have together in suboptimal ways (I believe there is talk of adding <=> to the standard library).</div><span class="gmail-"><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Let’s take, as an example, discovery of “formUnion”. How will a user, who doesn’t know about this, discover it’s existence and how it works?</div><div><br></div><div>• For the lucky people who already know about unions, but not swift’s crazy “formUnion”, they are in luck. If they just start typing ‘uni…’, then ‘formUnion’ will show in the autocomplete. Hmm… sounds like the exact method I was talking about with symbols.</div><div><br></div><div>• Maybe they will command-click into the definition file, and then see formUnion definition there. But couldn’t they also see the union symbol defined there?</div><div><br></div><div>• Maybe they search for the documentation and find “formUnion” explained on the page. Again, the same is true of the operator.</div></div></blockquote><div><br></div><div>OK, and if you've never seen that symbol before, just how do you say "∪"? As in, literally, how would someone who just discovered such a hypothetical operator in Swift's documentation for SetAlgebra turn to another programmer and pronounce it? Here's the description in the documentation: "Adds the elements of the given set to the set." Not very helpful for figuring that out, is it?</div></div></div></div></blockquote><div><br></div></span><div>In Xcode, they could mouse over it and see the word “union”. In the documentation, it could say “Union Operator. Adds the elements of the given set to the set.” It could even have a hint on how to type it (e.g. '^union’), and that part could be auto-generated.</div></div></div></blockquote><div><br></div><div>But if it needs to be documented as "union operator" and needs a tooltip to say "union" and you need to type "^union", why wouldn't you just name it "union" _as it already is_?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>We do need to be aware of and support beginning users, but optimizing Swift (or any expert system) for beginners just leads to a disempowering experience for everyone.</div></div></blockquote><div><br></div><div>Disagree strongly. Easy things should be easy, even when they're part of complex systems. Not everyone learning Swift has to grasp copy-on-write on day 1, but no one should have to struggle with how to type something.</div></div></div></div></blockquote><div><br></div></span><div>I do agree that easy things should be easy. I am saying we can make this easy if we want to. Easy enough that it can be used in any Swift code, even the core libraries when appropriate. </div><div><br></div><div>Again, if a symbol isn’t clear, we shouldn’t use it (and we can argue over what is clear or not in other threads). We should use whatever is clearest and most expressive. If that is ASCII, that is great, and if it is unicode, also great.</div></div></div></blockquote><div><br></div><div>I'm arguing that any ASCII character is at baseline, simply by virtue of having the increased recognition that ASCII characters do, clearer than any non-ASCII character to a general audience. There would have to be a huge win in expressiveness for any particular non-ASCII character to overcome that handicap. And I'm arguing that the most plausible scenario in the standard library where we might see a huge win--the union operator--does not, for me, pass that bar.</div><div><br></div><div>Again, this has nothing to do with how you write your own third-party libraries.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Why should we force ourselves to use something, which is by definition, less clear/expressive?</div></div></div></blockquote><div><br></div><div>See above. I can't accept your premise that the clearest and most expressive choice for any standard library API would be a non-ASCII symbol.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Just because a computer is a powerful device doesn't mean that we should tolerate the power button being unintuitive. (See, for example, widespread mockery of some versions of Windows because shutting down requires several menu clicks.) Just because Swift is a powerful language does not mean that we should give ourselves license to make the basic task of typing the letters required to invoke a function any harder than is absolutely necessary.</div></div></div></div></blockquote><div><br></div></span><div>I am not saying that we should make things purposefully unintuitive. But for expert systems, we want to optimize for efficiency of use, error recovery/prevention, and expression over walk-up-and-use. Believe it or not, this is the mindset the original mac was designed with (people still find that easy to use), and it is the mindset we should be designing with here.</div><div><br></div><div>As an aside, shutting down SHOULD require effort (Just as easy things should be easy… dangerous things should be a little bit difficult). You have to press and hold the mac power button for quite a while so that you don’t slip and hit it accidentally. It could be made “easier”, but that would put people’s data at risk. My understanding of why people ridicule Windows’ shutdown is that it was under the “start” menu.</div></div></div></blockquote><div><br></div><div>That's a much earlier criticism of the Windows shut down menu options...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Instead, we need to optimize for the users they will become, and provide “on-ramps” for the beginners. This is UX 101. Alan Cooper is probably the one who talks about this problem most, but any well trained designer will tell you the same.</div><div><br></div><div>You were characterizing having both ‘formUnion’ and the union symbol operator (or both <= and ≤) as a burden on the user’s feeble mind, but it isn’t. It is an on-ramp. It teaches them how to use the system! Are people confused by having ‘Save’ in the menu bar and also ⌘S? Or does the save menu command teach them how to use the keyboard to save time?</div></div></blockquote><div><br></div><div>This argument is unpersuasive. The situation with "formUnion" is the diametrical opposite of your example of the "Save" shortcut. There, the more discoverable method (the menu) is slower than the less discoverable one (the shortcut), so one points to the other. (Notably, on the Mac, pressing the shortcut will also highlight the corresponding menu, so it works both ways.) How is having the less-than-or-equal-to symbol "saving time"? Is it really faster for you to type it out than to type "<="? That's certainly not the case for me! Half the time I find myself responding to you, I'm using the iPad, where I have not yet worked out how to type that symbol at all. Hence, "less-than-or-equal-to" it is.</div></div></div></div></blockquote><div><br></div></span>In the case of the menu item, it is used to teach an accelerator which saves time. I am saying, we can use the same technique to teach symbols which are more concise, are more easily located in code, and are more representative. If the symbol is less representative than the word in a particular case, then we should use the word. We should use whatever is best.</div></div></blockquote><div><br></div><div>Yes, and I'm saying, in the standard library, what's best isn't the symbol.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Funny story: For new users (to a shortcut), especially those who are currently using the mouse, keyboard shortcuts actually take longer than using the menu, despite the fact that it FEELS much quicker to them. The brain basically stops making memories for a second during the context switch. You can sit in coffee shops and watch it happen. I always found it an amusing effect. (This changes with practice for common commands due to muscle memory)</div><div><br></div><div><span class="gmail-"><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I'm glad you have some thoughts as to how to teach someone to do something (typing the less-than-or-equal-to sign) that's more difficult than something else (typing "<="). I totally agree that where something is necessarily difficult, then we should be thinking to these methods of teaching users. But you know what's better than a good way of teaching something? Not having to teach it at all!</div></div></div></div></blockquote><div><br></div></span><div>Sure, but you are always going to have to teach someone who doesn’t have transferable experience (see above with students seeing <= as an arrow and being confused). We find the mouse intuitive now, but the original Mac came with software which taught you how to use it (and they needed to). Should we have stayed with DOS, because people knew how to use the keyboard (and we don’t want to teach them a new thing)? </div><span class="gmail-"><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I should point out that all of your arguments also argue against things like color and image literals (which are features I absolutely love). I am really glad that those didn’t have to go through this process, because we never would have done it. I guess that is what is worrying me…</div></div></blockquote><div><br></div><div>Huh? How is this related in any way to color or image literals? Those are extremely beginner-friendly and pedagogically useful facilities. Again, you are misunderstanding my argument. Colors and images are often used in Swift programming, and referring to them by a series of hexadecimal numbers or a file path (respectively) is unintuitive. It is therefore useful to have a beginner-friendly, WYSIWYG way of specifying a color or image. By contrast, typing the less-than-or-equal-to symbol is not necessary in Swift. It is totally backwards to design an elaborate way to make it easier to do so for the purpose of justifying an API change that will make them necessary.</div></div></div></div>
</blockquote><br></span></div><div>Well, image literals currently work exactly the same way I am saying unicode should. I agree that they are very beginner-friendly and pedagogically useful. Why do you think we can’t make symbols beginner-friendly and pedagogically useful? Is having both image(named:) and image literals confusing to beginners? No it is not.</div><div><br></div><div>This is not to justify making an API change. I am saying that we need to do whatever is clearest and most expressive. We can argue over whether ≤ or <= is clearer or more expressive (that is a separate issue), but I am shocked that so many are arguing that we should limit clarity to adhere to an ASCII only rule.</div></div></blockquote><div> </div></div><br></div></div>