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.
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.
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.
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.
From today’s Daring Fireball:
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.
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).
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.
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?
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)
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.
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.
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.
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?
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.
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!
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…
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.
···
On Sat, Oct 29, 2016 at 4:14 PM, Jonathan Hull <jhull@gbis.com> wrote:
On Oct 29, 2016, at 8:11 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
