Seriously! Freeze Swift For Two Years After Release 3.0!


(Ted van Gaalen) #1

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


(Saagar Jha) #2

Most source breaking changes will be made in Swift 3. From now on code
should be mostly backwards compatible.

···

On Wed, Jul 6, 2016 at 11:28 AM Ted F.A. van Gaalen via swift-evolution < swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha


(L Mihalkovic) #3

Regards
LM
(From mobile)

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.

The fact that some people jumped early on a not yet finished language should not constitute a jail for everyone else. Swift3 is starting to make a lot more sense, but it is still IMHO far from polished. We will live with 3, but if i knew this was the end of the road, i'd immediately push every large corp project i know to c#/xamarin, or even phonegap/typescript.

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!

I had an interesting conversation with the manager of the java group at apple 7 years ago who equated this behavior with being attributes of a 'failed technology' (then equally applied to java and cobol).

···

On Jul 6, 2016, at 8:28 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Karl) #4

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 :wink:

Karl

···

On 6 Jul 2016, at 20:28, Ted F.A. van Gaalen via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Rod Brown) #5

Comments inline (resent to swift evolution)

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!"

···

On 7 Jul. 2016, at 4:28 am, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

Kind Regards from beautiful Speyer.de <http://speyer.de/> in Germany

TedvG
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #6

I don't want to freeze Swift 3.0 either.

I'd much prefer to push out Swift 3.0 to grant it time to mature and perfect (and get those generics right, add some great features, etc) than to freeze Swift 3.0 under the currently announced timeline. Swift 2.2/2.3 is pretty great.

The obvious problem with doing this is that it encourages the development of a wider codebase that *will* break on the Swift 3 transition. On the other hand, Swift will have much better and more mature migration tools with additional time, not just a better language.

-- E

···

On Jul 7, 2016, at 8:46 AM, Karl via swift-evolution <swift-evolution@swift.org> wrote:
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).


(Charlie Monroe) #7

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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(Jean-Denis Muys) #8

Ted,

I basically disagree 100% with everything you wrote. I will not got into much details, but for me, technology that doesn’t evolve is dead technology.

Moreover, your main argument about large code bases, is not a good one: we now have migration tools that work quite well. They could be made even better, with some investment, that most (I think) would rather see invested in the leading edge.

Aversion to change is everywhere. It’s deeply engrained in us human beings. That’s why consultant make a living selling change management. I have seen people complain a lot about Apple releasing new versions of iOS for example. I have seen developers complain that Apple releases new versions of Xcode too frequently. I was even not too long ago in a position to do a web development job for a customer who wanted to support Internet Explorer 6. I have very little sympathy for such plights.

If you don’t want to maintain your Swift 2 code, don’t. But don’t prevent the rest of us from doing it, despite the efforts required.

I applaud the way the Swift team is handling those breaking changes, piling them up as early as possible, postponing additive changes to post 3.0. This is the way to minimise the efforts as much as possible. I hope that even then, source-breaking changes will continue to happen when they make sense. I am looking forward to a language that will get constantly better at enabling me to evolve my code in the most productive way. If my source code breaks, that is a very small price to pay.

Jean-Denis


(Haravikk) #9

I'm very much in the camp that doesn't mind breaking changes; of course we shouldn't be too cavalier about them either, but if a sound case can be made for why a breaking change is required, then we shouldn't be afraid to make the change either.

The biggest example that's impacted me in Swift 3, besides all the renaming, is probably the new Collection indexing scheme; while the previous system was functional enough in many cases, the new one is simply better, and takes a lot of burden away from the indices themselves to track minutia required for them to operate. It's been a bit of pain to transition some of my code, and I put a lot of time into working around the old system, but on the whole my code is now cleaner and more efficient.

So yeah, if the choice is between a language that is willing to make breaking changes that improve the language overall, compared to one that will remain stagnant and struggle to improve, then I'm willing to suffer some broken code that needs tweaking every time; we have developer previews and now support for multiple toolchains to make this much easier to work with and to preview potential breakages and fix them in advance.

Lastly, I'd say that even with version 3 fast approaching, Swift is still a very new language; some of its ideas were more successful than others, and some have been reevaluated in view of new features that overlap or replace them. I fully expect that in future there will be fewer breaking changes, but I think that trying to force that state too early is counterproductive, as it may restrict far more desirable improvements.

···

On 7 Jul 2016, at 14:16, Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

The designers of Swift have adopted a pragmatic approach to things: get a language that can be useful practically quickly, then improve it as things go. Its very Apple-like and I think it makes a lot of sense. We have a lot of useful changes in Swift 3.0, but the language is still far from complete. Recent discussions make it very obvious that some fundamental features are still in flux or are misunderstood (e.g the function argument label discussion), and the generics implementation has a lot of important stuff missing. Freezing Swift now would mean suspending it in a beta state.

So, no, a strong disagree with the premise of this thread from me.

Best,

Taras


(Taras Zakharko) #10

The designers of Swift have adopted a pragmatic approach to things: get a language that can be useful practically quickly, then improve it as things go. Its very Apple-like and I think it makes a lot of sense. We have a lot of useful changes in Swift 3.0, but the language is still far from complete. Recent discussions make it very obvious that some fundamental features are still in flux or are misunderstood (e.g the function argument label discussion), and the generics implementation has a lot of important stuff missing. Freezing Swift now would mean suspending it in a beta state.

So, no, a strong disagree with the premise of this thread from me.

Best,

Taras


(Chris Lattner) #11

Helpful hint for folks moving from Xcode 8.0 beta 1 to beta 2 (and beyond): when you open your project in a new beta, make sure to go to "Edit -> Convert -> To Modern Swift Syntax…”, which will help move you up by automatically applying the migration fixits that correspond to the changes in the new beta.

-Chris

···

On Jul 7, 2016, at 7:46 AM, Karl <razielim@gmail.com> wrote:

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.


(ChanMaxthon) #12

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@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@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 in Germany

TedvG
_______________________________________________
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


(Muse M) #13

I would disagree to freeze API for 2 years when a large parts of proposal
by brilliants programmers and scientists (that where performance is) have
yet to implement features in 3.1, 3.5 to 4.0​ would be ideally to move
fast, break fast before it reach mature stage.


(ChanMaxthon) #14

For JSONFusion this won't work at all, as the code base is largely Objective-C with lots of Swift-related annotations and depend on Objective-C and Swift ABI details to work. The main trick in JSONFusion is property introspection which don't play nice with Swift yet, and for JSFRemote the main trick is message forwarding interception.

···

Sent from my iPhone

On Jul 8, 2016, at 06:33, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 7, 2016, at 7:46 AM, Karl <razielim@gmail.com> wrote:
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.

Helpful hint for folks moving from Xcode 8.0 beta 1 to beta 2 (and beyond): when you open your project in a new beta, make sure to go to "Edit -> Convert -> To Modern Swift Syntax…”, which will help move you up by automatically applying the migration fixits that correspond to the changes in the new beta.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ted van Gaalen) #15

Hi Chris, sorry for the delayed response.

In many cases Swift converters/ migration tools are certainly helpful,
however they work mostly scanning on a statement-by-statement basis,
having "not enough AI” to grasp and process the context
e.g. for a cluster of source lines...

So, e.g. if one has programmed a function with its logic heavily based
on deprecating or removed Swift language elements, one still has to edit and
retest that code, which mostly consumes lots of time. Additionally,
in many cases - albeit somewhat reduced by good structured design -
these changes influences also other parts of the application.
(but we all know that of course)

imho and after releasing Swift 3.0:

···

On 08.07.2016, at 00:33, Chris Lattner <clattner@apple.com> wrote:

On Jul 7, 2016, at 7:46 AM, Karl <razielim@gmail.com> wrote:

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.

Helpful hint for folks moving from Xcode 8.0 beta 1 to beta 2 (and beyond): when you open your project in a new beta, make sure to go to "Edit -> Convert -> To Modern Swift Syntax…”, which will help move you up by automatically applying the migration fixits that correspond to the changes in the new beta.

-Chris

               ===================

Existing language elements should never be removed,
    (even if they are frowned upon, which occasionally is caused
     by aspects of subjective opinion, lack of experience and premature vague statistics, we’re human aren’t we?)
and even if much better newer solutions are available.

New language elements should be supplements, standing on their own,
with the purpose of extending Swift, not as changes of existing code,
thus leaving the older equivalents intact as not to break older source code.

         (it would then to be expected that,
          if better alternatives are made available
         these would of course be preferred,
         causing the older alternatives to be forgotten
         after some time. Like the classical for-loop for instance.
         but, they’re still there to stay compatible with older source code)

-Even renaming language elements makes revisiting
and editing often large amounts of source code necessary.

Yes, I know this can be quite a challenge, nevertheless
it is necessary, i think.

In a (often unforgiving and stressed) production-environment
we used to write code in a “fire and forget” modus,
that is once written and tested it should run forever!

There simply is no time for revisiting. For instance, if one
would have to re-edit an old source to make minor
changes, then it wouldn’t be enough to just correct
this perhaps minor error, as one would have to edit
many source lines because the compiler won’t accept
language elements used some time ago and
now rendered obsolete.

Unless you allow to compile conditionally for each and every version
of the language. But conditional compiling creates a
mess, and makes source code hard to maintain.

Changing language elements or, even worse, removing them
makes it a tedious and very costly necessity to revisit and
re-edit all previously written source code, not to mention
that after that, all application/libraries involved need to be
tested again!

If it is just a trivial application, then this still could be done
without too much effort, however, in more complex cases
this could result in a real nightmare, consuming lots of time and money.

If i am not mistaken, the word “deprecated” originated in the Java
world. There the questionable culture of rücksichtslos throwing
things away started, I guess. Trendy perhaps?
In this culture, tons of Java code needs to be revised,
tested and re-released almost yearly because of that.

I think we should not make the same mistake.

Changing things all the time would certainly diminish Swift’s
popularity by professional developers.

In all these years as a programmer my general experience is,
that improvements in programming languages are supplemental*
not changes or removal from existing language elements.

As perhaps misunderstood (from my previous writing) by some of us:
Of course I am not in favor of stopping development of Swift.
but imho as described above, changes should be supplemental
and not replacing existing language elements or removing them.

In this perspective “Freezing Swift” is meant here to keep all
new supplements in beta, yes, for a prolonged time, 2 years or so.
In that time Swift will have many more users, that no doubt, will
come with valuable feedback allowing to
improve the language even better.

Please note that all the writing and considerations above concerns the
time AFTER the release of Swift 3.0.

I see a lot of good ideas and enthusiasm here, but
i might perhaps assume that many here didn’t work in a tight an
tense production environment?

At least please try to imagine what it would be
if you would have to maintain source code that:
  -was written a few (ten?) years ago
  -cryptic sources worked on through by many people, of talented and often rookies,
    hired and fired and hired again.
  -a lot of times you wouldn’t have time to solve problems decently, or
   rewrite it, it just has to be patchwork.

I had to work many years like that and some projects almost drove crazy.
burn outs and so.
could tell you things that make you cry.. (but hey also positive things too)

I’d say one should pay more attention to these aspects.

Also, Swift has the very powerful feature to write one’s own
extensions, protocols and forms of inheritance.
This imho reduces the need to chance the language.

Thanks for reading.
Kind Regards
Ted

@ Karl :

Yes, it was blown a bit out of proportion, I hope the
above has nuanced it a bit.

@Charlie Monroe:

Your assumption:

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.

Forget it :o)
On the contrary, both languages PL/1 and Cobol are much more complex than Swift.
Take a look at the programming manuals, language specs.

Kind Regards
Ted


(Ted van Gaalen) #16

Hi Jean-Denis

please look at my response in-line further down.

I am also writing this text because I think
that the implications of back breaking chances
are severely underestimated.

Again, the scope of my writing concerns the situation after Swift 3.0

Veuillez recevoir, Monsieur, nos salutations distinguées.

Ted

Ted,

I basically disagree 100% with everything you wrote.

Ok, it was a bit supercharged as in effect, I meant
only source breaking changes.

However also my recommendation to move a bit slower
for a year or two so that people (not only the Swift-evolution participants)
really have started using Swift is a consideration… to get
more matured feedback, which then can play an important
role in improving Swift further.

I will not got into much details, but for me, technology that doesn’t evolve is dead technology.

I agree with this of course!

The subject title I gave this thread:

"Seriously! Freeze Swift For Two Years After Release 3.0 !”

and also what I wrote was a bit over-dramatic. That is a bit my nature…:o) sorry.
Now it has a more appropriate subject title as you can see above.

What I (but who am I?) would prefer is:

All improvements and changes should be supplemental only.
thus leaving what is already there intact.

···

On 07.07.2016, at 14:12, Jean-Denis Muys <jdmuys@gmail.com> wrote:
      
===================================================================
This Would 100% Guarantee That Everything Ever Built, Never Needs To Be Changed.
===================================================================

(that is, within the scope and context of the programming language itself, of course)

This is certainly feasible and proven: there are a number of programming languages that
adhere to this basic rule. This is e.g. the case with the classical languages Cobol and PL/1 for
C, C++ for example.

Moreover, your main argument about large code bases, is not a good one: we now have migration tools that work quite well. They could be made even better, with some investment, that most (I think) would rather see invested in the leading edge.

As I wrote before, I think that in many cases converters/ migration tools
are certainly helpful,however they work mostly scanning on a
statement-by-statement basis,
having "not enough AI” to grasp and process the context
e.g. for a cluster of source lines…

Imho, it is nearly impossible to write a migration tool that catches everything
and automatically converts flawlessly.
Making such a migrator would probably use as much or even more effort
as making the Swift compiler itself.

I have worked for many years in IT-environments with extremely large
and often ancient code bases (Mainframe, banks insurance companies etc.)

In these environments,- even without source migration -
it is extremely difficult to apply changes to existing software, thousands of
sources scattered al over the place: a myriad of chaotic intertwined sub systems,
often badly connected via middle ware, chaotic file systems etc. Yes, from time to time
change managers/firms are hired, however, in many cases this makes it even worse.
Note that this is not a worst case scenario but the average large systems scenario.

Aversion to change is everywhere. It’s deeply engrained in us human beings.

Yes, very true, albeit that it is a very understandable feature of human intuition
as changes are risky in many cases. This does not imply that change
should be avoided at all times of course! Apparently I gave this impression
unintentionally in my previous writing.

Especially in IT , the reluctancy to change is very plausible if changes bring
severe risk of malfunctioning systems. For example changes to large bank’s
accounting systems literally consisting of thousands of programs, modules
and files and a few different databases simultaneously.. These systems are
extremely fragile.

When changes applied go wrong, it cause severe financial damage.
It happens many times as it is very hard to foresee the impact
and side-efects these changes might have in
large (and mostly hybrid) systems.

So imagine something so trivial as changing the Cobol assignment statement
"MOVE A TO B.” to "COPY A INTO B."
(which btw would have been more correct, because basically that is what it does)

Even such a small change can have an enormous impact. On top of that,
as changes to sources also need a conversion cycle when there is backwards
breaking the situation will be extremely difficult.
The example here is just a trivial case.

A hypothetic but realistic example:

Swift is intended as a general purpose language, so, what prevents
us from writing a complete accounting system with Swift?

Let’s assume a company decides to (re)built its complete company-wide
accounting system using Swift as its main programming language.
About 40 Swift programmers are hired, they manage
to built this accounting system in even less that a year.
(which might be feasible because Swift is flexible and powerful)

The codebase for this hypothetic accounting system
(compared with codebases in say Java and/or Cobol)
could contain (among other software, database etc.)
more than thousand Swift source files.
This is a realistic estimation.

If, say, a year after completing this accounting system source compatibility
breaks, they are in real trouble. (as with Java sometimes)
No, there is no time and budget to rewrite and test! say, about 700 source files.
This is not an exaggeration.

Ergo:
If it can, the project management will only accept Swift
(or for that matter any other language/system )
if and only if
there is an 100% guarantee that future changes
of the programming language
will not break existing code.

Chris has emphasized to me the following Swift goal / intention:

"The primary goal of this release is to solidify and mature the Swift language and development experience.
While source breaking changes to the language have been the norm for Swift 1 through 3,
we would like the Swift 3.x (and Swift 4+) languages to be as
source compatible with Swift 3.0 as reasonably possible.”

Well, that is positive, but imho not good enough.
There should be no source breaking changes at all.

That’s why consultant make a living selling change management.

Definitely not a job for me… :o)

I have seen people complain a lot about Apple releasing new versions of iOS for example. I have seen developers complain that Apple releases new versions of Xcode too frequently.

Yes, people often complain and it is true imho that releases come a bit to often these days.
Oh the other hand, there are many large iOS apps out there.

I was even not too long ago in a position to do a web development job for a customer who wanted to support Internet Explorer 6. I have very little sympathy for such plights.

It really depends on the situation:
I know of the case of of a large German company where
there was a very large system (and probably still is) based on IE 6,
but sometimes there is no money and/or time to upgrade it.
Have you read about air traffic systems?
There is a lot of “old” software, mature and stable,
in many businesses, functioning very well and if it were
not from pressure from “outside” and evaporating OS s
they would still be quite happy.
Yes, missing out on progress of course,
but in some businesses this is irrelevant.

If you don’t want to maintain your Swift 2 code, don’t. But don’t prevent the rest of us from doing it, despite the efforts required.

No, I don’t want to remain with older Swift versions, but move on with newest versions.
These however, should flawlessly compile everything written in older versions.

I applaud the way the Swift team is handling those breaking changes, piling them up as early as possible, postponing additive changes to post 3.0.
This is the way to minimise the efforts as much as possible.

I subscribe to that.

I hope that even then, source-breaking changes will continue to happen when they make sense.

I certainly hope not.

I am looking forward to a language that will get constantly better at enabling me to evolve my code in the most productive way.

Yes, me too!

If my source code breaks, that is a very small price to pay.

Would you still have this opinion if you (or your team)
after two years or so would have to edit hundreds of source files manually?
(because the source breaking change cannot be automatically converted?)

For example, after the removal of the classical for-loop with floats like this one:

        for var x:Float = -60; x < 60; x += w * 1.2
        {
            for var y:Float = -30; y < 60; y += h * 1.2
            {
               let pos = SCNVector3(x: x, y: y, z: z)
                
                let tile = TGStaticTile(pos: pos,
                                w: CGFloat(w), h: CGFloat(h), l: CGFloat(l),
                                color: UIColor.randomColor(), naam: "Tile\(tiles.count + 1)")

                tiles.append(tile)
           }
  }

I have more that a few of these in my AppleTV app under construction
which I all have to rewire manually when Swift 3.0 arrives,
because the migrator can not do it.

AFAIK, there is no automatic source conversion possible
in the above example.
(Also, there is no alternative in Swift yet for classical for-loops.
(I brought this forward extensively a few months ago,
but no one seems to care. I still can write a proposal
to reinstate the classical for-loop, but I guess it would be rejected))

N.B. an example: Some time ago, I was in favor to remove
variadic parameters from functions. This contradicts
the way I think now about removing language elements
I now think it should not be removed:
it is still there then, but one doesn’t need to use it.

met vriendelijke groeten
Ted
https://www.tedvg.com
https://www.ravelnotes.com
https://soundcloud.com/ted-van-gaalen
https://tedvg.deviantart.com

Jean-Denis


(Chris Lattner) #17

Ted,

I recommend that you familiarize yourself with the goals for Swift 3, which are described here:

An excerpt:

"The primary goal of this release is to solidify and mature the Swift language and development experience. While source breaking changes to the language have been the norm for Swift 1 through 3, we would like the Swift 3.x (and Swift 4+) languages to be as source compatible with Swift 3.0 as reasonably possible.”

-Chris

···

On Jul 9, 2016, at 12:41 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

imho and after releasing Swift 3.0:
              ===================

Existing language elements should never be removed,
   (even if they are frowned upon, which occasionally is caused
    by aspects of subjective opinion, lack of experience and premature vague statistics, we’re human aren’t we?)
and even if much better newer solutions are available.

New language elements should be supplements, standing on their own,
with the purpose of extending Swift, not as changes of existing code,
thus leaving the older equivalents intact as not to break older source code.


(Ted van Gaalen) #18

Hi Chris,

Yes, I did read it again, subscribe to that strategy.

I’ve perhaps over-emphasized the importance of the impact back-breaking changes
.. Still..

The subject title was a bit overloaded too.

I guess it’s between two extremes: that is, between (1) really freezing it and
(2) using Swift as a continuous "software laboratory” :o)
neither would be OK, (as with all extremities)...

thanks
Ted

···

On 10.07.2016, at 00:20, Chris Lattner <clattner@apple.com> wrote:

On Jul 9, 2016, at 12:41 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

imho and after releasing Swift 3.0:
             ===================

Existing language elements should never be removed,
  (even if they are frowned upon, which occasionally is caused
   by aspects of subjective opinion, lack of experience and premature vague statistics, we’re human aren’t we?)
and even if much better newer solutions are available.

New language elements should be supplements, standing on their own,
with the purpose of extending Swift, not as changes of existing code,
thus leaving the older equivalents intact as not to break older source code.

Ted,

I recommend that you familiarize yourself with the goals for Swift 3, which are described here:
https://github.com/apple/swift-evolution

An excerpt:

"The primary goal of this release is to solidify and mature the Swift language and development experience. While source breaking changes to the language have been the norm for Swift 1 through 3, we would like the Swift 3.x (and Swift 4+) languages to be as source compatible with Swift 3.0 as reasonably possible.”

-Chris