<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Responses inline.</div><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 1, 2017, at 8:35 AM, Jon Gilbert via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On Nov 30, 2017, at 08:10, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Personally, I feel this system is designed to let you write Python, using Swift as a wrapper language - except unlike with Objective-C,<br class=""></blockquote><br class="">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.<br class=""><br class="">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. <br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>The point is not to let you write Python in Swift. If you want to write Python, just write Python. The point is to let you <i class="">call</i> Python libraries (or any dynamic language) <i class="">from</i> Swift, in the same way that we can already call C libraries from Swift. The ability to call C libraries does not make people “avoid hiring real Swift developers”; it just means that Swift developers can take advantage of C libraries. The goal of this proposal is to make Swift able to use <i class="">more</i> existing libraries. It sounds like your argument is “we want people to rewrite those libraries in Swift instead”. That’s a great goal, but it will only be achieved if Swift gains the kind of widespread cross-platform adoption that would be facilitated by this very proposal.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">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.<br class=""></blockquote><br class="">Exactly. <br class=""><br class="">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.<br class=""><br class="">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. <br class=""></div></div></blockquote><div><br class=""></div><div>It doesn’t. There was one brief mention of a JSON example, to show how this proposal is useful for more than just Python interop. But most of the proposal talks about Python, not JSON.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Why compromise Swift’s static-ness and roll out the red carpet for the dynamic, unwashed masses?<br class=""><br class="">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. <br class=""></div></div></blockquote><div><br class=""></div><div>If you can create an AI that quickly and <i class="">accurately</i> translates Python, Ruby, and JS into Swift, go right ahead. To the extent that those projects are not taking advantage of the dynamic features of their language, that’s likely feasible. It’s going to be a lot more difficult for the kind of code that <i class="">does</i> take advantage of the dynamic nature of the language. For example, dynamic languages can inspect the function name to vary its behavior. You can write one “<font face="Menlo" class="">fetchAll____FromDatabase()</font>” function, and then call it as <font face="Menlo" class="">fetchAllEntiresFromDatabase()</font>, <font face="Menlo" class="">fetchAllUsersFromDatabase()</font>, or <font face="Menlo" class="">fetchAllCommentsFromDatabase()</font>, and automatically get the right behavior. I don’t think you’re going to be able to automatically create an AI that mimics that behavior on Swift; it fundamentally relies on the dynamic binding present in those languages.</div><div><br class=""></div><div>It’s clear that you think dynamic languages are inferior to static languages. That’s fine, but the fact is that there are existing <i class="">useful</i> libraries in those languages which do not currently exist in Swift. Is it your argument that Swift should not be able to make use of such libraries because of their “unclean-ness”? I disagree.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">When we consider interoperability with other languages, it should be from the perspective of mapping their features to Swift’s philosophies.<br class=""></blockquote><br class="">Amen.<br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">This proposal takes the reverse approach, and makes Swift like Python, so I’m against it.<br class=""></blockquote><br class="">This is my concern as well. <br class=""><br class="">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). <br class=""><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class="">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.<br class=""><br class="">Of course, maybe I am missing something here, and my opinion is wrong; Chris will let us know if these concerns are valid.<br class=""><br class="">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.<br class=""></div></div></blockquote><div><br class=""></div><div>You seem to conflate “libraries written in a dynamic language” with “bad code”. That’s an unjustified assumption that ignores the large quantity of existing <i class="">very useful </i>libraries written in those languages. Or maybe you’re assuming that if this proposal goes through, people will choose to write dynamic code in their native Swift projects? It’s certainly possible that some people will do that, but the way this proposal is written makes it unlikely for dynamic behavior to spread throughout the project itself, because you still need an underlying source of dynamism. This proposal only makes it possible to call into an existing dynamic system; it does not introduce a new dynamic system directly into Swift.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class="">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. <br class=""><br class="">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.<br class=""><br class="">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.<br class=""></div></div></blockquote><div><br class=""></div><div>If someone’s wanting to farm out their iOS app to a 3rd party, they can already do that, whether or not Swift supports calling into dynamic libraries. They can even already do it from Swift with the existing C API for calling Python, in fact; this proposal just makes it a little easier. But if the entire app is really written in Python, a few C shims to get into Python-land aren’t a large burden. And they can already do it via ObjC as well. I think it’s unlikely that writing an entire iOS app in Python would be an efficient way to do things, but if that’s actually a better way to write the project, why are we stopping them? Is it the goal of the core team to encourage people to use Swift even when it’s not the best choice? I would suggest rather that the goal should be to improve Swift to make it the best choice. If that means being able to call into some existing business logic written in <font face="Menlo" class="">dyanmic_language_here</font>, why is that problematic? If an engineering manager cannot make a convincing case that writing their app in Swift or ObjC is a better idea, then perhaps there’s not much of a case to be made. I find this scenario implausible, though, for a variety of reasons. For one, Python code can’t take advantage of the various system frameworks like Swift or ObjC can.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">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?<br class=""><br class="">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?<br class=""></div></div></blockquote><div><br class=""></div><div>It seems odd that you talk about “deserving” dynamic sugar. The goal of this proposal is to make it easier to use more existing libraries, via a little bit of sugar goes a lot way toward that goal. <i class="">All</i> Swift users can take advantage of that. If we can make Swift a more viable language for web development (by enabling them to use existing dynamic libraries) without harming the language, why shouldn’t we? Of course, I think your argument is that this proposal does harm the language, but I fail to see how that’s the case. This proposal does precisely <i class="">nothing</i> to the language unless you’re calling methods on a type that conforms to <font face="Menlo" class="">DynamicMemberLookupProtocol</font>. And when you’re doing that, the dynamism is well contained; it only exists those types. None of your other code is affected in any way.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">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.)<br class=""></div></div></blockquote><div><br class=""></div><div>You can’t “fake import” Swift modules using this, because there’s no good way to look up Swift classes or methods by name, so you would have no way to make it work. This is about leveraging existing dynamic systems, not introducing new ones.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">- Jon<br class=""><br class="">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.”<br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class=""><br class=""></div>-BJ<br class=""><br class=""></body></html>