<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Should we compare dynamic member lookup to Microsoft's DLR ?<div><br><div><a href="https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/dynamic-language-runtime-overview">https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/dynamic-language-runtime-overview</a></div><div><br></div><div>Quote: </div><div><div><p class="lf-text-block lf-block" data-lf-anchor-id="85a62c6154b8203b35dd89dfcd33c753:0" style="margin-top: 1rem; margin-bottom: 0px; position: relative !important; padding-right: 25px !important;"><span style="background-color: rgba(255, 255, 255, 0);">The <em>dynamic language runtime</em> (DLR) is a runtime environment that adds a set of services for dynamic languages to the common language runtime (CLR). The DLR makes it easier to develop dynamic languages to run on the .NET Framework and to add dynamic features to statically typed languages. </span><span class="lf-mobile-thread-btn" style="position: absolute !important; right: 0px !important; top: 0px !important;"></span></p><p class="lf-text-block lf-block" data-lf-anchor-id="fbebbb43bdbf73a9386d0bcfc9f672ab:0" style="margin-top: 1rem; margin-bottom: 0px; position: relative !important; padding-right: 25px !important;"><span style="background-color: rgba(255, 255, 255, 0);">Dynamic languages can identify the type of an object at run time, whereas in statically typed languages such as C# and Visual Basic (when you use <code style="border-top-left-radius: 2px; border-top-right-radius: 2px; border-bottom-right-radius: 2px; border-bottom-left-radius: 2px; display: inline-block; padding: 3px 7px; border: 1px solid rgb(211, 214, 219); line-height: 19px; -webkit-font-smoothing: auto; direction: ltr;">Option Explicit On</code>) you must specify object types at design time. Examples of dynamic languages are Lisp, Smalltalk, JavaScript, PHP, Ruby, Python, ColdFusion, Lua, Cobra, and Groovy. </span><span class="lf-mobile-thread-btn" style="position: absolute !important; right: 0px !important; top: 0px !important;"></span></p><p class="lf-text-block lf-block" data-lf-anchor-id="f7e73cd4a9bbe4332ee18b4fe5f4c783:0" style="margin-top: 1rem; margin-bottom: 0px; position: relative !important; padding-right: 25px !important;"><span style="background-color: rgba(255, 255, 255, 0);">Most dynamic languages provide the following advantages for developers: </span><span class="lf-mobile-thread-btn" style="position: absolute !important; right: 0px !important; top: 0px !important;"></span></p><ul class="lf-text-block lf-block" data-lf-anchor-id="e4936e1346be31b91cc3bbc44b63f67b:0" style="margin: 16px 0px 16px 38px; padding-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 25px !important; position: relative !important;"><li style="list-style: disc outside none;"><p style="margin-top: 1rem; margin-bottom: 0px; position: relative !important; padding-right: 25px !important;"><span style="background-color: rgba(255, 255, 255, 0);">The ability to use a rapid feedback loop (REPL, or read-evaluate-print loop). This lets you enter several statements and immediately execute them to see the results. </span></p></li><li style="list-style: disc outside none;"><p style="margin-top: 1rem; margin-bottom: 0px; position: relative !important; padding-right: 25px !important;"><span style="background-color: rgba(255, 255, 255, 0);">Support for both top-down development and more traditional bottom-up development. For example, when you use a top-down approach, you can call functions that are not yet implemented and then add underlying implementations when you need them. </span></p></li><li style="list-style: disc outside none;"><p style="margin-top: 1rem; margin-bottom: 0px; position: relative !important; padding-right: 25px !important;"><span style="background-color: rgba(255, 255, 255, 0);">Easier refactoring and code modifications, because you do not have to change static type declarations throughout the code. </span></p></li><span class="lf-mobile-thread-btn" style="position: absolute !important; right: 0px !important; top: 0px !important;"></span></ul><p class="lf-text-block lf-block" data-lf-anchor-id="e76f7fdd244be55a245d09cf0ff7668f:0" style="margin-top: 1rem; margin-bottom: 0px; position: relative !important; padding-right: 25px !important;"><span style="background-color: rgba(255, 255, 255, 0);">Dynamic languages make excellent scripting languages. Customers can easily extend applications created by using dynamic languages with new commands and functionality. Dynamic languages are also frequently used for creating Web sites and test harnesses, maintaining server farms, developing various utilities, and performing data transformations. </span><span class="lf-mobile-thread-btn" style="position: absolute !important; right: 0px !important; top: 0px !important;"><a class="fycon-action-view" tabindex="0" aria-label="Write a Sidenote" data-lf-anchor-id="e76f7fdd244be55a245d09cf0ff7668f:0" style="-webkit-text-decoration-skip: objects; cursor: pointer; word-wrap: break-word; border: none; display: inline-block; font-stretch: normal; line-height: 18px; height: 13px; margin: 0px 0px 0px 6px; opacity: 1; position: relative; -webkit-user-select: none; background-color: rgba(255, 255, 255, 0); background-position: 0px 0px;"><font color="#000000">+</font></a></span></p><p class="lf-text-block lf-block" data-lf-anchor-id="81ed3fe94ca260b9314589dfcd114685:0" style="margin-top: 1rem; margin-bottom: 0px; position: relative !important; padding-right: 25px !important;"><span style="background-color: rgba(255, 255, 255, 0);">The purpose of the DLR is to enable a system of dynamic languages to run on the .NET Framework and give them .NET interoperability. The DLR introduces dynamic objects to C# and Visual Basic in Visual Studio 2010 to support dynamic behavior in these languages and enable their interoperation with dynamic languages.</span></p><p class="lf-text-block lf-block" data-lf-anchor-id="81ed3fe94ca260b9314589dfcd114685:0" style="margin-top: 1rem; margin-bottom: 0px; position: relative !important; padding-right: 25px !important;"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></p><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">--<br>C. Keith Ray</span><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">* <a href="https://leanpub.com/wepntk">https://leanpub.com/wepntk</a> <- buy my book?<br>* </span><a href="http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf">http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf</a><span style="background-color: rgba(255, 255, 255, 0);"><br>* <a href="http://agilesolutionspace.blogspot.com/">http://agilesolutionspace.blogspot.com/</a></span></div></div><div><br>On Dec 1, 2017, at 8:07 AM, Benjamin G via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 1, 2017 at 4:35 PM, Jon Gilbert via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Nov 30, 2017, at 08:10, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Personally, I feel this system is designed to let you write Python, using Swift as a wrapper language - except unlike with Objective-C,<br>
<br>
</span>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></blockquote><div><br></div><div>As a sidenote, the weakest points of python on the server side is compile-time type safety (none) and concurrency (almost none either). If we want to convince anyone at the moment to switch to swift on the backend, i'd say the urgent part isn't to make one or two function calls to a python library more "swifty" (but without any guarantee that we didn't mistype a function name). I'd say we should better focus on having a great agent concurrency model, as well as even better generics and faster compile time.</div><div>From what i've observed around me, people seem to migrate python code to golang. Not ruby or lisp.<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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>
<span class=""><br>
> 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>
<br>
</span>Exactly.<br>
<br>
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>
<br>
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>
<br>
Why compromise Swift’s static-ness and roll out the red carpet for the dynamic, unwashed masses?<br>
<br>
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>
<span class=""><br>
> When we consider interoperability with other languages, it should be from the perspective of mapping their features to Swift’s philosophies.<br>
<br>
</span>Amen.<br>
<span class=""><br>
> This proposal takes the reverse approach, and makes Swift like Python, so I’m against it.<br>
<br>
</span>This is my concern as well.<br>
<br>
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>
<br>
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>
<br>
Of course, maybe I am missing something here, and my opinion is wrong; Chris will let us know if these concerns are valid.<br>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
- Jon<br>
<br>
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>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></div></body></html>