4 ms·

Why rewrite code if it isn't broken?

by stesch 11y ago

vetinari 11y ago
Shows dedication to the platform. Currently, Swift is being hurt by incompatible changes between 1.x and 2.x. There are expected more incompatible changes between 2.x and 3.x. If Apple had significant investment in Swift apps, they would not be making breaking changes so lightly. Because they don't, breaking changes are expected and why should be you the one, who is constantly rewriting the app you have? TL;DR: it hurts the adoption of the language.
- akramhussein 11y ago
  I've been writing Swift since day 0 of its announcement - the migration issues aren't that big of a deal even for 10k lines of code, especially if you did it at each step. Sure it isn't fun, but everyone knew it was a early/beta language. After 3.x, their won't be huge breaking changes thankfully. Personally, only issue that bugged me was slower compilation time. About significant investment, this is just how Apple is. They don't stop the train for anyone, it's get on or off. Same goes for SDK you compile against, certain features you must bake in etc. Objective-C is 33 years old, I don't know for sure but I bet it wasn't that stable at the start!
- smackfu 11y ago
  Is it really mature enough that they shouldn't be making breaking changes?
  - mariusmg 11y ago
    No.
  - deleted 11y ago
    [deleted]
  - ucaetano 11y ago
    If it isn't, they shouldn't be advising people to build on it.
    - aljones 11y ago
      I'm not sure what exactly you mean. These breaking changes have not been surprises. They've clearly state their intention to evolve the language in public since it was first shown.
- cballard 11y ago
  Currently? Have people really not migrated to 2.0 yet? It wasn't that bad.
- coldtea 11y ago
  >Shows dedication to the platform. You generally want to show dedication to a platform with sane means. Not by writing multi-million line codebases, and creating new bugs, cut-down features and delays in the process (a la FCPX, which was in the same language as 7, but still a total rewrite). >If Apple had significant investment in Swift apps, they would not be making breaking changes so lightly. And the language wouldn't have fixed its early mistakes and matured. Which is what they did with 2.0 and plan to do with 3.0 -- at which point they promise stability. In general you want to stop making incompatible changes when you have finalized a good design and fixed all the major pain points from the early releases that the community brought forward.
kalleboo 11y ago
Dogfooding
- the_af 11y ago
  Wouldn't dogfooding mean writing new software using Swift, where appropriate, instead of re-writing existing software?
  - blktiger 11y ago
    I think true dogfooding would require a mix of both new applications as well as migrating older applications over.
oneJob 11y ago
Applications are rarely released in explicit versions (from the user side, publicity wise, sure there is a version number in the version control process, but what percentage of Gmail users do you think know what version they are using). If Apple has an application that is successful then they will continue to iterate that code base. If Apple truly is of the opinion that Swift is the language of the future, one would expect them to utilize it going forward. In order to utilize it going forward they'd need to rewrite some of the code base when they fix bugs and change functionality or aesthetics. The remaining code base can be left alone so long as they are confident they can get the resource to work with it if needed in the future. So really, what Apple is saying is, it's still easy enough to get someone to work on Objective-C should an issue arise. When that talent pool dwindles, at that point Apple will need to look at the cost/benefit of rewriting large code bases again. That is all assuming Apple has commited to moving to Swift and away from Objective-C, which I doubt is the state of affairs just yet.
deleted 11y ago
[deleted]

Why rewrite code if it isn't broken?

by stesch 11y ago

Why rewrite code if it isn't broken?

Shows dedication to the platform. Currently, Swift is being hurt by incompatible changes between 1.x and 2.x. There are expected more incompatible changes between 2.x and 3.x. If Apple had significant investment in Swift apps, they would not be making breaking changes so lightly. Because they don't, breaking changes are expected and why should be you the one, who is constantly rewriting the app you have? TL;DR: it hurts the adoption of the language.

akramhussein 11y ago
I've been writing Swift since day 0 of its announcement - the migration issues aren't that big of a deal even for 10k lines of code, especially if you did it at each step. Sure it isn't fun, but everyone knew it was a early/beta language. After 3.x, their won't be huge breaking changes thankfully. Personally, only issue that bugged me was slower compilation time. About significant investment, this is just how Apple is. They don't stop the train for anyone, it's get on or off. Same goes for SDK you compile against, certain features you must bake in etc. Objective-C is 33 years old, I don't know for sure but I bet it wasn't that stable at the start!
smackfu 11y ago
Is it really mature enough that they shouldn't be making breaking changes?
- mariusmg 11y ago
  No.
- deleted 11y ago
  [deleted]
- ucaetano 11y ago
  If it isn't, they shouldn't be advising people to build on it.
  - aljones 11y ago
    I'm not sure what exactly you mean. These breaking changes have not been surprises. They've clearly state their intention to evolve the language in public since it was first shown.
cballard 11y ago
Currently? Have people really not migrated to 2.0 yet? It wasn't that bad.
coldtea 11y ago
>Shows dedication to the platform. You generally want to show dedication to a platform with sane means. Not by writing multi-million line codebases, and creating new bugs, cut-down features and delays in the process (a la FCPX, which was in the same language as 7, but still a total rewrite). >If Apple had significant investment in Swift apps, they would not be making breaking changes so lightly. And the language wouldn't have fixed its early mistakes and matured. Which is what they did with 2.0 and plan to do with 3.0 -- at which point they promise stability. In general you want to stop making incompatible changes when you have finalized a good design and fixed all the major pain points from the early releases that the community brought forward.

kalleboo 11y ago

Dogfooding

the_af 11y ago
Wouldn't dogfooding mean writing new software using Swift, where appropriate, instead of re-writing existing software?
- blktiger 11y ago
  I think true dogfooding would require a mix of both new applications as well as migrating older applications over.

oneJob 11y ago

Applications are rarely released in explicit versions (from the user side, publicity wise, sure there is a version number in the version control process, but what percentage of Gmail users do you think know what version they are using). If Apple has an application that is successful then they will continue to iterate that code base. If Apple truly is of the opinion that Swift is the language of the future, one would expect them to utilize it going forward. In order to utilize it going forward they'd need to rewrite some of the code base when they fix bugs and change functionality or aesthetics. The remaining code base can be left alone so long as they are confident they can get the resource to work with it if needed in the future. So really, what Apple is saying is, it's still easy enough to get someone to work on Objective-C should an issue arise. When that talent pool dwindles, at that point Apple will need to look at the cost/benefit of rewriting large code bases again. That is all assuming Apple has commited to moving to Swift and away from Objective-C, which I doubt is the state of affairs just yet.

deleted 11y ago

[deleted]