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

[John Pratt]

I agree with what you said and I wonder myself if it is possible at this
time for Swift to do what I mentioned in that article, given the current
roadmap.

Everyone would have to rewrite the agenda of Swift 5 to incorporate 
most of what I was talking about.  Additionally, Swift's
syntax and XCode would begin to overlap.  It would definitely require a "smart
editor," but then I also think that all terminals should be smart likewise.
The distinction between code and code editor would become less clear.

This is probably something that needs to be tested, as a proof
of concept, before a lot of people are ready to accept it.  But I am glad that
people are at least recognizing what I am talking about on this list, that unicode
symbols could be used.

I saw the beginning of crowdfunding.  The website I founded had one of our
users actually coin the word.  People at Kickstarter were able to swoop in and get
huge investors because the proof of concept was there for 4 years.  In other words:
no one thinks anything is going to work until it’s there.  But it still might work.


-John

> On Aug 29, 2017, at 11:33 PM, Chris Lattner <clattner at nondot.org> wrote:
> 
> 
>> On Aug 29, 2017, at 6:13 AM, John Pratt <jprattx at gmail.com <mailto:jprattx at 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 <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.
> 
> 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170830/281b58c6/attachment.html>