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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
