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 <[email protected]> wrote: > > >> On Aug 29, 2017, at 6:13 AM, John Pratt <[email protected] >> <mailto:[email protected]>> 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
