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

[Joseph Bell]

-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 at swift.org> wrote:

>
> > On 29 Oct 2016, at 03:22, Xiaodi Wu via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161031/f2f4d82e/attachment.html>