[swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

Thu Jul 7 06:35:02 CDT 2016

Both are examples of languages that do not have a lot of sytax/features/complexity. Such languages are more easily production-ready from day 1.

The major issue with Swift and its evolution is how to interact with existing APIs that are written in another language (ObjC), which is vastly different. When you look at the proposals for Swift 3, lot of them are focused on interoperability and refining the Foundation API.

These things aren't easy to design and they even may look well at the design stage, but time proves that they need some tweaking. It also requires a lot of work and some features require others to be present first for the others to be implemented.

Sure, we could maintain backward compatibility by having name aliases, etc. but it was clearly noted that neither API nor ABI is final for Swift 1 or 2. It's better to shed these off rather than litter the language.

Moreover, most changes will be automatically migrated by Xcode's Migration Assistant...

> On Jul 7, 2016, at 1:17 PM, ChanMaxthon via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Code compiled well with the original ISO C compiler still compiles well with the latest C standards.
> 
> I just found some of my original Visual Basic .net 2002 code written just after it was released, and it builds and works beautifully in Visual Basic .net 2015. (I did not join the Apple Developer family until 2012, before that I was a Windows desktop and Windows Mobile developer)
> 
> One of my projects written in 2010 and using Visual Studio 2010 still works bug-free on Windows 10 and still builds under Visual Studio 2015, despite the project being long abandoned.
> 
> 
> 
> Sent from my iPhone
> 
> On Jul 7, 2016, at 17:38, Rod Brown via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> Comments inline (resent to swift evolution)
>> 
>>> On 7 Jul. 2016, at 4:28 am, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hi there
>>> 
>>> From the perspective from many active programmers
>>> that use Swift (not objective C anymore) I am  not
>>> very happy by having to change
>>> program source all the time:   
>>> 
>>> Therefore after Swift 3.0 is released I’d recommend kindly:
>>> 
>>> 
>>> Freeze Swift For Some Time! 
>>> Do Not Change AnyThing For At Least 2 Years.
>>> (Yes you’ve read that correctly: two years.)
>> 
>> 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.
>> 
>>> 
>>> Still there? OK, read on:
>>> 
>>> In the mean time, you’ll have the great opportunity
>>> to fine-tune compiler and run time systems, to eliminate
>>> the few bugs there and make it blazingly fast!
>> 
>> 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!”
>> 
>>> In two (or more) years,  there are enough Real Users (programmers) 
>>> that by then will have enough practical experience with Swift, which
>>> might play a more solid role in improving Swift, and of course,
>>> are extremely happy with Swift, and that it is not changed
>>> all the time, So that they can concentrate on writing cool,
>>> reliable and decent programs, instead of revising it all
>>> the time! 
>> 
>> So we wait to get a larger user base so we hurt *more* people when we do this? Why?
>> 
>>> 
>>> After such time, and much more intensive and practical usage, 
>>> it becomes clear, what is good in Swift and what is not. 
>> 
>> 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?
>> 
>>> What happens now, for instance, is that some base their “statistics” of which 
>>> language elements etc. are frequently used or not, merely upon scanning 
>>> a codebase of the relatively few (compared with e.g. ObjC, Java or C#) programmers
>>> that use Swift now
>> 
>> 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?
>> 
>>> 
>>> Imho, Swift has not yet been in use long enough. It needs a prolonged time 
>>> because now, most users have relatively little experience using Swift, 
>>> thus the way they program now is not really representative with what one really can do
>>> with this powerful language, compared to experienced (years, not months) 
>>> programmers in other languages. 
>>> Still a lot has to be discovered, has to settle and form good mental pictures in 
>>> programmer’s minds. It is all going a bit too fast, I think.
>>> 
>>> 
>>> Please (if you did’t already) realize that already many source
>>> code all over the world is written in Swift therefore it is very, very
>>> important that backwards compatibility should be preserved as much 
>>> as possible. because  backwards-breaking-changes are a disaster
>>> to companies/individuals that have already hundreds or thousands
>>> of programs written in Swift.
>> 
>> 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.
>> 
>>> 
>>> For comparison, until recently I did also programming projects on IBM
>>> mainframes for banks, insurance companies etc. The systems they use consists
>>> (per company) of literally thousands of Cobol and/or PL/1 programs written
>>> in all the years from ca 1970 until now. Still, one can take a program written
>>> in 1970 which compiles and runs flawlessly without any modification!
>>> All is backward compatible. If you would break backward
>>> compatibility in this domain you would probably be kicked of the planet..
>> 
>> 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.
>> 
>>> 
>>> But even if we remain in macOS or iOS development, a huge amount of source
>>> code has been written in Objective C. Everyone would scream hell if you took
>>> out or change language elements.. 
>>> So please don’t. (it’s unnecessary) 
>> 
>> 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.
>> 
>>> 
>>> 
>>> When Swift arrived, to me, it had already everything I need, not really missing anything.
>>> Of course, a programming language -like all things in life- is never perfect.
>> 
>> And yet there have been massive changes to swift that have radically improved it since then.
>> 
>>> 
>>> To me it was also perfectly OK that Swift wasn’t open source, because those that
>>> have made Swift did a very good job. So one could even start thinking, why
>>> open source Swift? Why not leave it to Apple? 
>>> But I guess I won’t make many friends asking this..
>>> And I also realize that many good ideas comes from open source.
>>> 
>>> 
>>> To me, Swift 2.2 and also 3.0  is fine. 
>>> so, after that:
>>> you don’t have to change a thing.
>>> it works and has everything I need
>>> and is fast and stable. 
>>> stop removing things.
>>> thanks.
>> 
>> The crux of your argument seems to be: "Make it better, but don't change anything!"
>> 
>>> 
>>> 
>>> Kind Regards from beautiful Speyer.de <http://speyer.de/> in Germany
>>> 
>>> TedvG
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>_______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> 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/20160707/fbc50fe6/attachment.html>