<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Comments inline (resent to swift evolution)<br class=""><br class=""><blockquote type="cite" class="">On 7 Jul. 2016, at 4:28 am, Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hi there<br class=""><br class="">From the perspective from many active programmers<br class="">that use Swift (not objective C anymore) I am not<br class="">very happy by having to change<br class="">program source all the time: <br class=""><br class="">Therefore after Swift 3.0 is released I’d recommend kindly:<br class=""><br class=""><br class="">Freeze Swift For Some Time! <br class="">Do Not Change AnyThing For At Least 2 Years.<br class="">(Yes you’ve read that correctly: two years.)<br class=""></blockquote><br class="">Freezing seems antithetical to the evolution of new features. Avoiding source-breaking changes is reasonable, and I believe this is plan going forward. Even then, making this a hard rule still ends up with the same issue: the more we delay changes, the more we just push out the inevitable and drag the pain out longer.<br class=""><br class=""><blockquote type="cite" class=""><br class="">Still there? OK, read on:<br class=""><br class="">In the mean time, you’ll have the great opportunity<br class="">to fine-tune compiler and run time systems, to eliminate<br class="">the few bugs there and make it blazingly fast!<br class=""></blockquote><br class="">This discounts the fact that a lot of the speed improvements don't simply come from a smarter compiler. Many improvements in speed and compilation are held back by a lack of guarantees that the compiler can rely on due to the language's limitations. Swift's efficiency and performance comes from the language-specific guarantees that the compiler can leverage. While there are some guarantees that aren't currently leveraged in the compiler, this statement appears to some extent contradictory. "Make it faster, but don't change anything!”<br class=""><br class=""><blockquote type="cite" class="">In two (or more) years, there are enough Real Users (programmers) <br class="">that by then will have enough practical experience with Swift, which<br class="">might play a more solid role in improving Swift, and of course,<br class="">are extremely happy with Swift, and that it is not changed<br class="">all the time, So that they can concentrate on writing cool,<br class="">reliable and decent programs, instead of revising it all<br class="">the time! <br class=""></blockquote><br class="">So we wait to get a larger user base so we hurt *more* people when we do this? Why?<br class=""><br class=""><blockquote type="cite" class=""><br class="">After such time, and much more intensive and practical usage, <br class="">it becomes clear, what is good in Swift and what is not. <br class=""></blockquote><br class="">Because the current team don't have enough experience with swift to work it out, but a year or two more of doing the same thing without any changes will somehow give them that experience?<br class=""><br class=""><blockquote type="cite" class="">What happens now, for instance, is that some base their “statistics” of which <br class="">language elements etc. are frequently used or not, merely upon scanning <br class="">a codebase of the relatively few (compared with e.g. ObjC, Java or C#) programmers<br class="">that use Swift now<br class=""></blockquote><br class="">Statistics aren't everything. Focusing on a few language elements at the neglect of the rest is ill-advised. Do you build a house but only focus on building a foundation well only in the rooms you expect people to walk in?<br class=""><br class=""><blockquote type="cite" class=""><br class="">Imho, Swift has not yet been in use long enough. It needs a prolonged time <br class="">because now, most users have relatively little experience using Swift, <br class="">thus the way they program now is not really representative with what one really can do<br class="">with this powerful language, compared to experienced (years, not months) <br class="">programmers in other languages. <br class="">Still a lot has to be discovered, has to settle and form good mental pictures in <br class="">programmer’s minds. It is all going a bit too fast, I think.<br class=""><br class=""><br class="">Please (if you did’t already) realize that already many source<br class="">code all over the world is written in Swift therefore it is very, very<br class="">important that backwards compatibility should be preserved as much <br class="">as possible. because backwards-breaking-changes are a disaster<br class="">to companies/individuals that have already hundreds or thousands<br class="">of programs written in Swift.<br class=""></blockquote><br class="">I think everyone is aware there are commercial and logistical issues with continuing to change Swift. That's why there was such a rush to bake every source-breaking change into Swift 3. There will have to be a very good justification going forward for source breaking changes.<br class=""><br class=""><blockquote type="cite" class=""><br class="">For comparison, until recently I did also programming projects on IBM<br class="">mainframes for banks, insurance companies etc. The systems they use consists<br class="">(per company) of literally thousands of Cobol and/or PL/1 programs written<br class="">in all the years from ca 1970 until now. Still, one can take a program written<br class="">in 1970 which compiles and runs flawlessly without any modification!<br class="">All is backward compatible. If you would break backward<br class="">compatibility in this domain you would probably be kicked of the planet..<br class=""></blockquote><br class="">If we went by this reasoning they should never have changed anything since Swift 1. If backwards compatibility and guaranteed compilation is a requirement, nothing would ever improve.<br class=""><br class=""><blockquote type="cite" class=""><br class="">But even if we remain in macOS or iOS development, a huge amount of source<br class="">code has been written in Objective C. Everyone would scream hell if you took<br class="">out or change language elements.. <br class="">So please don’t. (it’s unnecessary) <br class=""></blockquote><br class="">In the opinion of the vast majority here, the benefits of quickly changing things at the start of Swift's life will outweigh the pain to the early adopters, and there are mitigation strategies in place.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class="">When Swift arrived, to me, it had already everything I need, not really missing anything.<br class="">Of course, a programming language -like all things in life- is never perfect.<br class=""></blockquote><br class="">And yet there have been massive changes to swift that have radically improved it since then.<br class=""><br class=""><blockquote type="cite" class=""><br class="">To me it was also perfectly OK that Swift wasn’t open source, because those that<br class="">have made Swift did a very good job. So one could even start thinking, why<br class="">open source Swift? Why not leave it to Apple? <br class="">But I guess I won’t make many friends asking this..<br class="">And I also realize that many good ideas comes from open source.<br class=""><br class=""><br class="">To me, Swift 2.2 and also 3.0 is fine. <br class="">so, after that:<br class="">you don’t have to change a thing.<br class="">it works and has everything I need<br class="">and is fast and stable. <br class="">stop removing things.<br class="">thanks.<br class=""></blockquote><div class=""><br class=""></div>The crux of your argument seems to be: "Make it better, but don't change anything!"<br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class="">Kind Regards from beautiful <a href="http://speyer.de" class="">Speyer.de</a> in Germany<br class=""><br class="">TedvG<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></body></html>