+ đź’Żđź‘Ź Dave
> 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
