On Wed, Dec 6, 2017 at 6:14 PM, Chris Lattner <clatt...@nondot.org> wrote:
> On Dec 6, 2017, at 5:41 AM, Vincent Esche via swift-evolution < > swift-evolution@swift.org> wrote: > > Alas while Swift's generics provide a nice basic foundation, they still > have big gaps in what can be expressed through them. > > 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. > > This is all orthogonal to the proposal. I’m certainly not opposed to the > generics system getting better :-), […] > 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. 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. > And I think that we have more urgent topics at hand that need to get > fixed. > > Swift's generics are very limited. We hardly have any tooling. > > Diagnostics are just shy of migrating from "utter garbage" to "getting > usable", by modern standards. > > Integration with Xcode still to this day is an utter clusterfuck. With > errors pointing to the void, regularly. > > I'd prefer the team to focus on these, solidifying the foundation and > once that's done > > and the result have been proven to be sound by time I'd love to see > Swift get some more dynamism. > > 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. > 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. 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”. I have doubts about this. There is plenty of evidence for the contrary: - 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. 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. - 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. 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. - There is still plenty of use of AnyObject and its cousins where for a long time we have had better solutions. - There is still incredible amounts of non-typesafe APIs (and I’m talking about fresh 3rd-party stuff here, not legacy frameworks). - … > At this point in time it's like opening Pandora's box. > > I, still, have yet to see any evidence of harm that this proposal can > cause. > The harm from my perspective is not so much of technical nature than more of a cultural one. And plenty of “evidence” has been provided in this thread for why this proposal is a risk for the language. If not then Letanyan put it perfectly: On Thu, Dec 7, 2017 at 7:37 AM, Letanyan Arumugam via swift-evolution < swift-evolution@swift.org> wrote: > 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. > > > The goal of this proposal is to *bring people from a culture where > excessive use of this would be the norm for them*. *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?* > > 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? > […] 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. *People coming from JavaScript could perceivably make dictionaries conform. > And later JSON, database, file and basically all resource API’s would > follow.* Why would all of this happen rather than people behaving the way current > Swift community members behave? 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.* "This would create a disparate Swift community” is the money quote here and the elephant in the room. I fully agree with Letanyan. Couldn’t have said it any better. What more evidence do we need that there _is_ potential for harm? This is no blind and reactionary fear-mongering. > - How do you plan to teach the proper use of this feature? How would the > documentation introduce it > > and how would it ensure that people fully understand its purpose and > what it decidedly is _not_ for? > > - How would the diagnostics (in particular in code mixing static and > dynamic Swift) look like? > > - How would the debugging of dynamic APIs look like? > > 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. So expert-only features don’t need to be documented/taught or get human-friendly diagnostics or debugging support? Regardless of whether something is an expert-only feature it will come into contact with users of all levels of expertise. And regardless of whether something is an expert-only feature it begs the question of … - How we will introduce & teach this feature to people coming from static languages? How for those coming from dynamic languages? - 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? - 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. I don’t understand this complete neglect of the community/educational aspect of adding a language feature with the potential to completely changing the shape of large parts of the still young Swift ecosystem. Vincent On Thu, Dec 7, 2017 at 7:38 AM, Letanyan Arumugam via swift-evolution < swift-evolution@swift.org> wrote: > > > 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. > > > > 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. > > People coming from JavaScript could perceivably make dictionaries conform. > And later JSON, database, file and basically all resource API’s would > follow. > > Why would all of this happen rather than people behaving the way current > Swift community members behave? > 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. > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
