On Fri, Dec 1, 2017 at 4:17 AM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote:
> > > > 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? > It's not about getting "Python developers" or "Ruby developers" to switch to Swift. Yes, if you believe the objective is to attract people who like Python to Swift, then you must offer something "better than Python." Now, given that some of the things that attract people to Python have to do with its dynamic behavior, you've defined an impossible task right off the bat. But that's not the objective here and it misses the point entirely. No, the motivation instead is this: Why would someone--someone who might not even know Python or Ruby--choose to use those languages? Why does some bother to learn Python or Ruby other than curiosity or love of the language itself? The answer is that there are some tasks that are best accomplished using those languages because of libraries and their user communities--so much better than one's other favorite languages that those other languages are not even in contention. In my case, many excellent computational biology tools were only available (nowadays, are most mature and have the biggest ecosystem of users) in languages such as Python or Perl. So the use case here is, how do we make Swift a viable candidate for doing those things which today drive users to Python? The answer here is _not_: build a better Python. Nor does it require, out of the gate, even being as good as Python. The solution is to provide a _reasonably_ ergonomic to _interoperate with libraries available in Python_, with the benefit that those parts that you can write in native Swift will make the overall result safer and faster, etc. Again, it's _not_ about "scooping up developers of other languages"--it's about expanding the universe of computational tasks for which Swift is a viable candidate. This is why, also, Chris's insistence that the solution be equally available in the REPL and in Playgrounds is so important.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
