<div dir="ltr"><br><div><br><div class="gmail_quote">On Wed, Dec 6, 2017 at 6:14 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Dec 6, 2017, at 5:41 AM, Vincent Esche via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>> Alas while Swift's generics provide a nice basic foundation, they still have big gaps in what can be expressed through them.<br>> And i'm not talking about HKT or any such more advanced use of types). I'm talking about the basic stuff. Generic abstractions over type conversion. Generic abstractions over arithmetic operators. This kind of stuff. Stuff, that ironically would be necessary for a generic yet idiomatic implementation of Linear Algebra algorithms in Swift.<br><br></span>This is all orthogonal to the proposal. I’m certainly not opposed to the generics system getting better :-), […]<span class="gmail-"><br></span></blockquote><div><br></div><div>Exactly. That’s my whole point. How do we make sure these are understood to be orthogonal? We’re talking about the average Joe here.</div><div>For someone used to stringly-typed dictionaries (Python e.g.) and stringly-typed reflection (many message-passing/dynamic languages) it will not be clear that 9/10 times dynamic stringly-typed member lookup is not the right tool of choice for modeling type relations in a statically typed language, which is exactly how these things are done in many scripting languages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">> And I think that we have more urgent topics at hand that need to get fixed.<br>> Swift's generics are very limited. We hardly have any tooling.<br>> Diagnostics are just shy of migrating from "utter garbage" to "getting usable", by modern standards.<br>> Integration with Xcode still to this day is an utter clusterfuck. With errors pointing to the void, regularly.<br>> I'd prefer the team to focus on these, solidifying the foundation and once that's done<br>> and the result have been proven to be sound by time I'd love to see Swift get some more dynamism.<br><br></span>I’m not disagreeing with your point about other things needing to be improved, but the only question is whether this proposal fits with the right long term direction for Swift. It is not a prioritization question.<br></blockquote><div><br></div><div>I’m not so much thinking of it as a prioritization issue (as you already did the implementation and made clear from the beginning that you would do the heavy lifting, not the core team), but more of a timing issue. It absolutely is a timing issue from my point of view, for the very reasons that I gave previously.</div><div><br></div><div>A frequent argument against any of the reasonable doubts expressed in this thread is the notion that the community “would figure something out” and “prevent any anti-patterns and misuses from gaining a foothold”.</div><div><br></div><div><div>I have doubts about this. There is plenty of evidence for the contrary:</div><div><br></div><div>- We don't have a strong unit testing culture in the swift community. Hardly any Swift project on Github has proper unit test coverage. Most have none at all.</div><div> And I can’t blame them/us, as XCTest is more of a burden to use than a help. XCTest on Linux is even worse if not border-line offensive to work with.</div><div>- We don't have a strong culture of “avoid IUOs at all costs” either. I see them all over the place when going through random Github projects.</div><div> They are everywhere. I would give you numbers, but “!” is kinda hard to search for (i.e. impossible) using Github’s source code search feature.</div><div>- There is still plenty of use of AnyObject and its cousins where for a long time we have had better solutions.</div></div><div>- There is still incredible amounts of non-typesafe APIs (and I’m talking about fresh 3rd-party stuff here, not legacy frameworks).</div><div>- …</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">> At this point in time it's like opening Pandora's box.<br><br></span>I, still, have yet to see any evidence of harm that this proposal can cause.<span class="gmail-"><br></span></blockquote><div><br></div><div>The harm from my perspective is not so much of technical nature than more of a cultural one.</div><div>And plenty of “evidence” has been provided in this thread for why this proposal is a risk for the language.</div><div><br></div><div>If not then Letanyan put it perfectly:<br></div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div class="gmail_quote"><div>On Thu, Dec 7, 2017 at 7:37 AM, Letanyan Arumugam via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:</div></div></div><div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span class="gmail-"><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px">My main objection to the critical responses is that most of the objections are fundamentally cultural, not technical, and are fear-based, not evidence-based.</div></blockquote></span></div></div></blockquote></div></div></div><div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><span class="gmail-"><div><br></div></span></div></div></blockquote></div></div></div><div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div>The goal of this proposal is to <b>bring people from a culture where excessive use of this would be the norm for them</b>. <b>Why would it be so hard to imagine that people would adopt bad principles, knowing or unknowing, because this is what they’ve always done?</b></div></div></div></blockquote></div></div></div><div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br></div></div></div></blockquote></div></div></div><div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div>Evidence is going to be hard to get since I don’t know any other language like Swift that has done this for the same reasons before. As far as C# goes were they trying to get people from a heavily based dynamic community or help those already in the community?</div></div></div></blockquote></div></div></div></blockquote><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">[…]</blockquote></blockquote><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">My fear is that a design pattern around dynamic members and calls arise that is <b>used to bypass the perceived initial annoyance of Swifts type system from new developers that come over to Swift</b> and are now starting to try and go native. They <b>have no reason to think</b> about their conforming types as <b>something that might fail</b> because <b>they’re using it</b> to model behaviour that they’re used to (good or bad). I don’t see why it’s so bad to remind people that these conformances should be failing and only in rare cases should you ever have a dynamic member lookup that is fine to ignore all failing lookups.</blockquote></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><b>People coming from JavaScript could perceivably make dictionaries conform. And later JSON, database, file and basically all resource API’s would follow.</b></blockquote></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Why would all of this happen rather than people behaving the way current Swift community members behave?</blockquote></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Because I worry that by bringing in people from other languages that <b>a new learning path is created</b>. One where you start by learning your language interoperating with Swift. And then pick up other Swift features as you go along using your Python API for example. <b>This would create a disparate Swift community.</b></blockquote></div></blockquote><br>"This would create a disparate Swift community” is the money quote here and the elephant in the room.<div>I fully agree with Letanyan. Couldn’t have said it any better.</div><div>What more evidence do we need that there _is_ potential for harm? This is no blind and reactionary fear-mongering.</div><div><div><br><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">> - How do you plan to teach the proper use of this feature? How would the documentation introduce it<br>> and how would it ensure that people fully understand its purpose and what it decidedly is _not_ for?<br>> - How would the diagnostics (in particular in code mixing static and dynamic Swift) look like?<br>> - How would the debugging of dynamic APIs look like?<br><br></span>This is an expert-only feature like the ExpressibleBy protocols. This is not something that will be introduced or taught in chapter one of the Swift book, or in the Swift Tour.</blockquote><div><br></div><div>So expert-only features don’t need to be documented/taught or get human-friendly diagnostics or debugging support?</div><div><br></div><div>Regardless of whether something is an expert-only feature it will come into contact with users of all levels of expertise.</div><div>And regardless of whether something is an expert-only feature it begs the question of …</div><div><br></div><div>- How we will introduce & teach this feature to people coming from static languages? How for those coming from dynamic languages?</div><div>- How we will make sure that users of all experience levels don’t get lost when interfacing with an API that makes use of it?</div><div>- How we will make sure that we don’t create a blackboxed sub-language that is void of any support for debugging and/or introspection.</div><div><br></div><div><div>I don’t understand this complete neglect of the community/educational aspect of adding a language feature</div><div>with the potential to completely changing the shape of large parts of the still young Swift ecosystem.</div></div><div><br></div><div>Vincent </div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 7, 2017 at 7:38 AM, Letanyan Arumugam via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> Until, and if, the “resistance” presents some conceptual explanation of how this could cause harm (I’m not asking for anything concrete, just a logical series of events that causes a plausible problem in practice), my belief is that the Swift community will see this as unwarranted fear.<br>
><br>
<br>
</span>My fear is that a design pattern around dynamic members and calls arise that is used to bypass the perceived initial annoyance of Swifts type system from new developers that come over to Swift and are now starting to try and go native. They have no reason to think about their conforming types as something that might fail because they’re using it to model behaviour that they’re used to (good or bad). I don’t see why it’s so bad to remind people that these conformances should be failing and only in rare cases should you ever have a dynamic member lookup that is fine to ignore all failing lookups.<br>
<br>
People coming from JavaScript could perceivably make dictionaries conform. And later JSON, database, file and basically all resource API’s would follow.<br>
<br>
Why would all of this happen rather than people behaving the way current Swift community members behave?<br>
Because I worry that by bringing in people from other languages that a new learning path is created. One where you start by learning your language interoperating with Swift. And then pick up other Swift features as you go along using your Python API for example. This would create a disparate Swift community.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>