[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Goffredo Marocchi]

Sent from my iPhone

> On 19 Jul 2016, at 19:37, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
> 
> 
> 
> Regards
> (From mobile)
> 
>> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>>> <off-topic>
>>> 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.
>>> 
>>> 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.
>> 
>> ... rantish...
>> 
>> 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
> 
> That is a fact back by some interesting papers.

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?

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.

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?

> By it is also true that one cannot always be used in place of the other.
> 
>> ... 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.
>> 
>> 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). 
>> 
>> 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.
>> 
>> Sorry for the even more off topic bit and thank you to those people who read this.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160719/fe3f9a94/attachment.html>