> On 1. Dec 2017, at 07:05, Chris Lattner via swift-evolution 
> <swift-evolution@swift.org> wrote:
> Hi Doug,
> Thank you for the detailed email.  I have been traveling today, so I haven’t 
> had a chance to respond until now.  I haven’t read the down-thread emails, so 
> I apologize if any of this was already discussed:
>> I think better interoperability with Python (and other OO languages in 
>> widespread use) is a good goal, and I agree that the implementation of the 
>> feature described is straight-forward and not terribly invasive in the 
>> compiler.
> Fantastic, I’m really pleased to hear that!  I only care about solving the 
> problem, so if we can find a good technical solution to the problems than 
> I’ll be happy.
> A funny thing about swift-evolution is that it is populated with lots of 
> people who already use Swift and want to see incremental improvements, but 
> the people who *aren’t* using Swift yet (but should be) aren’t represented 
> here.  As you know, I’m perhaps the biggest proponent of Swift spreading into 
> new domains and earning the love of new users.

I don’t really appreciate that argument. You also need to consider: what 
improvements are we offering these people who don’t yet use Swift?

For Objective-C developers, the static typing and resulting performance and 
safety improvements made this a worthwhile switch. Plus, we could interoperate 
very well with existing Objective-C codebases and libraries (e.g. we can have 
generic subclasses of NSObject!), so we could actually use a lot of these nice 
features when writing our mac/iOS applications.

For Python developers, I gather the pitch would be similar: Swift has all kinds 
of nice features which will make your code safer and faster. We’re unlikely to 
achieve the same tight integration with Python (or any other language) that we 
have with Objective-C, though. We used to rely a lot on AnyObject, but since 
Objective-C made the importing experience so much better, you rarely (if ever) 
see it in practice. Objective-C can also be more dynamic than we show it as - 
you can have methods which are not declared anywhere, and which the object 
synthesises during its message-handling routines. We don’t support calling 
these non-existing methods on Objective-C objects, so why should we allow it 
for these objects?

My worry is that in eagerness to try and scoop up developers of other 
languages, that we diminish the Swift language to the point where it doesn’t 
really provide a benefit for them. Python developers will be writing the same 
unsafe, non-checked code using Swift that they do in Python; where’s the win?

- Karl
swift-evolution mailing list

Reply via email to