The semantics of the DLR seems fairly similar to Chris’ proposal, does it not? Btw, this makes me think that I would prefer to have one proposal contain both dynamic member lookup and dynamic method calls: it would be kind of silly to have one accepted and not the other.
David. > On 1 Dec 2017, at 17:38, C. Keith Ray via swift-evolution > <swift-evolution@swift.org> wrote: > > Should we compare dynamic member lookup to Microsoft's DLR ? > > 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> > > Quote: > The dynamic language runtime (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. > 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 Option > Explicit On) you must specify object types at design time. Examples of > dynamic languages are Lisp, Smalltalk, JavaScript, PHP, Ruby, Python, > ColdFusion, Lua, Cobra, and Groovy. > Most dynamic languages provide the following advantages for developers: > 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. > 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. > Easier refactoring and code modifications, because you do not have to change > static type declarations throughout the code. > 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. + <> > 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. > > -- > C. Keith Ray > > * https://leanpub.com/wepntk <https://leanpub.com/wepntk> <- buy my book? > * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf > <http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf> > * http://agilesolutionspace.blogspot.com/ > <http://agilesolutionspace.blogspot.com/> > > On Dec 1, 2017, at 8:07 AM, Benjamin G via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >> >> On Fri, Dec 1, 2017 at 4:35 PM, Jon Gilbert via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> > On Nov 30, 2017, at 08:10, Karl Wagner via swift-evolution >> > <swift-evolution@swift.org <mailto: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. >> >> 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. >> From what i've observed around me, people seem to migrate python code to >> golang. Not ruby or lisp. >> >> >> >> >> 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 <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > 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
