<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 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><br class=""><div><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><br class=""></div><div>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! It’s a really freeing insight once you’ve wrapped your head around it.</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="">What I really care about is “what kind of code is written by a FooLang programmer in practice”, which is what I refer to as the programmer model encouraged by FooLang.</div></div></div></blockquote>…</div><div><div><div><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="">When designing a programming language from scratch or considering adding a feature to an existing one, the “big” question is what the programmer model should be and whether a particular aggregation of features will provide it.</div></div></div></blockquote><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""></div></div></div></div></div><div><br class=""></div><div>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><br class=""></div><div>That’s wonderful. And daunting.</div><div><br class=""></div><div><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">So … how do you test this? 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></div><div><br class=""></div><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="">This is why we use “let” as a keyword instead of “const” or “let mut". If it were longer than “var”, some people would just use var everywhere with the argument that consistency is better.</div></div></div></blockquote><div><br class=""></div><div>I love this example. Yes, of course, we programmers would all concoct some post-hoc justification for doing what’s comfortable to us.</div><div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""></div></div></div></div></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="">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><br class=""></div><div>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><br class=""></div><div>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><br class=""></div><div>On which note: is there thought of eventually bootstrapping the Swift compiler?</div><div><br class=""></div><div>Cheers,</div><div><br class=""></div><div>Paul</div><div><br class=""></div></div></body></html>