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

[Karl]

> On 6 Jul 2016, at 20:28, Ted F.A. van Gaalen via swift-evolution <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.)
> 
> 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!
> 
> 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! 
> 
> After such time, and much more intensive and practical usage, 
> it becomes clear, what is good in Swift and what is not.  
> 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
> 
> 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.
> 
> 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..
> 
> 
> 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) 
> 
> 
> 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.
> 
> 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.
> 
> 
> Kind Regards from beautiful Speyer.de in Germany
> 
> TedvG
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


It’s nice that you like Swift 3.0 so much, but it still has holes - there are plans in the generics manifesto for instance which are basically just limited by implementation. We don’t have a stable ABI. Reflection is still fairly rudimentary.

I don’t think the changes from Swift 2.2 -> Swift 3.0 are that dramatic, but overall I feel they have made the language much better. The new indexing model, for instance, is a significant improvement; it’s now much easier to write custom collections. I was initially opposed to moving the “where” clause for generics outside of the angle brackets, but I’ve come around and I’m really looking forward to it, now. I’m even glad we got rid of C-style ‘for’ loops - it has helped me write safer, more readable code. There have been some really great performance improvements and I’m seeing more and more really big ones in the Github PR list every day (it’s really fascinating, I do love seeing how the language is getting improved piece-by-piece, in parallel, by so many people - I like to just flick through it sometimes and click on every title I don’t understand, sometimes you discover really cool things).

Not only that, but we have compiler fix-its. When there are renaming changes or argument-label changes, I just filter down my Xcode error list, click each one, give it a quick eyeball and hit “enter”. I don’t know of other languages that have had such good migration infrastructure for existing code. I don’t know how Linux users get the benefit of these fixits, though. Maybe a command-line interface for applying those fixits would be a neat idea, if they don’t have something else already. On Apple's platforms, they’ve got Swift 2.3 to help ease the migration pain (which is something I wish they’d done for Swift 2.0, but at least it’s nice to see they listened to the feedback).

Not only that, but you need to appreciate that comparing Swift, a language which has only been public for a couple of years, to a C language specification that has gone through ISO-certification process, is not really fair. Even then, C has had to evolve and so there are many newer specifications. I would guess the Swift core team won’t want to follow that approach - they’ve said a few times that they don’t want there to be multiple ‘flavours’ or ‘dialects’ of Swift.

So long as Swift keeps moving in the right direction, I’m happy for it to keep going at this pace. What I’ve seen of the project so far indicates that it’s run pretty well, and that the core team are very fair when it comes to source-breaking changes. For instance, I didn’t expect SE-0108 to get rejected recently, but the core team took the side of language users over compiler developers (i.e. Themselves) and are willing to go back to the drawing board because they considered it an unacceptable user regression. I thought that was pretty cool.

Basically, I think it’s blown out of proportion a bit. All languages must evolve, and the Swift team provide lots of supporting infrastructure to help users through those transitions. 

"Weiter so!”, as we say in Germany ;)

Karl