<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I agree with what you said and I wonder myself if it is possible at this</div><div class="">time for Swift to do what I mentioned in that article, given the current</div><div class="">roadmap.</div><div class=""><br class=""></div><div class="">Everyone would have to rewrite the agenda of Swift 5 to incorporate </div><div class="">most of what I was talking about. Additionally, Swift's</div><div class="">syntax and XCode would begin to overlap. It would definitely require a "smart</div><div class="">editor," but then I also think that all terminals should be smart likewise.</div><div class="">The distinction between code and code editor would become less clear.</div><div class=""><br class=""></div><div class="">This is probably something that needs to be tested, as a proof</div><div class="">of concept, before a lot of people are ready to accept it. But I am glad that</div><div class="">people are at least recognizing what I am talking about on this list, that unicode</div><div class="">symbols could be used.</div><div class=""><br class=""></div><div class="">I saw the beginning of crowdfunding. The website I founded had one of our</div><div class="">users actually coin the word. People at Kickstarter were able to swoop in and get</div><div class="">huge investors because the proof of concept was there for 4 years. In other words:</div><div class="">no one thinks anything is going to work until it’s there. But it still might work.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-John</div><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 29, 2017, at 11:33 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 29, 2017, at 6:13 AM, John Pratt <<a href="mailto:jprattx@gmail.com" class="">jprattx@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Chris: Please read the article that I originally posted and mailed to the Swift team</div><div class="">before shooting down what I said:</div><div class=""><br class=""></div><div class=""><a href="http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf" class="">http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf</a></div><div class=""><br class=""></div><div class="">Alan Kay’s FONC project rewrote entire projects in far less code by</div><div class="">using symbols in the Maru and Nile programming languages. Alan Kay, as you know,</div><div class="">is the father of Smalltalk. Unicode symbols can be very powerful.</div></div></div></blockquote><br class=""></div><div class="">Ok John, let me approach this from a different direction:</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">My primary objections (compared to doing nothing: recommending that folks who care use a ligature font) are:</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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? </div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></body></html>