[swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

Robert Bennett rltbennett at icloud.com
Tue Aug 29 20:24:54 CDT 2017


But the question is, why does this need to affect the code base?

In the article you attached, they mention the antiquated one-line calculator display. The issue with that display is not the data stored in the calculator; it’s the display itself. An upgrade to (say) a Texas Instruments Inspire or whatever the newest TI calculator is (in my day we used an 83 or 84) only changes the display of the data; after all, you input that data will old fashioned buttons as well. The calculator isn’t doing any magic with the data itself in order to display that. If you want nicely formatted fractions, square roots, or matrices, go to WolframAlpha and type in your expression in ascii; you’ll see nicely formatted output.

Which is all to say, if you want pretty graphics in your code, all you need is a better front end. The backend can — and in absence of a better argument, should — remain unchanged.

> On Aug 29, 2017, at 3:38 PM, John Pratt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> The case I am making is that matrix multiplication would greatly benefit.
> 
> If by typing "matrix()" a real algebra matrix popped out of code with multiple columns
> spanning multiple rows of text, wouldn't that be a major improvement for everyone who
> does math or graphics?  There are a lot of these things.
> 
> Graphical elements acting as code can do much more than plain text formatting
> of any programming language's syntax.
> 
> 
> 
>> On Tue, Aug 29, 2017 at 1:38 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
>> I still would prefer ligature fonts (Fira-Code). All these complicated characters might be good and so but remeber there are more than one keyboard layout on this planet, some of those are far more complicated than the English keyboard layout. Even I struggle sometimes with simple {} and [] because these characters are not visible on my German keyboard layout at all.
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> Am 29. August 2017 um 18:27:05, Félix Cloutier via swift-evolution (swift-evolution at swift.org) schrieb:
>> 
>>> 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 at 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 at nondot.org> wrote:
>>>>> 
>>>>> 
>>>>>> On Aug 28, 2017, at 9:58 PM, John Pratt via swift-evolution <swift-evolution at 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.:
>>>>> https://medium.com/larsenwork-andreas-larsen/ligatures-coding-fonts-5375ab47ef8e
>>>>> https://github.com/tonsky/FiraCode
>>>>> https://www.hanselman.com/blog/MonospacedProgrammingFontsWithLigatures.aspx
>>>>> 
>>>>> -Chris
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170829/19a3e4a3/attachment.html>


More information about the swift-evolution mailing list