[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Paul Cantrell]

> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam <letanyan.a at 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 at 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 <letanyan.a at 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