[swift-evolution] [Meta] Let's talk TouchBar + Unicode

[Xiaodi Wu]

On Mon, Oct 31, 2016 at 5:45 PM, Jonathan Hull <jhull at gbis.com> wrote:

> Premature standardization is just as bad as premature optimization...
>
> 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.
>>
>
> 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.)
>
>
> Sorry if I was unclear.  The point is not that you shouldn’t deal with
> annoyances (you should improve the keys on the next already scheduled
> re-print).  The point was that I was imagining the problem to be much worse
> (and much more urgent) than it actually was, because I wasn’t realistic
> about the user’s capabilities.  It may be counter-intuitive, but it leads
> to worse designs overall and lack of trust in the designer (and designers
> in general) by the client.  It also blinded me to much bigger improvements
> that could be made to truly improve the guest’s stay.
>
>
> 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.
>
>
> Why do you imagine that it has to be annoying or difficult?  You already
> told me that you find image literals “beginner-friendly”, and this could
> have a similar UX. It is not taking away any capability you have now, just
> adding the ability to use symbols much more easily when you want to.
>
>
>  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.
>
> 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.
>
>
>> 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.
>>
>> 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.
>>
>
> 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.
>
> 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.
>
>
> If this is true, I would argue for ≤ (with <= bringing up ≤ in
> autocomplete). I would also probably argue for a longer depreciation
> schedule.  We can argue about that in phase 2 though.
>
> I am actually a little annoyed at the removal of appending(contentsOf:),
> because I used both that and ‘+’, finding one or the other clearer in
> different contexts.  I’ll get used to it eventually though.
>
> 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.
>>
>
> 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 "*<*" [note to non-rich-text
> readers: that's "<" with an underline] is very near 100%.)
>
>
> Just because Microsoft Word is horrible and unintuitive, doesn’t mean that
> we have to be (also note that they were trying to make the ≤ symbol as
> opposed to writing <= or something similar).  The point is that we can do
> better than the status quo… and we should.
>
>
> 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).
>>
>>
>> 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?
>>>
>>> • 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.
>>>
>>> • 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?
>>>
>>> • Maybe they search for the documentation and find “formUnion” explained
>>> on the page. Again, the same is true of the operator.
>>>
>>
>> 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?
>>
>>
>> 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.
>>
>
> 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_?
>
>
> Because it is much more concise.  It is essentially “named” union… we just
> have a shorthand way to display it that doesn’t have to distract as much
> from everything else.  Would you rather have: '2.formSum(2)' or ‘2 + 2’ ?
> It makes a REAL difference when you are combining things into a fairly
> complex equation.  One line vs. half a page.
>
> The recent update from named methods to symbols in Decimal made my code so
> much more readable and clear.  The transformation is remarkable.  I can
> understand at a glance what I had to read and comprehend before.  Why
> should we deny ourselves similar clarity for set, vector, or matrix
> operations?
>

Again, I'm not opposed to making the IDE better for Unicode. And I'm not
opposed to having appropriate symbols for vector or matrix operations. You
keep returning to these points where we don't disagree.

The point I'm trying to make is: the set algebra operations in the Standard
Library are implemented by general-purpose types such as CharacterSet.
These are not going to be participating in mathematical operations. No one
is denying anybody the use of mathematical symbols for mathematical
equations. But they are not appropriate, IMO, for the Standard Library.
This applies equally for less-than-or-equal-to signs, which are implemented
for all Equatable types, many of which (most?) are *not* geared towards
mathematical use cases.

Again, I'd be perfectly content to see mathematical symbols aliasing the
appropriate functions in a separate library. That'd be delightful. I'd even
use it for math-heavy work.

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.
>>>
>>
>> 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.
>>
>>
>> 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.
>>
>> 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.
>>
>
> 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.
>
>
> Well, if on a case-by-case basis, we end up choosing ASCII characters and
> words, that is fine. I am just saying that we shouldn’t have a rule that
> limits us from choosing the best option in the case we decide it is the
> unicode version.
>

See, I'm -1 on the case-by-case evaluation of the Standard Library API,
which I think should stay as it is. Firstly, because we just went through a
whole bunch of renaming, and secondly, because I'm arguing that
mathematically correct symbols, which are wonderful for a mathematical
library, don't belong in the Standard Library unless they're ASCII.

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.
>>
>
> Yes, and I'm saying, in the standard library, what's best isn't the symbol.
>
>
> In most cases, the word is probably clearest.  But we decided ‘+’ (which
> is a symbol) is more clear than ‘formSum()’.  As I said above, I found a
> huge real world improvement from moving to symbols with Decimal.  I am sure
> that we will find other cases as well where symbols are helpful, especially
> as we start bringing in both heavy math (like vectors and matrices) and
> advanced string processing.
>

I believe the core team has made clear that vector and matrix math will
*not* be a part of the standard library. I'm not sure where non-ASCII
symbols come into advanced string processing. I'm not aware of any and
wouldn't know how to interpret any that I did come across.

Again, this has nothing to do with how you write your own third-party
> libraries.
>
> Why should we force ourselves to use something, which is by definition,
>> less clear/expressive?
>>
>
> 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.
>
>
> Right, and that is something we can argue given the context of each
> issue.  I can’t accept the premise that you know FOR SURE that there aren’t
> cases where something else might be the best choice.
>
>
> If we stop ourselves from even CONSIDERING other options, then I can tell
> you we won’t find the best one.  In my experience, productive creativity
> requires two phases:
>
> 1) Ideation - Where you generate lots of ideas (most of which are
> unworkable).  I tell my students that the road to GREAT ideas runs through
> bad ideas, so don’t stop with ideas that are merely ok.
>
> 2) Pruning - Where you take all of those ideas and nurture and sculpt the
> good ones… picking just the one or two that work best.
>
> I have found this list to be downright hostile at times towards anyone
> attempting step 1, and I think it is hurting us.  It may work for iterative
> refinement, but it makes big leaps much harder, so we get stuck in local
> maxima (and bike shedding).
>
>
> When I was little, I was lucky enough to meet Buzz Aldrin, and he told me:
> “Reach for the stars, and you might just touch the sky”.  I was confused,
> and asked him what it meant.  He said, “You need to aim high, because you
> will surprise yourself with what you are capable of (even if you don’t
> reach your goal) and you will do better than you thought you ever could.
> If you aim for your actual goal, you will never actually reach it.”  That
> stuck with me my whole life.
>
> All I am saying is that we need to stop imagining that everything is too
> difficult (for ourselves and for “The User”). Let’s figure out what we
> would want in an ideal world, and then we can figure out how to make some
> approximation work in our own...
>

Again, to reiterate, I'm -1 on any ideation regarding revisions to Standard
Library APIs that involve the use of non-ASCII symbols, for the reasons
I've written above and in previous emails. Sorry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161031/f7e1b773/attachment.html>