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

Magnus Ahltorp map at kth.se
Mon Dec 4 11:58:49 CST 2017


> 5 Dec. 2017 02:25 Joe DeCapo via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Dec 4, 2017, at 11:15 AM, Tino Heth <2th at gmx.de> wrote:
>> 
>>> 
>>> This is a bridge to allow easy access to the vast number of libraries that currently exist in those dynamic language domains, and to ease the transition of the multitudes of those programmers into Swift.
>> 
>> I’ve read several posts that gave me the impression that Python has a huge user base of people who are tired of using that language (the cited statement is just an arbitrary pick)… but is that actually true?
>> Afaik, Python never became as common as Java, C# or C++, and it never had much support from big companies — people decided to use Python not because it’s some sort of standard, but because they liked it and found it to be a language that’s easy to learn.
>> 
>> So the whole story of „let’s make it easier for those poor Python guys to switch to a real language“ sounds very much like hubris to me.
>> Of course, that statement is an exaggeration, but still:
>> Did anyone ever ask the Python-community who actually wants to switch to Swift? I don’t think there would be enough positive feedback to take it as a justification for the proposed changes.
> 
> That's not really what I meant, and I haven't gotten the impression that that's the main motivating reason. Partly it's for the benefit of the Swift community to leverage many currently existing, mature libraries that exist but are written in dynamic languages. And it makes it possible for someone interested in trying out Swift who has experience with those libraries to still be able to leverage the things they're already familiar with during the transition. There may not be an overwhelming number of developers who have to work in these languages but would prefer Swift, but I don't think there necessarily needs to be for this to still be a worthwhile change.

Yes, there are many of us that have extensive experience with both Python and Swift, and many more who have experience with Python libraries that want to write their code in Swift because it fits better with some other part of their project. Maybe not because they want to desert Python, and maybe not because they love Swift, but because it's a better way to solve that particular problem.

Before Swift existed, I wrote high-level parts of a project in Python because it was untenable to do it in Objective-C (it was actually much easier for me to write a bridge *and* the Python code than to write it in Objective-C), but now I have rewritten those parts in Swift, because I could throw out the Python runtime and write interface code and logic code in the same language. I didn't depend on any critical Python libraries, but others will, and if they want to write Cocoa code in Swift, they have to have a Python bridge, and the probability that a high-quality Python bridge will exist is much lower if the syntax is awful. This of course goes for other dynamically typed languages as well.

/Magnus



More information about the swift-evolution mailing list