Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

Evolution Discussion
1

I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.

Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.

Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?

Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.

I expound on this issue in my article:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Thank you for reading.

-John

2

I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.

Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.

Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?

Hi John,

while it may be visually appealing, can you imagine typing those in real-life programming? I can't. Reaching for Symbol Viewer each time I need to compare two ints is a bit impractical, don't you think? Yes, on some keyboard layouts (e.g. US), you can use Option-< to type ≤, but in general, this one keyboard layout out of many and also the other symbols suggested (union, etc.) are nowhere to be found on a keyboard.

If you desire them, you can define custom operators, but it's IMHO impractical. It would require a radical redesign of the keyboard - and if you suggest the TouchBar, can you imagine symbols from your Fig. 6 on there and having to browse through them looking for the one you want?

If you want to test using them, you can try this library that defines them: GitHub - mattt/Euler: Swift Custom Operators for Mathematical Notation

Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.

Sorry, but I personally think it would make programming slower. Person, who can type with all 10 of his fingers will outpace a person looking for math symbols on a TouchBar any time he need to use "greater than or equal"...

···

On Aug 29, 2017, at 4:57 AM, John Pratt via swift-evolution <swift-evolution@swift.org> wrote:

I expound on this issue in my article:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Thank you for reading.

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

3

I whole-heartedly agree with the sentiment, but I think you're approaching this from the wrong direction... Unicode isn't used much because there's no simple, easy, and universal way to input unicode characters. Personally, I use a custom keyboard layout with tons of stuff mapped to ctrl- and alt-keys, but that breaks things like, say, Terminal.app, because ctrl-d prints ∂ instead of sending the control character (so I switch back to a keyboard layout without the control keys mapped, which is annoying). We need to solve the general unicode input problem before we can start seriously pushing for its use to be required, and that's far outside of Swift's scope.

As far as formatting matrices "correctly" (and I also wish they could be displayed the way you demonstrated in your write-up), I think that'd be more a feature of some sort of custom display layer in Xcode than of macOS's or Linux's text system. Maybe it'd fit in with some other OS's type system, but "typewriter text" is too ingrained into the text systems of Windows, macOS, and Linux (and every other OS I can think of) for "pretty print" matrices to work across all text-based applications (which is what I think it'd take to catch on).

- Dave Sweeris

···

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.

Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.

Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?

Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.

I expound on this issue in my article:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Thank you for reading.

4

Well, here is one question: 100 years from now do you think all computers
should use vi?

At what point would people ever have anything that ever slightly resembles
something advanced?
  
Do you ever want anything that
slightly resembles science fiction, ever, in society? Or should everyone be
using vi for the rest of civilization?

···

On Aug 30, 2017, at 5:32 PM, Eagle Offshore <eagleoffshore@me.com> wrote:

While I am in theory a fan of literate programming and enjoy integrated programming environments when they are integrated into a complete literate system (Smalltalk browsers, LISP environments, HyperCard, etc...)...In practice if its just a language and not a complete holistic system, and I can't command the entire thing with God's own editor (I speak of vi - because its "there" and it is the only editor guaranteed to be "there" on any system I am ever likely to try to access), I'm not gonna use it.

Just my $0.02

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.

Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.

Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?

Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.

I expound on this issue in my article:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Thank you for reading.

-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

5

A few thoughts:

1) I would like to see Xcode gain a couple more literal types using the same strategy it does for Image and Color literals

2) I would LOVE to see simple equation typesetting in Xcode

(Those two are mostly up to the Xcode team as opposed to swift, I suppose)

3) Why are we pretending like we can always edit swift in a ASCII editor? The argument that actually using unicode would break things doesn’t seem valid, because Swift has supported unicode since version 1, and people have been using it since that time to name both variables and operators. That doesn’t mean we need a super fancy editor, but I think requiring unicode awareness is completely reasonable. If your editor from the 1970’s breaks something, it is both your and your editor’s fault, not the code or the library, because Swift has unicode in it’s spec.

4) I don’t think we should let the difficulty of typing certain things stop us. It is an issue we need to consider, but it is an issue which can be solved fairly easily with good UI design if there is a need. Sure, different editors might solve it in different ways, but they will all solve it if it is useful (and in a few years, we will have all settled on the best approach). As people have mentioned, it can be difficult to type ‘{‘ on certain language layouts, so if we limited ourselves by that we couldn’t do anything. We shouldn’t adopt a lowest common denominator approach.

5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It won’t be confusing if we let people do either ‘<=‘ or ‘≤’ (there is research by Apple in the late 80’s that proves this). We all learned the symbol in math class. Even non-programmers know what it means. Assigning it any other meaning would be confusing because it’s meaning is so widely known. Every time I bring this up, I am told to just roll my own (which I have)… but it means that my code will now clash with everyone else’s identical implementation (because there is only one sane way to implement it). The fact that there are multiple identical implementations interfering with each other (and no real way to make a significantly different implementation) tells me it really should be part of swift itself. Every time I bring it up, people complain about it being extended ASCII instead of pure ASCII, and that it is hard to type on a German keyboard (those people can either just type ‘<=‘ or use a better editor which autocompletes ‘<=‘ to ‘≤’).

6) My recommendations for typing symbols would be:
  a) Choose a subset of useful and well-known symbols instead of every symbol
  b) Allow autocomplete on those symbols by name
  c) Optionally choose a little-used guardian character to start the names of symbols (to avoid accidental autocompletion).

Thanks,
Jon

···

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution@swift.org> wrote:

I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.

Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.

Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?

Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.

I expound on this issue in my article:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Thank you for reading.

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

6

There is no reason to change the language to enable this. Editors could do this automatically. Alternatively, you could just use a programming font with ligatures for operators, see e.g.:

https://www.hanselman.com/blog/MonospacedProgrammingFontsWithLigatures.aspx

-Chris

···

On Aug 28, 2017, at 9:58 PM, John Pratt via swift-evolution <swift-evolution@swift.org> wrote:

I think the editor would recognize that "<==“ was just
typed and replace it with the unicode character ≤ immediately.

Likewise, x^2 would be recognized and turned into x with 2 in superscript.

As for how the UI would work for other types of symbols,
there are all kinds of techniques for that. That is a UI issue,
for a UI design team to address. XCode’s code completion is just one
example of how UI can manage input issues.

7

I think the editor would recognize that "<==“ was just
typed and replace it with the unicode character ≤ immediately.

Likewise, x^2 would be recognized and turned into x with 2 in superscript.

As for how the UI would work for other types of symbols,
there are all kinds of techniques for that. That is a UI issue,
for a UI design team to address. XCode’s code completion is just one
example of how UI can manage input issues.

···

On Aug 28, 2017, at 11:43 PM, Charlie Monroe <charlie@charliemonroe.net> wrote:

On Aug 29, 2017, at 4:57 AM, John Pratt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.

Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.

Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?

Hi John,

while it may be visually appealing, can you imagine typing those in real-life programming? I can't. Reaching for Symbol Viewer each time I need to compare two ints is a bit impractical, don't you think? Yes, on some keyboard layouts (e.g. US), you can use Option-< to type ≤, but in general, this one keyboard layout out of many and also the other symbols suggested (union, etc.) are nowhere to be found on a keyboard.

If you desire them, you can define custom operators, but it's IMHO impractical. It would require a radical redesign of the keyboard - and if you suggest the TouchBar, can you imagine symbols from your Fig. 6 on there and having to browse through them looking for the one you want?

If you want to test using them, you can try this library that defines them: GitHub - mattt/Euler: Swift Custom Operators for Mathematical Notation

Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.

Sorry, but I personally think it would make programming slower. Person, who can type with all 10 of his fingers will outpace a person looking for math symbols on a TouchBar any time he need to use "greater than or equal"...

I expound on this issue in my article:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Thank you for reading.

-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

8

Hi Chris: Please read the article that I originally posted and mailed to the Swift team
before shooting down what I said:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Alan Kay’s FONC project rewrote entire projects in far less code by
using symbols in the Maru and Nile programming languages. Alan Kay, as you know,
is the father of Smalltalk. Unicode symbols can be very powerful.

···

On Aug 29, 2017, at 12:28 AM, Chris Lattner <clattner@nondot.org> wrote:

On Aug 28, 2017, at 9:58 PM, John Pratt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think the editor would recognize that "<==“ was just
typed and replace it with the unicode character ≤ immediately.

Likewise, x^2 would be recognized and turned into x with 2 in superscript.

As for how the UI would work for other types of symbols,
there are all kinds of techniques for that. That is a UI issue,
for a UI design team to address. XCode’s code completion is just one
example of how UI can manage input issues.

There is no reason to change the language to enable this. Editors could do this automatically. Alternatively, you could just use a programming font with ligatures for operators, see e.g.:
Ligatures & Coding. What they can, can’t and shouldn’t do | by Andreas Larsen | Larsenwork | Medium
GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures
https://www.hanselman.com/blog/MonospacedProgrammingFontsWithLigatures.aspx

-Chris

9

Given the evolution of the past 30 years, I'd say yes, vi will still be a thing in a 100 years.

···

On 30 août 2017 18:39 -0400, John Pratt via swift-evolution <swift-evolution@swift.org>, wrote:

Well, here is one question: 100 years from now do you think all computers
should use vi?

At what point would people ever have anything that ever slightly resembles
something advanced?

Do you ever want anything that
slightly resembles science fiction, ever, in society? Or should everyone be
using vi for the rest of civilization?

> On Aug 30, 2017, at 5:32 PM, Eagle Offshore <eagleoffshore@me.com> wrote:
>
> While I am in theory a fan of literate programming and enjoy integrated programming environments when they are integrated into a complete literate system (Smalltalk browsers, LISP environments, HyperCard, etc...)...In practice if its just a language and not a complete holistic system, and I can't command the entire thing with God's own editor (I speak of vi - because its "there" and it is the only editor guaranteed to be "there" on any system I am ever likely to try to access), I'm not gonna use it.
>
> Just my $0.02
>
> > On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution@swift.org> wrote:
> >
> > I sent a postal envelope to the Swift team with an article I wrote, arguing that
> > symbols and graphics would push the programming language forward.
> >
> > Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
> > instead of typing, “matrix()”? It seems to me Swift has the chance to do that.
> >
> > Also: why does "<==" still reside in code as "less than or equal to” when
> > there is a unicode equivalent that looks neat?
> >
> > Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
> > I think this would make programming much easier to deal with.
> >
> > I expound on this issue in my article:
> >
> > http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf
> >
> > Thank you for reading.
> >
> >
> > -John
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>

10

I think we've possibly moved beyond the scope of swift-evolution. Skim-reading the OP's manifesto demonstrates nothing relevant to general purpose programming languages or Swift in particular.

Ryan

···

August 31, 2017 8:40 AM, "John Pratt via swift-evolution" wrote:
Well, here is one question: 100 years from now do you think all computers
should use vi?
At what point would people ever have anything that ever slightly resembles
something advanced?
Do you ever want anything that
slightly resembles science fiction, ever, in society? Or should everyone be
using vi for the rest of civilization?
On Aug 30, 2017, at 5:32 PM, Eagle Offshore wrote:
While I am in theory a fan of literate programming and enjoy integrated programming environments when they are integrated into a complete literate system (Smalltalk browsers, LISP environments, HyperCard, etc...)...In practice if its just a language and not a complete holistic system, and I can't command the entire thing with God's own editor (I speak of vi - because its "there" and it is the only editor guaranteed to be "there" on any system I am ever likely to try to access), I'm not gonna use it.
Just my $0.02
On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution wrote:
I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.
Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.
Also: why does "

11

If you ask me this thread is off topic and belongs on an Apple issue
tracker or forum. XCode is just one of many editors used to edit Swift
code, and it should by no means be used as a baseline for language design
considering it is closed source and only available on one platform,
compared to a large number of great open source editors.

···

On Thu, Aug 31, 2017 at 7:53 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote:

A few thoughts:

1) I would like to see Xcode gain a couple more literal types using the
same strategy it does for Image and Color literals

2) I would LOVE to see simple equation typesetting in Xcode

(Those two are mostly up to the Xcode team as opposed to swift, I suppose)

3) Why are we pretending like we can always edit swift in a ASCII editor?
The argument that actually using unicode would break things doesn’t seem
valid, because Swift has supported unicode since version 1, and people have
been using it since that time to name both variables and operators. That
doesn’t mean we need a super fancy editor, but I think requiring unicode
awareness is completely reasonable. If your editor from the 1970’s breaks
something, it is both your and your editor’s fault, not the code or the
library, because Swift has unicode in it’s spec.

4) I don’t think we should let the difficulty of typing certain things
stop us. It is an issue we need to consider, but it is an issue which can
be solved fairly easily with good UI design if there is a need. Sure,
different editors might solve it in different ways, but they will all solve
it if it is useful (and in a few years, we will have all settled on the
best approach). As people have mentioned, it can be difficult to type ‘{‘
on certain language layouts, so if we limited ourselves by that we couldn’t
do anything. We shouldn’t adopt a lowest common denominator approach.

5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It *won’t*
be confusing if we let people do either ‘<=‘ or ‘≤’ (there is research by
Apple in the late 80’s that proves this). We all learned the symbol in
math class. Even non-programmers know what it means. Assigning it any
other meaning would be confusing because it’s meaning is so widely known.
Every time I bring this up, I am told to just roll my own (which I have)…
but it means that my code will now clash with everyone else’s identical
implementation (because there is only one sane way to implement it). The
fact that there are multiple identical implementations interfering with
each other (and no real way to make a significantly different
implementation) tells me it really should be part of swift itself. Every
time I bring it up, people complain about it being extended ASCII instead
of pure ASCII, and that it is hard to type on a German keyboard (those
people can either just type ‘<=‘ or use a better editor which autocompletes
‘<=‘ to ‘≤’).

6) My recommendations for typing symbols would be:
a) Choose a subset of useful and well-known symbols instead of every symbol
b) Allow autocomplete on those symbols by name
c) Optionally choose a little-used guardian character to start the names
of symbols (to avoid accidental autocompletion).

Thanks,
Jon

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution < > swift-evolution@swift.org> wrote:

I sent a postal envelope to the Swift team with an article I wrote,
arguing that
symbols and graphics would push the programming language forward.

Wouldn’t it be nice to have an actual multiplication matrix broken out
into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do
that.

Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?

Why can’t the square of x have a superscript of 2 instead of having
“pow(x,2)?
I think this would make programming much easier to deal with.

I expound on this issue in my article:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Thank you for reading.

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

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

12

A few thoughts:

1) I would like to see Xcode gain a couple more literal types using the same strategy it does for Image and Color literals

2) I would LOVE to see simple equation typesetting in Xcode

(Those two are mostly up to the Xcode team as opposed to swift, I suppose)

Please file radars at https://bugreport.apple.com <Feedback Assistant; for enhancement requests for Xcode.

3) Why are we pretending like we can always edit swift in a ASCII editor? The argument that actually using unicode would break things doesn’t seem valid, because Swift has supported unicode since version 1, and people have been using it since that time to name both variables and operators. That doesn’t mean we need a super fancy editor, but I think requiring unicode awareness is completely reasonable. If your editor from the 1970’s breaks something, it is both your and your editor’s fault, not the code or the library, because Swift has unicode in it’s spec.

The unicode support in Swift is not entirely dissimilar to unicode support in other languages. Java had Unicode support from the beginning as well (although pre-Emoji) and you can use identifiers as function names. Note however that ≤ is treated as a non-Java identifier part, so you can't use that in this particular case:

The issue isn't to do with whether it breaks an editor or not, but in practice you don't get people using operators because they're difficult to type, rather than whether the editor can render them or not.

4) I don’t think we should let the difficulty of typing certain things stop us. It is an issue we need to consider, but it is an issue which can be solved fairly easily with good UI design if there is a need. Sure, different editors might solve it in different ways, but they will all solve it if it is useful (and in a few years, we will have all settled on the best approach). As people have mentioned, it can be difficult to type ‘{‘ on certain language layouts, so if we limited ourselves by that we couldn’t do anything. We shouldn’t adopt a lowest common denominator approach.

No-one is preventing you from creating a library that uses these operators, though. The success and adoption of that library can be used to influence whether that will be beneficial to be in other libraries.

5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It won’t be confusing if we let people do either ‘<=‘ or ‘≤’ (there is research by Apple in the late 80’s that proves this). We all learned the symbol in math class. Even non-programmers know what it means. Assigning it any other meaning would be confusing because it’s meaning is so widely known. Every time I bring this up, I am told to just roll my own (which I have)… but it means that my code will now clash with everyone else’s identical implementation (because there is only one sane way to implement it). The fact that there are multiple identical implementations interfering with each other (and no real way to make a significantly different implementation) tells me it really should be part of swift itself. Every time I bring it up, people complain about it being extended ASCII instead of pure ASCII, and that it is hard to type on a German keyboard (those people can either just type ‘<=‘ or use a better editor which autocompletes ‘<=‘ to ‘≤’).

Nothing is preventing you creating a library which defines the ≤ operator and then including that in your projects for when you want to use it. You can even provide this for others who have expressed an interest on this list.

···

On 31 Aug 2017, at 13:53, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:

6) My recommendations for typing symbols would be:
  a) Choose a subset of useful and well-known symbols instead of every symbol
  b) Allow autocomplete on those symbols by name
  c) Optionally choose a little-used guardian character to start the names of symbols (to avoid accidental autocompletion).

Thanks,
Jon

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.

Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.

Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?

Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.

I expound on this issue in my article:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Thank you for reading.

-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

13

If all the hard symbols are automatically converted by the editor, why can't the editor show you a "pretty" view and save as "regular" text? Why does it need compiler involvement if the problem can entirely be addressed in UI space?

···

Le 29 août 2017 à 06:14, John Pratt via swift-evolution <swift-evolution@swift.org> a écrit :

Hi Chris: Please read the article that I originally posted and mailed to the Swift team
before shooting down what I said:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Alan Kay’s FONC project rewrote entire projects in far less code by
using symbols in the Maru and Nile programming languages. Alan Kay, as you know,
is the father of Smalltalk. Unicode symbols can be very powerful.

On Aug 29, 2017, at 12:28 AM, Chris Lattner <clattner@nondot.org <mailto:clattner@nondot.org>> wrote:

On Aug 28, 2017, at 9:58 PM, John Pratt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think the editor would recognize that "<==“ was just
typed and replace it with the unicode character ≤ immediately.

Likewise, x^2 would be recognized and turned into x with 2 in superscript.

As for how the UI would work for other types of symbols,
there are all kinds of techniques for that. That is a UI issue,
for a UI design team to address. XCode’s code completion is just one
example of how UI can manage input issues.

There is no reason to change the language to enable this. Editors could do this automatically. Alternatively, you could just use a programming font with ligatures for operators, see e.g.:
Ligatures & Coding. What they can, can’t and shouldn’t do | by Andreas Larsen | Larsenwork | Medium
GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures
https://www.hanselman.com/blog/MonospacedProgrammingFontsWithLigatures.aspx

-Chris

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

14

Ok John, let me approach this from a different direction:

I’m not saying that doing such a thing would have zero value. Far from it, it could be an interesting research project for someone focusing on programmer productivity to investigate.

My primary objections (compared to doing nothing: recommending that folks who care use a ligature font) are:

a) Going down such a path has a lot of possible disadvantages: it could lead to forking the community (multiple ways of spelling the same thing), it cold make it harder to write code, it could lead to “requiring” smart editors, etc. The threshold for acceptance is not just “potentially interesting”, but something like this must “far outweight any downsides”. That criteria isn’t clear to me.

b) If you clear that hurdle, you need to clear the opportunity cost hurdle. Why is addressing this potential for improvement more important than the other potential areas for improvement? Why is this critical to address now? How does this align with the Swift 5 goals?

-Chris

···

On Aug 29, 2017, at 6:13 AM, John Pratt <jprattx@gmail.com> wrote:

Hi Chris: Please read the article that I originally posted and mailed to the Swift team
before shooting down what I said:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Alan Kay’s FONC project rewrote entire projects in far less code by
using symbols in the Maru and Nile programming languages. Alan Kay, as you know,
is the father of Smalltalk. Unicode symbols can be very powerful.

15

Saagar Jha

But countless editors have popped up since vi(m) first appeared. If anything, this is a testament to the fact that old, “crusty” technology can remain relevant forever, even as new technologies offering better ergonomics enter the market.

Also, could someone tell me how ImageLiteral and similar types are represented in the file? What appears when you open it in TextEdit? This same sort of thing — presumably some ascii delimiters signifying specially formatted data (I don’t have access to a computer) — could enable the desired matrix, sqrt, etc functionality in Xcode. (Unless Xcode is doing preprocessing of those types before compiling.)

It’ll show up as #imageLiteral([file name here]). Xcode will detect these automatically and fill it in with an image.

···

On Aug 30, 2017, at 16:42, Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 30, 2017, at 6:49 PM, Ryan Walklin via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think we've possibly moved beyond the scope of swift-evolution. Skim-reading the OP's manifesto demonstrates nothing relevant to general purpose programming languages or Swift in particular.

Ryan

August 31, 2017 8:40 AM, "John Pratt via swift-evolution" <swift-evolution@swift.org <mailto:%22John%20Pratt%20via%20swift-evolution%22%20<swift-evolution@swift.org>>> wrote:
Well, here is one question: 100 years from now do you think all computers
should use vi?
At what point would people ever have anything that ever slightly resembles
something advanced?
Do you ever want anything that
slightly resembles science fiction, ever, in society? Or should everyone be
using vi for the rest of civilization?

On Aug 30, 2017, at 5:32 PM, Eagle Offshore <eagleoffshore@me.com <mailto:eagleoffshore@me.com>> wrote:
While I am in theory a fan of literate programming and enjoy integrated programming environments when they are integrated into a complete literate system (Smalltalk browsers, LISP environments, HyperCard, etc...)...In practice if its just a language and not a complete holistic system, and I can't command the entire thing with God's own editor (I speak of vi - because its "there" and it is the only editor guaranteed to be "there" on any system I am ever likely to try to access), I'm not gonna use it.
Just my $0.02

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.
Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.
Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?
Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.
I expound on this issue in my article:
http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf
Thank you for reading.
-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

16

But countless editors have popped up since vi(m) first appeared. If anything, this is a testament to the fact that old, “crusty” technology can remain relevant forever, even as new technologies offering better ergonomics enter the market.

Also, could someone tell me how ImageLiteral and similar types are represented in the file? What appears when you open it in TextEdit? This same sort of thing — presumably some ascii delimiters signifying specially formatted data (I don’t have access to a computer) — could enable the desired matrix, sqrt, etc functionality in Xcode. (Unless Xcode is doing preprocessing of those types before compiling.)

···

On Aug 30, 2017, at 6:49 PM, Ryan Walklin via swift-evolution <swift-evolution@swift.org> wrote:

I think we've possibly moved beyond the scope of swift-evolution. Skim-reading the OP's manifesto demonstrates nothing relevant to general purpose programming languages or Swift in particular.

Ryan

August 31, 2017 8:40 AM, "John Pratt via swift-evolution" <swift-evolution@swift.org> wrote:
Well, here is one question: 100 years from now do you think all computers
should use vi?
At what point would people ever have anything that ever slightly resembles
something advanced?
Do you ever want anything that
slightly resembles science fiction, ever, in society? Or should everyone be
using vi for the rest of civilization?

On Aug 30, 2017, at 5:32 PM, Eagle Offshore <eagleoffshore@me.com> wrote:
While I am in theory a fan of literate programming and enjoy integrated programming environments when they are integrated into a complete literate system (Smalltalk browsers, LISP environments, HyperCard, etc...)...In practice if its just a language and not a complete holistic system, and I can't command the entire thing with God's own editor (I speak of vi - because its "there" and it is the only editor guaranteed to be "there" on any system I am ever likely to try to access), I'm not gonna use it.
Just my $0.02

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution@swift.org> wrote:
I sent a postal envelope to the Swift team with an article I wrote, arguing that
symbols and graphics would push the programming language forward.
Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do that.
Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?
Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?
I think this would make programming much easier to deal with.
I expound on this issue in my article:
http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf
Thank you for reading.
-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

17

Thank you everyone for contributing. I don't mean to talk more on this
issue.
If anyone at Apple wants to contact me to do things that go beyond
typewriter code,
you are welcome. Otherwise... well I guess you'll be copying Noctivagous
later.

···

On Wed, Aug 30, 2017 at 8:28 PM, Saagar Jha via swift-evolution < swift-evolution@swift.org> wrote:

Saagar Jha

On Aug 30, 2017, at 16:42, Robert Bennett via swift-evolution < > swift-evolution@swift.org> wrote:

But countless editors have popped up since vi(m) first appeared. If
anything, this is a testament to the fact that old, “crusty” technology can
remain relevant forever, even as new technologies offering better
ergonomics enter the market.

Also, could someone tell me how ImageLiteral and similar types are
represented in the file? What appears when you open it in TextEdit? This
same sort of thing — presumably some ascii delimiters signifying specially
formatted data (I don’t have access to a computer) — could enable the
desired matrix, sqrt, etc functionality in Xcode. (Unless Xcode is doing
preprocessing of those types before compiling.)

It’ll show up as #imageLiteral([file name here]). Xcode will detect these
automatically and fill it in with an image.

On Aug 30, 2017, at 6:49 PM, Ryan Walklin via swift-evolution < > swift-evolution@swift.org> wrote:

I think we've possibly moved beyond the scope of swift-evolution.
Skim-reading the OP's manifesto demonstrates nothing relevant to general
purpose programming languages or Swift in particular.

Ryan

August 31, 2017 8:40 AM, "John Pratt via swift-evolution" <
swift-evolution@swift.org
<%22John%20Pratt%20via%20swift-evolution%22%20%3Cswift-evolution@swift.org%3E>>
wrote:

Well, here is one question: 100 years from now do you think all computers
should use vi?
At what point would people ever have anything that ever slightly resembles
something advanced?
Do you ever want anything that
slightly resembles science fiction, ever, in society? Or should everyone be
using vi for the rest of civilization?

On Aug 30, 2017, at 5:32 PM, Eagle Offshore <eagleoffshore@me.com> wrote:
While I am in theory a fan of literate programming and enjoy integrated
programming environments when they are integrated into a complete literate
system (Smalltalk browsers, LISP environments, HyperCard, etc...)...In
practice if its just a language and not a complete holistic system, and I
can't command the entire thing with God's own editor (I speak of vi -
because its "there" and it is the only editor guaranteed to be "there" on
any system I am ever likely to try to access), I'm not gonna use it.
Just my $0.02

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution < > swift-evolution@swift.org> wrote:
I sent a postal envelope to the Swift team with an article I wrote,
arguing that
symbols and graphics would push the programming language forward.
Wouldn’t it be nice to have an actual multiplication matrix broken out
into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do
that.
Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?
Why can’t the square of x have a superscript of 2 instead of having
“pow(x,2)?
I think this would make programming much easier to deal with.
I expound on this issue in my article:
http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf
Thank you for reading.
-John
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

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

18

Please file radars at https://bugreport.apple.com <Feedback Assistant; for enhancement requests for Xcode.

Thanks. Will do.

4) I don’t think we should let the difficulty of typing certain things stop us. It is an issue we need to consider, but it is an issue which can be solved fairly easily with good UI design if there is a need. Sure, different editors might solve it in different ways, but they will all solve it if it is useful (and in a few years, we will have all settled on the best approach). As people have mentioned, it can be difficult to type ‘{‘ on certain language layouts, so if we limited ourselves by that we couldn’t do anything. We shouldn’t adopt a lowest common denominator approach.

No-one is preventing you from creating a library that uses these operators, though. The success and adoption of that library can be used to influence whether that will be beneficial to be in other libraries.

I have and will continue to. I would like to see support for making this easier in Xcode (which is another radar). My main argument here is that we should not shy away from at least considering options which require these operators in the standard library (if they are the best design). Right now all talk of it gets shut down immediately by a few very aggressive/vocal folks. Maybe it is the right design or maybe it isn’t… but we should at least be able to consider all of our options.

5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It won’t be confusing if we let people do either ‘<=‘ or ‘≤’ (there is research by Apple in the late 80’s that proves this). We all learned the symbol in math class. Even non-programmers know what it means. Assigning it any other meaning would be confusing because it’s meaning is so widely known. Every time I bring this up, I am told to just roll my own (which I have)… but it means that my code will now clash with everyone else’s identical implementation (because there is only one sane way to implement it). The fact that there are multiple identical implementations interfering with each other (and no real way to make a significantly different implementation) tells me it really should be part of swift itself. Every time I bring it up, people complain about it being extended ASCII instead of pure ASCII, and that it is hard to type on a German keyboard (those people can either just type ‘<=‘ or use a better editor which autocompletes ‘<=‘ to ‘≤’).

Nothing is preventing you creating a library which defines the ≤ operator and then including that in your projects for when you want to use it. You can even provide this for others who have expressed an interest on this list.

But there is something that is preventing me and others from doing this in open source code. I have written my own library with this (it was one of the first things I wrote in swift) and there are several others available online. The issue is that if I want to include another framework, and that framework has also defined it (or more likely relies on another framework that defines it) then swift gets upset about the multiple definitions. I really want to rely on those libraries, but if it makes my own framework have a danger of conflicts with other libraries then it will stop adoption of my framework as a result. That is the main reason I am arguing that it needs to be in a central spot… we are all prevented from really doing it on our own because multiple definitions conflict. It seems extra ridiculous because those definitions are all basically identical. Do you see the issue?

Thanks,
Jon

···

On Aug 31, 2017, at 6:53 AM, Alex Blewitt <alblue@apple.com> wrote:

19

Where is the source for this number? XCode is not even available for Linux.
And XCode’s market share is only shrinking as Swift expands more into the
open source world. To make Swift depend on proprietary XCode features would
nullify all of the work that has been done in the past 2 years to bring
Swift to Linux platforms.

···

On Thu, Aug 31, 2017 at 12:44 PM, John Pratt <jprattx@gmail.com> wrote:

XCode is not just one of many editors to edit Swift you asshole.

It is 99% of all editors used.

On Aug 31, 2017, at 11:27 AM, Taylor Swift <kelvin13ma@gmail.com> wrote:

If you ask me this thread is off topic and belongs on an Apple issue
tracker or forum. XCode is just one of many editors used to edit Swift
code, and it should by no means be used as a baseline for language design
considering it is closed source and only available on one platform,
compared to a large number of great open source editors.

On Thu, Aug 31, 2017 at 7:53 AM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote:

A few thoughts:

1) I would like to see Xcode gain a couple more literal types using the
same strategy it does for Image and Color literals

2) I would LOVE to see simple equation typesetting in Xcode

(Those two are mostly up to the Xcode team as opposed to swift, I suppose)

3) Why are we pretending like we can always edit swift in a ASCII
editor? The argument that actually using unicode would break things
doesn’t seem valid, because Swift has supported unicode since version 1,
and people have been using it since that time to name both variables and
operators. That doesn’t mean we need a super fancy editor, but I think
requiring unicode awareness is completely reasonable. If your editor from
the 1970’s breaks something, it is both your and your editor’s fault, not
the code or the library, because Swift has unicode in it’s spec.

4) I don’t think we should let the difficulty of typing certain things
stop us. It is an issue we need to consider, but it is an issue which can
be solved fairly easily with good UI design if there is a need. Sure,
different editors might solve it in different ways, but they will all solve
it if it is useful (and in a few years, we will have all settled on the
best approach). As people have mentioned, it can be difficult to type ‘{‘
on certain language layouts, so if we limited ourselves by that we couldn’t
do anything. We shouldn’t adopt a lowest common denominator approach.

5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It
*won’t* be confusing if we let people do either ‘<=‘ or ‘≤’ (there is
research by Apple in the late 80’s that proves this). We all learned the
symbol in math class. Even non-programmers know what it means. Assigning
it any other meaning would be confusing because it’s meaning is so widely
known. Every time I bring this up, I am told to just roll my own (which I
have)… but it means that my code will now clash with everyone else’s
identical implementation (because there is only one sane way to implement
it). The fact that there are multiple identical implementations
interfering with each other (and no real way to make a significantly
different implementation) tells me it really should be part of swift
itself. Every time I bring it up, people complain about it being extended
ASCII instead of pure ASCII, and that it is hard to type on a German
keyboard (those people can either just type ‘<=‘ or use a better editor
which autocompletes ‘<=‘ to ‘≤’).

6) My recommendations for typing symbols would be:
a) Choose a subset of useful and well-known symbols instead of every
symbol
b) Allow autocomplete on those symbols by name
c) Optionally choose a little-used guardian character to start the names
of symbols (to avoid accidental autocompletion).

Thanks,
Jon

On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution < >> swift-evolution@swift.org> wrote:

I sent a postal envelope to the Swift team with an article I wrote,
arguing that
symbols and graphics would push the programming language forward.

Wouldn’t it be nice to have an actual multiplication matrix broken out
into code,
instead of typing, “matrix()”? It seems to me Swift has the chance to do
that.

Also: why does "<==" still reside in code as "less than or equal to” when
there is a unicode equivalent that looks neat?

Why can’t the square of x have a superscript of 2 instead of having
“pow(x,2)?
I think this would make programming much easier to deal with.

I expound on this issue in my article:

http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf

Thank you for reading.

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

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

20

5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It won’t be confusing if we let people do either ‘<=‘ or ‘≤’ (there is research by Apple in the late 80’s that proves this). We all learned the symbol in math class. Even non-programmers know what it means. Assigning it any other meaning would be confusing because it’s meaning is so widely known. Every time I bring this up, I am told to just roll my own (which I have)… but it means that my code will now clash with everyone else’s identical implementation (because there is only one sane way to implement it). The fact that there are multiple identical implementations interfering with each other (and no real way to make a significantly different implementation) tells me it really should be part of swift itself. Every time I bring it up, people complain about it being extended ASCII instead of pure ASCII, and that it is hard to type on a German keyboard (those people can either just type ‘<=‘ or use a better editor which autocompletes ‘<=‘ to ‘≤’).

Nothing is preventing you creating a library which defines the ≤ operator and then including that in your projects for when you want to use it. You can even provide this for others who have expressed an interest on this list.

But there is something that is preventing me and others from doing this in open source code.

No, nothing prevents you from doing it in open source code. If you have done this already, please share the link so that others may benefit from your work.

swift-evolution is designed to discuss and advance the language of the Swift language, and the core data components that make the language necessary. There's a lot of extra functions and data types in the swift-corelibs-foundation project that don't belong in the core of Swift either.

I have written my own library with this (it was one of the first things I wrote in swift) and there are several others available online.

OK, so link to them, and get the various parties to agree on using one definition instead of several.

The issue is that if I want to include another framework, and that framework has also defined it (or more likely relies on another framework that defines it) then swift gets upset about the multiple definitions. I really want to rely on those libraries, but if it makes my own framework have a danger of conflicts with other libraries then it will stop adoption of my framework as a result.

This hasn't stopped a number of others from relying on types they've defined, like the Result type, for example.

That is the main reason I am arguing that it needs to be in a central spot… we are all prevented from really doing it on our own because multiple definitions conflict.

Have you submitted pull requests to those projects to try and unify them to a single spot? What was the outcome of those reviews?

It seems extra ridiculous because those definitions are all basically identical. Do you see the issue?

There's a difference of expectations here as to the purpose of the swift-evolution list. It's not about growing personal preferences of how to achieve that which is already available and possible to do today.

Alex

···

On 31 Aug 2017, at 15:47, Jonathan Hull <jhull@gbis.com> wrote:

On Aug 31, 2017, at 6:53 AM, Alex Blewitt <alblue@apple.com <mailto:alblue@apple.com>> wrote: