7 ms·

This is already being done. Swift 4 (unreleased) has source compatibility with Swift 3 [0], so all Swift code working today should work in the next version, no

This is already being done. Swift 4 (unreleased) has source compatibility with Swift 3 [0], so all Swift code working today should work in the next version, no migrator necessary. Additionally, the goal of Swift 4 is to finalize the ABI. Once that is done, you can mix and match different Swift versions in the same project. The real "problem" here is that Swift wants to be a "big" language, in the vein of C++ or Rust, as opposed to a "small" language like C or JS where you can read one book. (Swift does have a book, it's 1200 pages.) There's a lot of "stuff": a complex typesystem, many basetypes, generics, extensions, both static and dynamic dispatch, programmer-assisted memory management, closures, visibility, ephemerals, optionals, a mutability-based memory model, etc. etc. Inevitably some of that stuff won't be quite right and so you have churn. But ideally you only need 10% of those (it's just that everybody needs a different 10%) and so the amount of churn you personally have to deal with should be low, and can be lower with the appropriate tooling. [0] https://swift.org/blog/swift-4-0-release-process/ https://swift.org/blog/swift-4-0-release-process/ [1] https://github.com/apple/swift-evolution https://github.com/apple/swift-evolution

Someone 10y ago
"Swift does have a book, it's 1200 pages." It is an ePub, so your mileage may vary. On my iPad, it is 1077 in landscape, 892 in portrait (edit: playing with the font size in iBooks, I got it down to 484 pages while still being eminently readable for my myopic eyes) More importantly, that ePub on my iPad shows only 16-ish on a page in landscape mode, 22-ish on portrait. A printed book probably would be around 300-400 pages. In comparison, the PDF I have for "small" language ISO C 2011 has 701 pages, a draft of ECMA-262 for JavaScript 252.
0x0 10y ago
I thought they announced swift 4 would not finalize the ABI after all? http://mjtsai.com/blog/2017/02/16/deferring-abi-stability-from-swift-4/ http://mjtsai.com/blog/2017/02/16/deferring-abi-stability-fr...
edblarney 10y ago
"Swift wants to be a "big" language" My guess is that it is not ideological. Swift feels like it wants to be 'everything'. Because of this, it's almost too much. I want to like Swift, but I run into a lot of trouble with it. The decision to be compatible with ObjC was one of the big issues: obviously, pragmatically, they felt that they just had to do it. In hindsight, I wonder if it would have been better to just have a clean break.
- fiedzia 10y ago
  > In hindsight, I wonder if it would have been better to just have a clean break. Language-wise - sure, it adds a lot of complexity. Platform-wise, they would risk people staying on what they had and ignoring Swift entirely, and that would mean Apple would need to support objective-c a lot longer than they want to.
  - edblarney 10y ago
    Yes, that is the rationale. But I wonder. They are a $700B company. What if they just 'did it right' - i.e. made sure all of the APIs and documentation were available in 'new Swift' which had no relation to ObjC. Because the 'fallback on ObjC' has more problems than integration. A lot of people want to make apps for iPhone and ObjC is not in their vocab. Me, for example. Swift could have been an easy-to-approach language. But because of 1) lack of docs and 2) dependency on a lot of ObjC residue ... guess what? To make app in 'Swift' - you still had better know a lot of ObjC! So - to really make use of 'the new' - you still have to know 'the old' - which totally defeats the purpose! I wish they had made a clean break - great docs, examples that are clear and well marked in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes. And left a few things out.
    - fiedzia 10y ago
      > They are a $700B company. But many of their customers aren't. Lot of them have no budget (or will) for complete rewrite. And if you force them (or just make them believe you may do it) they will complain and it means bad press, in a very competitive market. It may not be something Apple can afford. > What if they just 'did it right' You can't "did it right" without support of large amount of users, regardless of the money. The definition of "right" in programming languages is "works for users". And to get users onboard, you have make sacrifices. > A lot of people want to make apps for iPhone and ObjC is not in their vocab. And even more has existing apps to maintain. Tradeoffs have to be made. > great docs, examples that are clear and well marked in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes All those things will come. If you want them, wait for them. Being early adopter has its cons.
hboon 10y ago
As noted in the first link above, source compatibility isn't kept with Swift 3->4 anymore. There are changes to the String APIs.
mahyarm 10y ago
If your an objective-c programmer, a lot of swift concepts are very close to each other. Most of the time you just pick it up as you go along. In many ways it's a cleaned up objective-c.

Someone 10y ago

"Swift does have a book, it's 1200 pages." It is an ePub, so your mileage may vary. On my iPad, it is 1077 in landscape, 892 in portrait (edit: playing with the font size in iBooks, I got it down to 484 pages while still being eminently readable for my myopic eyes) More importantly, that ePub on my iPad shows only 16-ish on a page in landscape mode, 22-ish on portrait. A printed book probably would be around 300-400 pages. In comparison, the PDF I have for "small" language ISO C 2011 has 701 pages, a draft of ECMA-262 for JavaScript 252.

0x0 10y ago

I thought they announced swift 4 would not finalize the ABI after all? http://mjtsai.com/blog/2017/02/16/deferring-abi-stability-from-swift-4/ http://mjtsai.com/blog/2017/02/16/deferring-abi-stability-fr...

edblarney 10y ago

"Swift wants to be a "big" language" My guess is that it is not ideological. Swift feels like it wants to be 'everything'. Because of this, it's almost too much. I want to like Swift, but I run into a lot of trouble with it. The decision to be compatible with ObjC was one of the big issues: obviously, pragmatically, they felt that they just had to do it. In hindsight, I wonder if it would have been better to just have a clean break.

fiedzia 10y ago
> In hindsight, I wonder if it would have been better to just have a clean break. Language-wise - sure, it adds a lot of complexity. Platform-wise, they would risk people staying on what they had and ignoring Swift entirely, and that would mean Apple would need to support objective-c a lot longer than they want to.
- edblarney 10y ago
  Yes, that is the rationale. But I wonder. They are a $700B company. What if they just 'did it right' - i.e. made sure all of the APIs and documentation were available in 'new Swift' which had no relation to ObjC. Because the 'fallback on ObjC' has more problems than integration. A lot of people want to make apps for iPhone and ObjC is not in their vocab. Me, for example. Swift could have been an easy-to-approach language. But because of 1) lack of docs and 2) dependency on a lot of ObjC residue ... guess what? To make app in 'Swift' - you still had better know a lot of ObjC! So - to really make use of 'the new' - you still have to know 'the old' - which totally defeats the purpose! I wish they had made a clean break - great docs, examples that are clear and well marked in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes. And left a few things out.
  - fiedzia 10y ago
    > They are a $700B company. But many of their customers aren't. Lot of them have no budget (or will) for complete rewrite. And if you force them (or just make them believe you may do it) they will complain and it means bad press, in a very competitive market. It may not be something Apple can afford. > What if they just 'did it right' You can't "did it right" without support of large amount of users, regardless of the money. The definition of "right" in programming languages is "works for users". And to get users onboard, you have make sacrifices. > A lot of people want to make apps for iPhone and ObjC is not in their vocab. And even more has existing apps to maintain. Tradeoffs have to be made. > great docs, examples that are clear and well marked in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes All those things will come. If you want them, wait for them. Being early adopter has its cons.

hboon 10y ago

As noted in the first link above, source compatibility isn't kept with Swift 3->4 anymore. There are changes to the String APIs.

mahyarm 10y ago

If your an objective-c programmer, a lot of swift concepts are very close to each other. Most of the time you just pick it up as you go along. In many ways it's a cleaned up objective-c.