Hi Magnus, You raise an excellent point.
The swift journey has been interesting to watch, for sure. I do not believe anyone has ever started with a rigidly typed system and then tried to make it more dynamic (Java JVM dynamicInvocation work by Bracha notwithstanding). There have been several languages that started out as purely dynamic that then added optional type annotations to get compilers to be a little more helpful. Strongtalk, Objective C v1, etc. But starting out with a rigid static bias and trying to add in dynamic features seems a lot harder than going the other way. Anyhow, I have heard for years this argument about how helpful compilers are when there is abundant type information. My experience leaves me personally skeptical but more to the point - where's the actual proof? Here's a blog post with a lot of links to studies trying to assess whether static-type heavy systems actually reduce defects and make people more productive. https://danluu.com/empirical-pl/ Don't just read the page, follow the links and read the studies. This continues to be argued at YCombinator. https://news.ycombinator.com/item?id=15384351 And there is this discussion of a talk called "The unreasonable effectiveness of dynamic typing". https://games.greggman.com/game/dynamic-typing-static-typing/ Bottom line - I want to see the proof too. I think everything should be DynamicLookupable - especially library code since the library creator cannot know in advance how his code may be used and it may well want to be bridged from another environment but then I have been doing a lot of bridging of Pharo Smalltalk to native C libraries via FFI lately and I firmly believe bridges need to run both ways. It is easy to bridge Objective C from Smalltalk. Swift, OTOH, looks nigh impossible as it is. > On Dec 4, 2017, at 10:20 AM, Magnus Ahltorp via swift-evolution > <swift-evolution@swift.org> wrote: > > >> 5 Dec. 2017 01:08 Benjamin G via swift-evolution <swift-evolution@swift.org> >> wrote: >> >> Unless DynamicLookup is used to circumvent every compiler warning or errors >> thrown at you by the language because your design is unsound. Something like >> "ho, yeah swift generics and protocols aren't really working fine together >> for your case, but just make everything DynamicLookupable and you'll be all >> set". Or "This JSON document has a really complex schema. Let's just not >> specify anything, and call the fields like this, you won't even feel any >> difference anyway". > > We have heard these horror tales about everyone making "everything > DynamicLookupable" and this being extremely bad, but can anyone actually > produce a believable example? It's not like it's absurdly convenient to > implement this, the ergonomics are at the call site, not the implementation. > It sounds like you think that just conforming to DynamicMemberLookupProtocol > and DynamicCallable will magically make everything in the code dynamic with > no extra effort. > > /Magnus > > _______________________________________________ > 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
