+ đź’Żđź‘Ź 


> On Dec 1, 2017, at 8:35 AM, Jon Gilbert via swift-evolution 
> <swift-evolution@swift.org> wrote:
>> 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.
> Exactly. 
> 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.
> Amen.
>> 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 isn’t?
> 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 
> kidding.)
> - 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
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

swift-evolution mailing list

Reply via email to