[Meta] Let's talk TouchBar + Unicode


(Jon Hull) #1

Given that Swift supports unicode, and it looks like this TouchBar will make typing relevant characters/symbols much more accessible/discoverable, I think we should move forward with the assumption that we will be able to type (somehow) whatever symbol we feel best represents something, and we should start looking for opportunities to use this where it makes sense.

The big issue is how to provide similar support for pre-touchbar devices (and non-Apple devices), and there are lots of options (of which I will list just a few below):

• Have emojis and symbols in the autocomplete list when appropriate by typing human readable names (i.e. ‘Dog Face’ instead of U+1F436, or ‘union’ for ∪). Optionally, we could have an easy symbol (e.g. $ or ^) which hints to the autocomplete that we might want a symbol (similar to how typing @ in Facebook brings up an autocomplete list of friends). Thus typing ‘^u’ would bring up '∪' near the top of the list (and you could continue typing ‘^union’ if needed to disambiguate)

• Allow autocomplete when using the short code (e.g. :dog: for :dog:)

• Have a bar along the bottom of the screen (kind of like the one which shows up when a keyboard is docked with an iPad) which maps to the function keys, and has similar options to what the TouchBar would have.

• For those using just a text editor, utilities like TextExpander (or the built in text expanding capabilities of OS X & other platforms). Pretty much every platform has a built in way to type unicode/emoji. It may not be the easiest, but hey, that is true of many platforms in general. There typically exist utilities to make it easier.

.

My main point, is that we should proceed as if everything we want to do in terms of input is possible, and trust that the Xcode team (and other IDE developers) will do what is required to make it work (or will speak up in particular cases to tell us we are headed in the wrong direction)… as opposed to assuming that things are impossible and not pushing the limits at all.

Note: I am not saying we should use these things frivolously… just that we shouldn’t be afraid to use them when they make a lot of sense (We have previously rejected several proposals because they are hard to type on one kind of keyboard or another).

Thanks,
Jon

PS. I am also ok having some overlap (e.g. both the union operator and ‘formUnion’, where one maps to the other) while technology is disseminating. They can always go through a depreciation cycle later if we decide to consolidate. I just don’t think we should wait, because then we will never start...


(Xiaodi Wu) #2

-1. I'm all for full and complete Unicode support in Swift so that each
person can use their native language to the fullest. But there is value in
saying that the working language for Swift evolution is U.S. English, the
working language for the Swift standard library API is U.S. English, and
the working character set for the core language facilities is ASCII. We've
discussed and rejected union operators in the stdlib; it was a heated
discussion, but we simply can't revisit API naming every six months. The
same argument about the touch bar can be said for iPad soft keyboards.

···

On Fri, Oct 28, 2016 at 7:35 PM Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote:

Given that Swift supports unicode, and it looks like this TouchBar will
make typing relevant characters/symbols much more accessible/discoverable,
I think we should move forward with the assumption that we will be able to
type (somehow) whatever symbol we feel best represents something, and we
should start looking for opportunities to use this where it makes sense.

The big issue is how to provide similar support for pre-touchbar devices
(and non-Apple devices), and there are lots of options (of which I will
list just a few below):

• Have emojis and symbols in the autocomplete list when appropriate by
typing human readable names (i.e. ‘Dog Face’ instead of U+1F436, or ‘union’
for ∪). Optionally, we could have an easy symbol (e.g. $ or ^) which hints
to the autocomplete that we might want a symbol (similar to how typing @ in
Facebook brings up an autocomplete list of friends). Thus typing ‘^u’
would bring up '∪' near the top of the list (and you could continue typing
‘^union’ if needed to disambiguate)

• Allow autocomplete when using the short code (e.g. :dog: for :dog:)

• Have a bar along the bottom of the screen (kind of like the one which
shows up when a keyboard is docked with an iPad) which maps to the function
keys, and has similar options to what the TouchBar would have.

• For those using just a text editor, utilities like TextExpander (or the
built in text expanding capabilities of OS X & other platforms). Pretty
much every platform has a built in way to type unicode/emoji. It may not
be the easiest, but hey, that is true of many platforms in general. There
typically exist utilities to make it easier.

.

My main point, is that we should proceed as if everything we want to do in
terms of input is possible, and trust that the Xcode team (and other IDE
developers) will do what is required to make it work (or will speak up in
particular cases to tell us we are headed in the wrong direction)… as
opposed to assuming that things are impossible and not pushing the limits
at all.

Note: I am not saying we should use these things frivolously… just that we
shouldn’t be afraid to use them when they make a lot of sense (We have
previously rejected several proposals because they are hard to type on one
kind of keyboard or another).

Thanks,
Jon

PS. I am also ok having some overlap (e.g. both the union operator and
‘formUnion’, where one maps to the other) while technology is
disseminating. They can always go through a depreciation cycle later if we
decide to consolidate. I just don’t think we should wait, because then we
will never start...
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #3

There are people out there who insist on using spaces for indention, just because of fear that some odd editor might not be able to deal with tabs properly… so even if this idea doesn't require a TouchBar, I don't think we should replace words with somewhat exotic characters:
Swift code will be written on computers without a TouchBar (which still has to prove its value), and even without Xcode.
So I'd focus the discussion on wether it makes sense to have two different ways to refer to common operations and constants (do you want π ? ;-), or if this would be a source of confusion.


(Haravikk) #4

Eh, I'm all for better emoji support but I think this needs to come in at the OS level.

Part of the problem for emoji is that the macOS special characters menu is so awkward to use; coincidentally I actually posted an enhancement request to the Apple bug reporter only yesterday asking for a more Spotlight-search like special characters selector. i.e- rather than the the awkward, tiny and hard to dismiss window something with immediate searching by relevant tags, either narrowing down for easy selection, or hitting enter for the top result.

In short; I don't think it's a Swift or even Xcode specific issue, and definitely shouldn't be part of auto-complete IMO. The real problem is that the macOS special characters selector is terrible, and has changed very little since OS X first appeared, except to be slightly rebranded for emojis (despite being no easier to use). Most apps that provide their own picker are vastly superior.

···

On 29 Oct 2016, at 01:34, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:

Given that Swift supports unicode, and it looks like this TouchBar will make typing relevant characters/symbols much more accessible/discoverable, I think we should move forward with the assumption that we will be able to type (somehow) whatever symbol we feel best represents something, and we should start looking for opportunities to use this where it makes sense.

The big issue is how to provide similar support for pre-touchbar devices (and non-Apple devices), and there are lots of options (of which I will list just a few below):

• Have emojis and symbols in the autocomplete list when appropriate by typing human readable names (i.e. ‘Dog Face’ instead of U+1F436, or ‘union’ for ∪). Optionally, we could have an easy symbol (e.g. $ or ^) which hints to the autocomplete that we might want a symbol (similar to how typing @ in Facebook brings up an autocomplete list of friends). Thus typing ‘^u’ would bring up '∪' near the top of the list (and you could continue typing ‘^union’ if needed to disambiguate)

• Allow autocomplete when using the short code (e.g. :dog: for :dog:)

• Have a bar along the bottom of the screen (kind of like the one which shows up when a keyboard is docked with an iPad) which maps to the function keys, and has similar options to what the TouchBar would have.

• For those using just a text editor, utilities like TextExpander (or the built in text expanding capabilities of OS X & other platforms). Pretty much every platform has a built in way to type unicode/emoji. It may not be the easiest, but hey, that is true of many platforms in general. There typically exist utilities to make it easier.

.

My main point, is that we should proceed as if everything we want to do in terms of input is possible, and trust that the Xcode team (and other IDE developers) will do what is required to make it work (or will speak up in particular cases to tell us we are headed in the wrong direction)… as opposed to assuming that things are impossible and not pushing the limits at all.

Note: I am not saying we should use these things frivolously… just that we shouldn’t be afraid to use them when they make a lot of sense (We have previously rejected several proposals because they are hard to type on one kind of keyboard or another).

Thanks,
Jon

PS. I am also ok having some overlap (e.g. both the union operator and ‘formUnion’, where one maps to the other) while technology is disseminating. They can always go through a depreciation cycle later if we decide to consolidate. I just don’t think we should wait, because then we will never start...
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jon Hull) #5

You are against even making it simpler to type/use the characters for those who want to use them? Hardcore.

···

On Oct 28, 2016, at 5:45 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

-1. I'm all for full and complete Unicode support in Swift so that each person can use their native language to the fullest. But there is value in saying that the working language for Swift evolution is U.S. English, the working language for the Swift standard library API is U.S. English, and the working character set for the core language facilities is ASCII. We've discussed and rejected union operators in the stdlib; it was a heated discussion, but we simply can't revisit API naming every six months. The same argument about the touch bar can be said for iPad soft keyboards.

On Fri, Oct 28, 2016 at 7:35 PM Jonathan Hull via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Given that Swift supports unicode, and it looks like this TouchBar will make typing relevant characters/symbols much more accessible/discoverable, I think we should move forward with the assumption that we will be able to type (somehow) whatever symbol we feel best represents something, and we should start looking for opportunities to use this where it makes sense.

The big issue is how to provide similar support for pre-touchbar devices (and non-Apple devices), and there are lots of options (of which I will list just a few below):

• Have emojis and symbols in the autocomplete list when appropriate by typing human readable names (i.e. ‘Dog Face’ instead of U+1F436, or ‘union’ for ∪). Optionally, we could have an easy symbol (e.g. $ or ^) which hints to the autocomplete that we might want a symbol (similar to how typing @ in Facebook brings up an autocomplete list of friends). Thus typing ‘^u’ would bring up '∪' near the top of the list (and you could continue typing ‘^union’ if needed to disambiguate)

• Allow autocomplete when using the short code (e.g. :dog: for :dog:)

• Have a bar along the bottom of the screen (kind of like the one which shows up when a keyboard is docked with an iPad) which maps to the function keys, and has similar options to what the TouchBar would have.

• For those using just a text editor, utilities like TextExpander (or the built in text expanding capabilities of OS X & other platforms). Pretty much every platform has a built in way to type unicode/emoji. It may not be the easiest, but hey, that is true of many platforms in general. There typically exist utilities to make it easier.

.

My main point, is that we should proceed as if everything we want to do in terms of input is possible, and trust that the Xcode team (and other IDE developers) will do what is required to make it work (or will speak up in particular cases to tell us we are headed in the wrong direction)… as opposed to assuming that things are impossible and not pushing the limits at all.

Note: I am not saying we should use these things frivolously… just that we shouldn’t be afraid to use them when they make a lot of sense (We have previously rejected several proposals because they are hard to type on one kind of keyboard or another).

Thanks,
Jon

PS. I am also ok having some overlap (e.g. both the union operator and ‘formUnion’, where one maps to the other) while technology is disseminating. They can always go through a depreciation cycle later if we decide to consolidate. I just don’t think we should wait, because then we will never start...
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jon Hull) #6

-1. I'm all for full and complete Unicode support in Swift so that each person can use their native language to the fullest. But there is value in saying that the working language for Swift evolution is U.S. English, the working language for the Swift standard library API is U.S. English, and the working character set for the core language facilities is ASCII. We've discussed and rejected union operators in the stdlib; it was a heated discussion, but we simply can't revisit API naming every six months.

It was mainly rejected based on being too hard to type. It turns out that that decision was short-sighted. I am saying we need to stop being short-sighted. I honestly don’t see the value in limiting ourselves to ASCII anymore. Let’s be expressive in the best way we can. If a symbol is more expressive in one case, let’s use it. If a word is more expressive in another, let’s use that. But applying (now artificial/unnecessary) constraints because it is what our forefathers did is not helpful.

I am reminded of the time, when I was writing my thesis (on Undo) in User Experience, they were trying to force us to put our charts, tables, and figures in a very unreadable format. Why? Because it made it easier for printing presses in the 1850’s, and the rules had been codified based on that. It didn’t matter that we were now printing on laser printers. Everyone was forced to do something suboptimal because it was what those in charge had been forced to do in their day as well. Arbitrarily forcing part of the system to be restricted to ASCII despite the fact that it now supports unicode is similarly silly (and similarly harmful).

The same argument about the touch bar can be said for iPad soft keyboards.

Yes, yes it can. Programming on the iPad will be a real thing before you know it. We need to avoid limiting ourselves to the constraints of the 1970s.

Thanks,
Jon

···

On Oct 28, 2016, at 5:45 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:


(Xiaodi Wu) #7

There are two proposals in here that you're mixing together.

One has to do with improvements to Xcode for working with Unicode. I'd be
all for that, as I've just said, but afaict this is not in scope for Swift
evolution.

The other has to do with expanding Swift standard library and core library
APIs beyond the ASCII character set. I'm -1 on that for the reasons I've
outlined above. Reworded, a very good reason to limit the standard library
itself to ASCII APIs is the same reason we limit the library to (a
restricted subset of) U.S. English. We do not all share a common first
language or recognize the same characters, but these are reasonable common
denominators with historical precedent in computer science *and* reasonably
wide international recognition.

Given the adage here that code is more frequently read than written, it is
unreasonable to require someone to master both "form union" and the union
operator when one of these will do. While you and I are comfortable with
set algebra notation, not everyone who uses Swift will be, and currently
they *do not have to be* in order to be perfectly proficient at Swift. It
does not sway me that you can now more easily type a character on a
potential future device. It matters to me that someone not familiar with
set algebra would have a hard time even looking up what such a non-ASCII
character is when he or she first encounters it in, say, a textbook.

Now, to be clear, a third-party Swift library should be free to adopt any
language or character set, and we should make the tooling as robust and
convenient as possible for that use case, but the choice for Swift standard
library APIs--themselves deliberately restricted in scope--should be the
minimum required for clearly expressing what these APIs are. A person
should not need to buy a special keyboard or device, or know how to work
the option/alt key, in order to write the less-than-or-equal-to operator.
OTOH, there's nothing wrong with a third-party project to decide that its
API will be Sanskrit-only and require proficiency in the associated script
for use.

···

On Fri, Oct 28, 2016 at 20:54 Jonathan Hull <jhull@gbis.com> wrote:

> On Oct 28, 2016, at 5:45 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> -1. I'm all for full and complete Unicode support in Swift so that each
person can use their native language to the fullest. But there is value in
saying that the working language for Swift evolution is U.S. English, the
working language for the Swift standard library API is U.S. English, and
the working character set for the core language facilities is ASCII. We've
discussed and rejected union operators in the stdlib; it was a heated
discussion, but we simply can't revisit API naming every six months.
It was mainly rejected based on being too hard to type. It turns out that
that decision was short-sighted. I am saying we need to stop being
short-sighted. I honestly don’t see the value in limiting ourselves to
ASCII anymore. Let’s be expressive in the best way we can. If a symbol is
more expressive in one case, let’s use it. If a word is more expressive in
another, let’s use that. But applying (now artificial/unnecessary)
constraints because it is what our forefathers did is not helpful.

I am reminded of the time, when I was writing my thesis (on Undo) in User
Experience, they were trying to force us to put our charts, tables, and
figures in a very unreadable format. Why? Because it made it easier for
printing presses in the 1850’s, and the rules had been codified based on
that. It didn’t matter that we were now printing on laser printers.
Everyone was forced to do something suboptimal because it was what those in
charge had been forced to do in their day as well. Arbitrarily forcing
part of the system to be restricted to ASCII despite the fact that it now
supports unicode is similarly silly (and similarly harmful).

> The same argument about the touch bar can be said for iPad soft
keyboards.
Yes, yes it can. Programming on the iPad will be a real thing before you
know it. We need to avoid limiting ourselves to the constraints of the
1970s.

Thanks,
Jon


(Alex Blewitt) #8

When typing you can use Control + Command + Space to bring up the same kind of emoji keyboard as on iOS; and it searches by name as well, so you can use the spotlight-like-search selector:

[:mag:pump ⓧ] [⠿⌘]
:high_heel: :jack_o_lantern: :fuelpump::fuelpump:

Screenshot in case the unicode characters don't survive:

···

On 29 Oct 2016, at 11:10, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

Part of the problem for emoji is that the macOS special characters menu is so awkward to use; coincidentally I actually posted an enhancement request to the Apple bug reporter only yesterday asking for a more Spotlight-search like special characters selector. i.e- rather than the the awkward, tiny and hard to dismiss window something with immediate searching by relevant tags, either narrowing down for easy selection, or hitting enter for the top result.


(Jon Hull) #9

But my main point is that the symbols painted on the physical keyboard are no longer our only (or even best) method of discovery. If ≤ comes up in the auto-complete when you write < or <=, then it solves the discovery issue. We can even use this to teach the option/alt key method (this is the what the Mac does to teach command keys associated with menu items).

Your point about the search-ability of symbols is an important one, but that can also be solved with appropriate UI for discovery of the associated (searchable) keywords.

Swift is a language being designed for the next 20-30 years, we shouldn’t be limiting ourselves based on technology that is already being replaced (as you mentioned many of the devices people use everyday already have a soft keyboard… and Ive said the TouchBar was just the beginning of a new direction). We need to aim for where the puck is going to be…

Thanks,
Jon

···

On Oct 28, 2016, at 7:22 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

A person should not need to buy a special keyboard or device, or know how to work the option/alt key, in order to write the less-than-or-equal-to operator.


(Rien) #10

+1, Well said.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl

···

On 29 Oct 2016, at 04:22, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

The other has to do with expanding Swift standard library and core library APIs beyond the ASCII character set. I'm -1 on that for the reasons I've outlined above. Reworded, a very good reason to limit the standard library itself to ASCII APIs is the same reason we limit the library to (a restricted subset of) U.S. English. We do not all share a common first language or recognize the same characters, but these are reasonable common denominators with historical precedent in computer science *and* reasonably wide international recognition.


(Rien) #11

Swift is a language being designed for the next 20-30 years, we shouldn’t be limiting ourselves based on technology that is already being replaced (as you mentioned many of the devices people use everyday already have a soft keyboard… and Ive said the TouchBar was just the beginning of a new direction). We need to aim for where the puck is going to be…

Hmm, I have engineering problems today. There will be engineering problems in 20 and 30 years as well, but I rather have a tool that is geared towards today’s problems. It would be even better if that tool is flexible enough so that it can adapt to the requirements as they change.

The difference between a puck and the future of engineering is that you can make a very good prediction about where a puck is going to be based on direction and speed. It is completely impossible to predict where the future of programming is going to be in 20 years time.

Let Swift be a flexible tool, don’t write anything in stone, and don’t try to predict the future.
If requirements change, let Swift change. But don’t try to be 20 years ahead of what we need today.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl


(Xiaodi Wu) #12

A person should not need to buy a special keyboard or device, or know how
to work the option/alt key, in order to write the less-than-or-equal-to
operator.

But my main point is that the symbols painted on the physical keyboard are
no longer our only (or even best) method of discovery. If ≤ comes up in
the auto-complete when you write < or <=, then it solves the discovery
issue. We can even use this to teach the option/alt key method (this is the
what the Mac does to teach command keys associated with menu items).

I agree with the first part of that, but IMO the second part misses the
point.

Sure, we should absolutely have better ways of discovering characters we do
not often use. I believe we should have this both at the OS level and, in
the case of writing code in languages that are Unicode-aware, at the IDE
level and baked into the language itself. I have no beef with that.

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.

Again, for your own libraries and APIs, go wild. Make a library that allows
people to write equations using the correct mathematical symbols. That'd be
awesome. *Of course* it makes sense then for people to need to learn these
symbols, and of course we could improve the OS and IDE and Swift itself to
make the experience of using that library better. But that shouldn't be the
_standard_ library.

Your point about the search-ability of symbols is an important one, but

···

On Sat, Oct 29, 2016 at 2:02 AM, Jonathan Hull <jhull@gbis.com> wrote:

On Oct 28, 2016, at 7:22 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
that can also be solved with appropriate UI for discovery of the associated
(searchable) keywords.

Swift is a language being designed for the next 20-30 years, we shouldn’t
be limiting ourselves based on technology that is already being replaced
(as you mentioned many of the devices people use everyday already have a
soft keyboard… and Ive said the TouchBar was just the beginning of a new
direction). We need to aim for where the puck is going to be…

Thanks,
Jon


(Jeremy Pereira) #13

Given the adage here that code is more frequently read than written, it is unreasonable to require someone to master both "form union" and the union operator when one of these will do. While you and I are comfortable with set algebra notation, not everyone who uses Swift will be, and currently they *do not have to be* in order to be perfectly proficient at Swift. It does not sway me that you can now more easily type a character on a potential future device. It matters to me that someone not familiar with set algebra would have a hard time even looking up what such a non-ASCII character is when he or she first encounters it in, say, a textbook.

Somebody not familiar with set algebra is not going to understand what “formUnion” means either. Either way they are going to have to look it up. Google returns the link in the Apple documentation as the top hit for formUnion, and it returns the Wikipedia page for set unions for ∪, so not a terrible disaster for discoverability. However …

Now, to be clear, a third-party Swift library should be free to adopt any language or character set, and we should make the tooling as robust and convenient as possible for that use case, but the choice for Swift standard library APIs--themselves deliberately restricted in scope--should be the minimum required for clearly expressing what these APIs are. A person should not need to buy a special keyboard or device, or know how to work the option/alt key, in order to write the less-than-or-equal-to operator. OTOH, there's nothing wrong with a third-party project to decide that its API will be Sanskrit-only and require proficiency in the associated script for use.

This I agree with 100%: the functions and operators of the standard library have to be typed in by everybody who programs in Swift. Not everybody has a MacBookPro with a touch bar (in fact, not anybody just yet, except for a lucky few). Not everybody wants to program with an iPad. Some people even like to program in Swift with text editors that aren’t Xcode. I expect there are programmers (especially on Linux) whose preferred editor is vi or even Emacs. For that reason, the Swift Standard Library has to be fairly lowest common denominator in terms of characters used.

···

On 29 Oct 2016, at 03:22, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:


(Haravikk) #14

Huh, this must be new on macOS Sierra? I'm still on El Capitan where it definitely does not work that way :wink:
If so it may be a reason to upgrade, as adding the winking emoji just there was a pain in the arse.

In that case though I'm not sure what extra support Swift really needs, as key-combo plus type-to-search ought to be more than fast enough, no need to overburden auto-complete etc.

···

On 31 Oct 2016, at 10:14, Alex Blewitt <alblue@apple.com> wrote:

On 29 Oct 2016, at 11:10, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Part of the problem for emoji is that the macOS special characters menu is so awkward to use; coincidentally I actually posted an enhancement request to the Apple bug reporter only yesterday asking for a more Spotlight-search like special characters selector. i.e- rather than the the awkward, tiny and hard to dismiss window something with immediate searching by relevant tags, either narrowing down for easy selection, or hitting enter for the top result.

When typing you can use Control + Command + Space to bring up the same kind of emoji keyboard as on iOS; and it searches by name as well, so you can use the spotlight-like-search selector:

[:mag:pump ⓧ] [⠿⌘]
:high_heel: :jack_o_lantern: :fuelpump::fuelpump:

Screenshot in case the unicode characters don't survive:
<Screen Shot 2016-10-31 at 10.11.51.png>


(Jon Hull) #15

Hmm, I have engineering problems today. There will be engineering problems in 20 and 30 years as well, but I rather have a tool that is geared towards today’s problems. It would be even better if that tool is flexible enough so that it can adapt to the requirements as they change.

I have already given several examples of how this can be done using today’s hardware (the TouchBar only makes things better). I have even shown how it can work with plain old text editors. Sure, in the case of using a vanilla editor, you lose some discoverability and ease, but that is a tradeoff that you make for using a vanilla editor (everything is still possible). Programs like BBEdit are infinitely extensible, and would quickly have plugins.

I agree that we want flexibility to adapt to requirements as they change.

The difference between a puck and the future of engineering is that you can make a very good prediction about where a puck is going to be based on direction and speed. It is completely impossible to predict where the future of programming is going to be in 20 years time.

Sure you can. I have an extremely good track record of predictions (and a horrible track record of being able to convince people before things actually happen… I call it my Cassandra Complex). You can’t predict everything of course, but there are patterns, trends and cycles that are fairly obvious if you look for them. Look at how the kids today communicate… they will be tomorrow’s programmers. I may not know exactly where we will end up, but I can tell which way the wind is blowing. You can either embrace the wind or fight it and be lost at sea.

More importantly though, we have a chance to help MAKE the future we want to see. That is why we are all here. While I value forward transfer, growth always requires some change.

Once again, I am not saying we should willy nilly replace things with crazy symbols. I am saying we should feel free to use whatever is clearest and most expressive for a given situation. If that is a word, we should use a word. If it is a symbol, then we should use a symbol. If that symbol is ASCII, then so be it. If it is unicode, we can do that now. Giving ourselves an artificial constraint of only being able to use the characters which are painted on US keyboards will, by definition, lead to a less clear/expressive experience.

···

On Oct 29, 2016, at 12:40 AM, Rien <Rien@Balancingrock.nl> wrote:


(Jon Hull) #16

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.

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).

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.

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. 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?

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…

···

On Oct 29, 2016, at 8:11 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:


(Dennis Lysenko) #17

FYI, the emoji bar with ctrl cmd space has worked that way since at the
very least El capitán, and I think as far back as mavericks.

···

Le lun. 31 oct. 2016 11:59, Haravikk via swift-evolution < swift-evolution@swift.org> a écrit :

On 31 Oct 2016, at 10:14, Alex Blewitt <alblue@apple.com> wrote:

On 29 Oct 2016, at 11:10, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote:

Part of the problem for emoji is that the macOS special characters menu is
so awkward to use; coincidentally I actually posted an enhancement request
to the Apple bug reporter only yesterday asking for a more Spotlight-search
like special characters selector. i.e- rather than the the awkward, tiny
and hard to dismiss window something with immediate searching by relevant
tags, either narrowing down for easy selection, or hitting enter for the
top result.

When typing you can use Control + Command + Space to bring up the same
kind of emoji keyboard as on iOS; and it searches by name as well, so you
can use the spotlight-like-search selector:

[:mag:pump ⓧ] [⠿⌘]
:high_heel: :jack_o_lantern: :fuelpump::fuelpump:

Screenshot in case the unicode characters don't survive:

<Screen Shot 2016-10-31 at 10.11.51.png>

Huh, this must be new on macOS Sierra? I'm still on El Capitan where it
definitely does not work that way :wink:
If so it may be a reason to upgrade, as adding the winking emoji just
there was a pain in the arse.

In that case though I'm not sure what extra support Swift really needs, as
key-combo plus type-to-search ought to be more than fast enough, no need to
overburden auto-complete etc.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Bell) #18

-1 I agree with Jeremy and Xiaodi with regards to adding non-ASCII
characters to the language core/standard library. Jeremy summed it up
nicely here, emphasis mine:

"This I agree with 100%: the functions and operators of the standard
library have to be typed in by everybody who programs in Swift. *Not
everybody has a MacBookPro with a touch bar* (in fact, not anybody just
yet, except for a lucky few). *Not everybody wants to program with an iPad*.
Some people *even like to program in Swift with text editors that aren’t
Xcode. I expect there are programmers (especially on Linux) whose preferred
editor is vi or even Emacs.* For that reason, the Swift Standard Library
has to be fairly lowest common denominator in terms of characters used."

I frequently code Swift on Linux with both vi and Emacs, and I'm on
touch-typist keyboards (Das Keyboard w/ no glyphs) with years of muscle
memory typing quick sequences such as <= or !=. Adding glyphs that cannot
be typed with 1 or 2 sequences (i.e., relying on a touchbar or relying on
an editor recognizing the "macOS-style" sequence of holding a key down long
enough to get options) or adding :less-than-or-equal-to: would be an
unwelcome addition.

-Joe

···

On Mon, Oct 31, 2016 at 9:07 AM, Jeremy Pereira via swift-evolution < swift-evolution@swift.org> wrote:

> On 29 Oct 2016, at 03:22, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
> Given the adage here that code is more frequently read than written, it
is unreasonable to require someone to master both "form union" and the
union operator when one of these will do. While you and I are comfortable
with set algebra notation, not everyone who uses Swift will be, and
currently they *do not have to be* in order to be perfectly proficient at
Swift. It does not sway me that you can now more easily type a character on
a potential future device. It matters to me that someone not familiar with
set algebra would have a hard time even looking up what such a non-ASCII
character is when he or she first encounters it in, say, a textbook.

Somebody not familiar with set algebra is not going to understand what
“formUnion” means either. Either way they are going to have to look it up.
Google returns the link in the Apple documentation as the top hit for
formUnion, and it returns the Wikipedia page for set unions for ∪, so not a
terrible disaster for discoverability. However …

>
> Now, to be clear, a third-party Swift library should be free to adopt
any language or character set, and we should make the tooling as robust and
convenient as possible for that use case, but the choice for Swift standard
library APIs--themselves deliberately restricted in scope--should be the
minimum required for clearly expressing what these APIs are. A person
should not need to buy a special keyboard or device, or know how to work
the option/alt key, in order to write the less-than-or-equal-to operator.
OTOH, there's nothing wrong with a third-party project to decide that its
API will be Sanskrit-only and require proficiency in the associated script
for use.

This I agree with 100%: the functions and operators of the standard
library have to be typed in by everybody who programs in Swift. Not
everybody has a MacBookPro with a touch bar (in fact, not anybody just yet,
except for a lucky few). Not everybody wants to program with an iPad. Some
people even like to program in Swift with text editors that aren’t Xcode. I
expect there are programmers (especially on Linux) whose preferred editor
is vi or even Emacs. For that reason, the Swift Standard Library has to be
fairly lowest common denominator in terms of characters used.

>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit


(Xiaodi Wu) #19

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:


(Sean Heber) #20

Well said. For what it is worth, I agree entirely. Let's move programming forward a little!

l8r
Sean

···

Sent from my iPad

On Oct 29, 2016, at 4:14 PM, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:

On Oct 29, 2016, at 8:11 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

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.

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).

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.

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. 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?

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…

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution