On Dec 1, 2017, at 02:44, Xiaodi Wu via swift-evolution 
<swift-evolution@swift.org> wrote:
> 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.

I think we would be better served by a transpiler that translates Python (etc.) 
into Swift at compile time. 

Look what Google did with j2objc (https://github.com/google/j2objc). It 
translates Java right into Objective C. You can even put your Java code right 
in XCode and it auto-translates at build time. 

Clearly, this is no small feat, and j2objc is a technical marvel that took 
world-class engineers years to perfect. 

My point is, “Dynamic Member Lookup” is not the only solution, and it’s not the 
ideal solution if indeed it compromises the static guarantees of Swift.

Therefore, we should consider what other approaches might entail. The main 
players in Swift have lots of money and technical resources they could pour 
into a set of revolutionary transpilers. 

Surely we don’t want to allow Goole to be the only company to provide a library 
that translates other codebases directly to a primarily Apple language, do we?

That being said, I am still interested to hear Chris’s response to these 
concerns, and if they were already addressed on a previous message and I missed 
that, then please forgive me.

- Jon
swift-evolution mailing list

Reply via email to