Sent from my iPhone > On 19 Jul 2016, at 23:36, L. Mihalkovic <laurent.mihalko...@gmail.com> wrote: > > > > Regards > (From mobile) > >> On Jul 19, 2016, at 11:05 PM, Goffredo Marocchi <pana...@gmail.com> wrote: >> >> >> >> Sent from my iPhone >> >>> On 19 Jul 2016, at 19:37, L. Mihalkovic <laurent.mihalko...@gmail.com> >>> wrote: >>> >>> >>> >>> Regards >>> (From mobile) >>> >>>> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution >>>> <swift-evolution@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@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
