<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="">On Dec 13, 2015, at 9:34 PM, Paul Cantrell <<a href="mailto:cantrell@pobox.com" class="">cantrell@pobox.com</a>> wrote:<div><blockquote type="cite" class=""><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="">I realize I’m straying for the topic of the thread (and Brent’s neglected proposal, which I really do mean to think some more about), but how I can I not chime in to these wonderful musings on language design?</div></div></div></blockquote><div><br class=""></div><div>No problem, I’m taking time to pontificate here for the benefit of the community, hopefully it will pay itself back over time, because people understand the rationale / thought process that led to Swift better :-)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">When you say “<b class="">programmer model</b>,” I understand you to mean "how a Swift programmer thinks about the language’s semantics while writing Swift code, without regard to how they’re implemented in the compiler.”</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes. Except in extreme cases, the interesting question isn’t whether it is “possible" to do thing X in language Foo, it is to ask whether Foo “encourages" X and how it rewards it.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes! When students ask why they should take Theory of Computation, part of my answer is that it’s good to get a really deep handle on the question of what’s <i class="">possible</i> in a language, and how very different that is from the question of what’s <i class="">elegant</i> in a language. The Church-Turing Thesis closes the door on a whole category of questions about what a given language can do: algorithmically, all these languages we work with are equivalent! </div></div></div></div></blockquote><div><br class=""></div><div>Yep, almost. I’m still hoping to get an infinite tape someday :-)</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Thanks for this. I was thinking “programmer model” meant only the programmer’s mental model of the language — but you’re talking about something broader and deeper: the style, the culture, the patterns of thought, and the aesthetics that arise from the experience of working with a particular language.</div></div></div></blockquote><div><br class=""></div>Right.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">So … how do you test this? </div></div></div></blockquote><div><br class=""></div><div>You can only test it by looking at a large enough body of code and seeing what problems they face. Any language that is used widely will evidence of problems that people are having. There are are shallow problems like “I have to type a few extra characters that are redundant and it annoys me”, and large problems “Two years into my project, I decided to throw it away and rewrite it because it had terrible performance / didn’t scale / was too buggy / couldn’t be maintained / etc". I don’t believe that there is ever a metric of “ultimate success", but the more big problems people have, the more work there is left to be done.</div><div><br class=""></div><div>The good news is that we, as programmers, are a strongly opinionated group and if something irritates us we complain about it :-). It is somewhat funny that (through selection bias) I have one of the largest list of gripes about Swift, because I see a pretty broad range of what people are doing and what isn’t working well (a result of reading almost everything written about swift, as well as tracking many, many, bug reports and feature requests). This drives my personal priorities, and explains why I obsess about weird little things like getting implicit conversions for optionals right, how the IUO model works, and making sure the core type checker can be fixed, but prefer to push off “simple” syntactic sugar for later when other pieces come in.</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">How do you evaluate language features for it? I think of these questions about protocol extensions, and trying to predict the resulting programmer model seems a fool’s errand.</div></div></div></blockquote><div><br class=""></div><div>Adding a feature can produce surprising outcomes. A classic historical example is when the C++ added templates to the language without realizing they were a turing complete meta-language. Sometime later this was discovered and a new field of template metaprogramming came into being. Today, there are differing opinions about whether this was a good or bad thing for the C++ programmer model.</div><div><br class=""></div><div>That said, most features have pretty predictable effects, because most features are highly precedented in other systems, and we can see their results and the emergent issues with them. Learning from history is extremely important. You can also think about the feature in terms of common metrics by asking things like “what is the error of omission?” which occurs someone fails to think about the feature. For example, if methods defaulted to final, then the error of omission would be that someone didn’t think about overridability, and then discovered later that they actually wanted it. If symbols defaulted to public, then people would naturally export way too much stuff, because they wouldn’t think about marking them internal, etc.</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">Swift doesn’t achieve this by being “watered down” for newbies, it does this by factoring the language so that power-user features can be learned at the appropriate point on the learning curve. “Niche” features for power uses make sense when they enable new things things being expressed, new markets to be addressed, or new performance wins to be had. This is key to Swift being able to scale from “low level system programming” all the way up to “scripting”, something I’m quite serious about.</div></div></div></blockquote><div class=""><br class=""></div><div class="">The other half of this is that the language doesn’t impose any cognitive burden on those who don’t use the niche / expert features. I don’t want to be an expert in everything all the time; I want to be able to focus on only the tools appropriate to the problem at hand. I don’t want to have to worry about bumping into the unshielded circular saw every time I pick up a screwdriver, even if I do know how to use a circular saw.</div><div class=""><br class=""></div><div class="">I like what Swift has done on this front so far. UnsafePointer is a great example. Swift can still provide bare memory access without making it ubiquitous. Take that, C++!</div></div></div></blockquote><div><br class=""></div>Right!</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">On which note: is there thought of eventually bootstrapping the Swift compiler?</div></div></div></blockquote><br class=""></div><div>There are no short term plans. Unless you’d consider rewriting all of LLVM as part of the project (something that would be awesome, but that I wouldn’t recommend :-), we’d need Swift to be able to import C++ APIs. I’m personally hopeful that we’ll be able to tackle at least some of that in Swift 4, but we’ll see - no planning can be done for Swift 4 until Swift 3 starts to wind down.</div><div><br class=""></div><div>-Chris</div><div class=""><br class=""></div></body></html>