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.


> On 1 Dec 2017, at 17:38, C. Keith Ray via swift-evolution 
> <> wrote:
> Should we compare dynamic member lookup to Microsoft's DLR ?
> <>
> 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
> * <> <- buy my book?
> * 
> <>
> * 
> <>
> On Dec 1, 2017, at 8:07 AM, Benjamin G via swift-evolution 
> < <>> wrote:
>> On Fri, Dec 1, 2017 at 4:35 PM, Jon Gilbert via swift-evolution 
>> < <>> wrote:
>> > On Nov 30, 2017, at 08:10, Karl Wagner via swift-evolution 
>> > < <>> 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 mailing list
>> <>
>> <>
> _______________________________________________
> swift-evolution mailing list

swift-evolution mailing list

Reply via email to