<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;"><br></div><br>Sent from my iPhone</div><div><br>On 19 Jul 2016, at 19:37, L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com">laurent.mihalkovic@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><br><div>Regards</div>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "> mobile)</span></div><div><br>On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><div style="direction: inherit;"><br></div>Sent from my iPhone</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><span></span><span><off-topic></span><br><span>Cocoa currently hides the boilerplate for all of these wonderful constructs behind amazingly effective runtime acrobatics. This fits perfectly into Objective-C, and it also works very well in Swift. But such features could be in better harmony with Swift's unique set of language constructs if their boilerplate was hidden behind amazingly effective **compile-time** acrobatics instead.</span><br><span></span><br><span>Such compile-time acrobatics are hard to perform today, and it is possible that the ability to create such systems will forever remain an advanced skill, just like forging runtime magic requires advanced skills in Objective-C.</span><br></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">... rantish...</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">I am still not convinced that even the best compiler can fully replace what a powerful runtime can provide no matter the acrobatics you put in in terms of compiler introduced utility code/constructs or the code analysis efforts you can put in at compile time</div></div></blockquote><div><br></div><div>That is a fact back by some interesting papers. </div></div></blockquote><div style="direction: inherit;"><br></div><div style="direction: inherit;">It would be interesting if this is practical or a theoretical you could, but would you? Can such a compiler exist and if it does what is preventing it from being the standard way we build software with? Recursion only languages are possible and a fact too. Do you have some links btw?</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">All the magic comes with a price ;), what is the price of only relying on static code analysis? How much do we pay in productivity? Nothing is free.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">How much would we pay in performance if one day the CPU takes the same approach and throws branch predictors, prefetchers, register renaming and reorder buffers, store-load forwarding, etc... (I am also insanely convinced that given proper funds and a modern manufacturing process IA-64 had a chance to prove itself and kick some ass ;)) and we have another go at VLIW?</div><div style="direction: inherit;"><br></div><blockquote type="cite"><div><div>By it is also true that one cannot always be used in place of the other.</div></div></blockquote><blockquote type="cite"><div><br><blockquote type="cite"><div><div style="direction: inherit;">... unless that work essentially replaces the runtime. Do we want to help coders with a great compiler and static analysis tools? Yes! Do we need to castrate the runtime to achieve this making it physically impossible for developers to escape the controlled environment we strictly want them to live in? I do not think so and we may regret the results once everything including UI and app frameworks are all Swifty™ (it is starting to get marketing firm icky when a discussion is stopped when this word is invoked or inflamed by a disagreement on who is more swiftly orthodox). I think that without holding technology back due to fear, we should not proceed only with the assumption that old way == worst thing ever while new way == it is new and young, it must be good.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Objective-C did not survive and thrive in Cocoa for so many years completely in spite of its many many deficiencies as sometimes it seems on this list (Objective-C being put down more than necessary IMHO... Swift does not need this kind of sometimes slightly biased comparison to be appreciated in full, but it can stand on its own merits). </div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Maybe the reason we like Cocoa/Cocoa Touck/AppKit/UIKit/etc... is precisely because of the beautiful balance it strikes between (sometimes leaning more on developers opting-in) safety and versatility allowing good code to be produced and tested quickly thus allowing easier prototyping, refactoring, and iterative development.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Sorry for the even more off topic bit and thank you to those people who read this.</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></blockquote></body></html>