[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 23:36, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
> 
> 
> 
> Regards
> (From mobile)
> 
>> On Jul 19, 2016, at 11:05 PM, Goffredo Marocchi <panajev at gmail.com> wrote:
>> 
>> 
>> 
>> 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.
> 
> Runtime optimization beats compiler hands down on long running code. Don't think swift will ever be as good as java on servers, but I don't think it is their target either, so all's well. I wish google would fork swift next year to make it more credible on servers. Don't get me wrong, swift is great.. as a successor to objc. I had high hopes when it came out, but at the moment i take far more pleasure in writting generic code in typescript. This is quite disapointing so far, and 3 is just differently unfinished than 2 was, but not fundamentally enhanced.
> 

I think we were not in disagreement :).

>> 
>> 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 ;))
> 
> At what power cost?  In the end arm is showing that simplicity works.
> 

ARM has cleverly added a lot of runtime HW enhancements over the years: wider SIMD, it used to offer predication on every instruction essentially, it added out of order execution, I would be surprised if they did not properly address Load-Hit-Store stalls by doing clever pipeline stage data forwarding, etc... but still, we agree that the simplicity of their overall approach yielded awesome results (like Alpha was having on servers).

> 
>> 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/20160720/7c7377d6/attachment.html>