> On 08 Dec 2017, at 00:06, Paul Cantrell <cantr...@pobox.com> wrote: > > >> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam <letanya...@gmail.com> 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? > > Languages bring in new developers who misapply their experience all the time. > Look at the early days of Ruby when it was actively working to pull new > developers away from Java, developers who were in the habit of using names > like AbstractItemManagerFactoryImpl. Look at beginner Swift code posted in > Stack Overflow questions, littered with careless force unwraps that are > clearly there because that’s the fixit and sort of smells like C or Java, not > because they actually thought about what they were doing. > > Note in both cases how the center of gravity of the language did •not• move. > Note how poorly designed libraries that didn’t fit the language did •not• see > adoption. Note how the core community acted as good teachers to the newcomers. > >> 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. > > That contradicts the historical experience of other languages that have seen > “crossover” adoption from developers bringing very different mental models > with them. > > A Swift library released today that senselessly used dynamic member lookup > without good engineering reason would go over just about as well as an > AbstractItemManagerFactoryImpl would have gone over with the Ruby community > in 2007. > > Again, a language feature alone will not erase the good sense of the > language’s stewards, or poison its community. > > People come to Swift to write Swift. People trying to write Python or Ruby or > C in Swift will feel the friction, learn from that, adjust their habits > taking a cue from the code they find in the surrounding ecosystem, and learn > to think “Swiftly.” This has been the case in every language before Swift; it > will not stop being the case now. > > Joe hit this nail on the head: > >> On Dec 7, 2017, at 10:08 AM, Joe DeCapo via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> When I began writing Python, I initially named all my variables in camel >> case. And when I used the Subprocess module, I was passing return codes >> throughout my code base like it was bash. Even though I didn't know what was >> idiomatic in Python at that time, I could still sense a code smell in what I >> was writing. I soon learned that snake case was the standard, so I updated >> my code. And eventually I learned how to use exceptions and I refactored my >> code to use them instead of return codes. I doubt that this is unusual when >> coming to a new language with previous experience in other languages. It >> seems inevitable, and a normal process for becoming familiar with the idioms >> of a certain language community. I don't think we need to be so fearful of >> the community fracturing if people from a dynamic language background come >> to Swift and initially use those idioms. It will always be more burdensome >> to do things in a non-idiomatic way, and over time people will learn how to >> write idiomatic Swift. > > Exactly. > >> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam <letanya...@gmail.com> wrote: >> >> 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? >> >>> If a little extra language ceremony helps assuage those fears, I guess I’d >>> consider it. I still think static analysis — starting and mostly ending >>> with boring old syntax coloring — answers most all the concerns people have >>> raised, and this debate is a tempest in a teapot. >> >> I'm unsure of this, but as far as I’m aware Swift language proposals >> shouldn’t rely on editor features. But like I said I’m unsure of this and if >> someone could clarify this that would great. > > Type inference effectively does, to at least the same degree as this > proposal. See my previous post reflecting on why Java chose not to have any > sort of type inference: > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041926.html > > • • • > > It’s wise to remember Flon’s Law: > > “There is not now, nor has there ever been, nor will there ever be, any > programming language in which it is the least bit difficult to write bad > code.” > > We should design languages to make writing excellent code as pleasant and > rewarding as possible. Or more accurately, we should design them so that > there exists a way of writing excellent code that is pleasingly well suited > to the language and the ecosystem that surrounds it. > > Designing languages instead to forcibly prevent or punish bad programming is > not merely futile, but in fact actively thwarts that first goal. > > Now, how can we use dynamic member lookup in Swift to make its way of writing > excellent code more excellent still? > > Cheers, > > Paul >
Okay I’ll concede and hope that a sub community, who are forced to use Swift because of the success of this proposal and others to follow, doesn’t form creating their own separate design patterns and beliefs :) _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
