<div dir="ltr">On Sat, Oct 29, 2016 at 4:14 PM, Jonathan Hull <span dir="ltr">&lt;<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>&gt;</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-"><br><div><blockquote type="cite"><div>On Oct 29, 2016, at 8:11 AM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class="gmail-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&#39;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&#39;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 &quot;discover&quot; (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&#39;m not sure how you conclude from the text that I&#39;ve written above that I believe Swift users to be &quot;complete idiots.&quot; 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&#39;ve never seen before.</div><div><br></div><div>And while I do find myself using vim sometimes, I hardly consider it a paragon of discoverability, and I&#39;ve never mentioned vim in any conversation. Not sure why you&#39;re throwing that into the discussion here.</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>From today’s Daring Fireball:</div><div><blockquote type="cite"><span style="color:rgb(238,238,238);font-family:verdana,&#39;bitstream vera sans&#39;,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 &quot;harm discovery&quot;? FWIW, it has been observed numerous times on this very list that operators are _less_, not more, discoverable than other functions.</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>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&#39;ve never seen that symbol before, just how do you say &quot;∪&quot;? As in, literally, how would someone who just discovered such a hypothetical operator in Swift&#39;s documentation for SetAlgebra turn to another programmer and pronounce it? Here&#39;s the description in the documentation: &quot;Adds the elements of the given set to the set.&quot; Not very helpful for figuring that out, is it?</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>There is the issue of how to learn from an already typed symbol how to type it, but I can think of several easy ways to do that in the UI (even something as simple as a tooltip). I trust the Xcode team to be able to come up with something appropriate and user test it as necessary.  (What about vim users?  I trust they can figure it out)</div><div><br></div><div><br></div><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&#39;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><br></div><div>Just because a computer is a powerful device doesn&#39;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><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>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 &lt;= 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 &quot;formUnion&quot; is the diametrical opposite of your example of the &quot;Save&quot; 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 &quot;saving time&quot;? Is it really faster for you to type it out than to type &quot;&lt;=&quot;? That&#39;s certainly not the case for me! Half the time I find myself responding to you, I&#39;m using the iPad, where I have not yet worked out how to type that symbol at all. Hence, &quot;less-than-or-equal-to&quot; it is.</div><div><br></div><div>I&#39;m glad you have some thoughts as to how to teach someone to do something (typing the less-than-or-equal-to sign) that&#39;s more difficult than something else (typing &quot;&lt;=&quot;). I totally agree that where something is necessarily difficult, then we should be thinking to these methods of teaching users. But you know what&#39;s better than a good way of teaching something? Not having to teach it at all!</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>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><br></div></div></div></div>