> On Nov 30, 2017, at 08:10, Karl Wagner via swift-evolution 
> <swift-evolution@swift.org> wrote:
> Personally, I feel this system is designed to let you write Python, using 
> Swift as a wrapper language - except unlike with Objective-C,

Let me paraphrase the proposal—it basically says this system is designed to 
make it easier to “fake import” existing Python/Ruby/JS libs to make it easier 
for people who depend on them to adopt Swift. Especially in the world of 
server-side Swift, I can see how this could help speed Swift’s adoption.

However, I believe that you bring up an extremely valid concern. To extrapolate 
from your points, this proposal seems to have a high potential to erode what 
makes Swift special, and it provides a way to get around Swift’s safe-guards, 
avoid writing Swift versions of libraries, and ultimately, avoid hiring real 
Swift developers. 

> it doesn’t have any static information about what you can do or not. It can’t 
> provide the “safe by default” guarantees are other core principles and set 
> Swift apart from other languages.


Look how JSON parsing is done in Swift 3.2 and 4.0—we make static types. The 
1’s and 0’s from a web response go through layers of proper error handling 
before they become proper types Swift.

So why does this proposal keeps mentioning JSON parsing as an excuse for making 
a dynamic ghetto within the language? Because some people are parsing untyped 
JSON? Well, the solution for that is, type your frickin’ JSON. 

Why compromise Swift’s static-ness and roll out the red carpet for the dynamic, 
unwashed masses?

Wouldn’t it be better to create an AI that quickly translates Pyton, Ruby, or 
JS into Swift? Augustus built huge public bathhouses for the unwashed Romans. 

> When we consider interoperability with other languages, it should be from the 
> perspective of mapping their features to Swift’s philosophies.


> This proposal takes the reverse approach, and makes Swift like Python, so I’m 
> against it.

This is my concern as well. 

Perhaps there is a way to make the proposal require that you declare Swift 
types and protocols that map to these other languages, with verbose error 
handling for when this glue breaks down (just like we have for typed JSON). 

Then, we could also make scripts that auto-generate the necessary Swift typing 
boilerplate interface code from the Python/Ruby/JS source, kinda like we get 
for Obj.-C bridging headers. This could be a good step towards the full AI 
translation that I mentioned.

Of course, maybe I am missing something here, and my opinion is wrong; Chris 
will let us know if these concerns are valid.

However, I hope we don’t hear how we are just being paranoid, because I assure 
you, this is not paranoia. It’s just about maintaining the static-ness and 
purity of Swift to help save the world from bad code.

Everything in life and engineering is a trade-off. Swift’s trademark is that it 
consistently sacrifices the convenience of dynamic-ness for the safety and 
performance of static-ness. This proposal does seem to do the opposite, and 
we’d be naive not to fear the effect this will have. 

Ask yourself... what if Product knows about it? The last conversation a tech 
lead or engineering manager wants to have, I would imagine, is to explain on 
deaf ears why it would be bad to cut costs by farming out the iOS work to a 
cheap Python shop overseas, then just wrap it in sugary compiler hooks. Or why 
it would be bad for a Swift project to depend upon a stack of third-language 
dependencies that CocoaPods/Carthage can’t manage, XCode can’t analyze, stack 
traces can’t delve into (or can it?), lldb can’t step through, etc.

I do not believe this is unreasonable paranoia, I just believe it looks that 
way to people who work with an elite squad of engineers at a top company, who 
have perhaps not seen what goes on at most places, where budgets are tight and 
lots of people are not the biggest fans of Apple. It’s already with much 
grinding of teeth that non-Windows, non-Linux devs are necessary.

Given Swift’s emphasis on safety, this push to make danger easier really does 
surprise me, unless I just don’t understand this correctly. Have we 
re-evaluated the importance of having the language itself prohibit bad 
practices? Or is there some reason why this proposal does not actually make it 
easier to write code that looks like good, type-safe Swift code, but actually 

Finally, to really be honest, may I ask why web devs, many of whom never 
touched a line of Swift, deserve all this dynamic sugar, while on the other 
hand, we SWIFT devs don’t get any? How will people feel who were told that 
dynamic is so unsafe that Swift was designed to prevent it altogether? People 
who have been through all the migrations and member-wise trenches might chafe a 
bit. Is that unreasonable?

Lastly, if you can “fake import” Javascript or Python to Swift via this 
proposal, is there anything that would prevent the “fake import” of 
masquerading Swift modules? In other words, could lazy devs who want hacky 
dynamic-ness abuse this? If so then maybe I’m in favor after all ;P (Just 

- Jon

PS—I am just trying to think critically here. Ultimately this proposal would 
not hurt me, but I am just worried about the big picture. I can see why it’s a 
tough call and I am sure that some pressures exist that might make even this 
compromise to be worth it. I just feel like we should not underestimate how 
much bad will come along with the good, nor should we assume, “Well that kind 
of bad would never happen where I work, and only idiots would abuse this.”
swift-evolution mailing list

Reply via email to