<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=""><br class=""><div><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>Ok John, let me approach this from a different direction:</div><div><br class=""></div><div>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><br class=""></div><div><br class=""></div><div>My primary objections (compared to doing nothing: recommending that folks who care use a ligature font) are:</div><div><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>-Chris</div><div><br class=""></div><div><br class=""></div></body></html>