Swift Changes Considered Harmful(furbo.org)
furbo.org
Swift Changes Considered Harmful
http://furbo.org/2017/02/17/swift-changes-considered-harmful/
48 comments
> Take a look at the Stack Overflow page again. There’s some good information there, but it’s completely hidden by Swift code that’s no longer relevant.
I recently experienced this first-hand with Python, chasing an issue with SSL certificates - my problem (SSL doesn't work on Python 3.6 on OSX unless you follow a post-install step to install certificates) was completely masked by problems some people experienced in a recent previous version of Python, where they had switched on certificate validation by default [0]. There were a number of similar-but-different SO questions, that all linked to each other. I wasted hours before I discovered that none of the results on Google for my exception were relevant.
It's hard with SO sometimes - information ends up being stale, and the accepted answer might no longer be the best. Sometimes you find a helpful comment or a new answer that has the right info, but other times it's just out of date or completely irrelevant. Worst, it leads you to mis-diagnose the problem, which is especially easy when it's something you're not familiar with: I know very little about SSL, I just want my API requests to work.
[0] Yes, I was astonished to discover that all this time certificates weren't being checked
I recently experienced this first-hand with Python, chasing an issue with SSL certificates - my problem (SSL doesn't work on Python 3.6 on OSX unless you follow a post-install step to install certificates) was completely masked by problems some people experienced in a recent previous version of Python, where they had switched on certificate validation by default [0]. There were a number of similar-but-different SO questions, that all linked to each other. I wasted hours before I discovered that none of the results on Google for my exception were relevant.
It's hard with SO sometimes - information ends up being stale, and the accepted answer might no longer be the best. Sometimes you find a helpful comment or a new answer that has the right info, but other times it's just out of date or completely irrelevant. Worst, it leads you to mis-diagnose the problem, which is especially easy when it's something you're not familiar with: I know very little about SSL, I just want my API requests to work.
[0] Yes, I was astonished to discover that all this time certificates weren't being checked
I had a bad time going from 2 to 3. The renamification was pretty smooth but took a few hours of work for a big project. However there were more subtle differences.
Example code:
I would still happily start a project in Objective-C(++) if I would need to integrate a lot of libraries that rely on O-C, C or C++. But Swift is the default for me.
Example code:
var rowID: Int! // Set elsewhere, keeping it short. Also would never declare anything in this way but legacy
func someFunc() {
let updateUrl = "things/\(rowID).json"
print("updateUrl")
}
things/123.json
things/Optional(123).json
I would still happily start a project in Objective-C(++) if I would need to integrate a lot of libraries that rely on O-C, C or C++. But Swift is the default for me.
Are we at a point yet where people have realized that mutability is basically an optimization fraught with danger, and that immutability and functional data structures (coupled with some decent GC scheme) are the way to go for the most secure, bug-free code out of the gate?
Wake me up when we are, because "UnsafeMutableRawPointer" in sample code makes me nauseous. Meantime, I'm gonna hang out here over in Elixir-land.
Wake me up when we are, because "UnsafeMutableRawPointer" in sample code makes me nauseous. Meantime, I'm gonna hang out here over in Elixir-land.
This seems like an issue with out of date examples.
This same criticism could be leveled against any language that evolves and invalidates past syntax.
PHP7 invalidates tons of old examples on the web. Does that mean those changes were bad or harmful? No. Just because we happen to be at a transition window with Swift such that recent examples are now invalid doesn't change that.
This same criticism could be leveled against any language that evolves and invalidates past syntax.
PHP7 invalidates tons of old examples on the web. Does that mean those changes were bad or harmful? No. Just because we happen to be at a transition window with Swift such that recent examples are now invalid doesn't change that.
I love Swift and I don't care if they break it everyday. I'll patch everything that needs to be patched while having fun building apps for all devices in the world, desktop, mobile, server, watch, tv, IoT, embedded, etc. Naysayers will naysay, just stay away and let us code.
Swift is a beautiful language and it gets better by the day.
Swift is a beautiful language and it gets better by the day.
It's always a tradeoff. The io.js mess showed what happens when you try to be too stable.
[deleted]
"Considered Harmful" Essays Considered Harmful: http://meyerweb.com/eric/comment/chech.html
Every time I see a "considered harmful" title, I groan and think of this. It's a meme at this point, and really detracts from the value of the article for me.
Is There An Alternative to “Considered Harmful” Essays?
Absolutely. The most basic alternative is not to write them at all, but to instead engage in reasoned debate without resorting to dogmatic assertions or distractive tactics (e.g., ad hominem attacks and straw man arguments). In those cases where some sort of document is needed outside of the debate, there are a number of superior alternatives.
* A description of the strong and weak aspects of one’s own point of view; we might call it a “benefits and weaknesses of” essay. This is a positive contribution to the debate, and allows the debating parties to take the best parts of each view and more readily find a compromise solution. Knowing both the benefits and weaknesses of all views makes it easier to cover the weaknesses in one view with the strengths in another.
* A description of the strong and weak aspects of another point of view; we might call it a “perceived benefits and weaknesses of” essay. This allows the author to evaluate what he believes to be good and bad about another point of view. Authors must be careful to avoid slanting the piece too far toward the weaknesses, lest they end up writing a “considered harmful” essay by another name.
* An essay that compares different viewpoints in the same piece; in other words, a “compare and contrast” essay. These essays attempt to objectively evaluate multiple views and point out how they are both alike and dissimilar, thus highlighting both common ground and areas that need work. The benefits of such essays are fairly self-evident.
Absolutely. The most basic alternative is not to write them at all, but to instead engage in reasoned debate without resorting to dogmatic assertions or distractive tactics (e.g., ad hominem attacks and straw man arguments). In those cases where some sort of document is needed outside of the debate, there are a number of superior alternatives.
* A description of the strong and weak aspects of one’s own point of view; we might call it a “benefits and weaknesses of” essay. This is a positive contribution to the debate, and allows the debating parties to take the best parts of each view and more readily find a compromise solution. Knowing both the benefits and weaknesses of all views makes it easier to cover the weaknesses in one view with the strengths in another.
* A description of the strong and weak aspects of another point of view; we might call it a “perceived benefits and weaknesses of” essay. This allows the author to evaluate what he believes to be good and bad about another point of view. Authors must be careful to avoid slanting the piece too far toward the weaknesses, lest they end up writing a “considered harmful” essay by another name.
* An essay that compares different viewpoints in the same piece; in other words, a “compare and contrast” essay. These essays attempt to objectively evaluate multiple views and point out how they are both alike and dissimilar, thus highlighting both common ground and areas that need work. The benefits of such essays are fairly self-evident.
The purpose of the "Considered Harmful" headline was, and always has been, to draw attention. And it's frequently been successful, both in the original attempt and here as well.
My grief with this sort of "considered harmful" essay or blog post is that it is being applied to such concrete subjects as Swift code migration, not the almost philosophical objects as the original GOTO. "Considered harmful" essays should be timeless to do service to the concept.
I don't agree with this. Presumably this is going to be a long lived language. They should fix the problems as early as possible so that generations of developers don't have to keep reliving the same pain.
As painful as it is in the short run, I am inclined to agree with this.
A story I heard once that I love to retell is that after Stu Feldman wrote the first version of 'make' for Unix, he realized that the syntax was borderline unusable, but he didn't want to fix it because he already had 10 users.
I've also heard that Chris Lattner didn't want to release Swift when he did, but was pressured by Apple into doing so. There's no question in retrospect that it wasn't ready, and I think it's entirely fair to beat up on Apple for pushing it out too soon. Nonetheless, since it is out, I think they should do their best to get it right.
A story I heard once that I love to retell is that after Stu Feldman wrote the first version of 'make' for Unix, he realized that the syntax was borderline unusable, but he didn't want to fix it because he already had 10 users.
I've also heard that Chris Lattner didn't want to release Swift when he did, but was pressured by Apple into doing so. There's no question in retrospect that it wasn't ready, and I think it's entirely fair to beat up on Apple for pushing it out too soon. Nonetheless, since it is out, I think they should do their best to get it right.
Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history.
-- Stu Feldman in The Art of Unix Programming
-- Stu Feldman in The Art of Unix Programming
Disclaimer: I'm purposefully stretching to come to this conclusion, think of it as me transcribing an idle thought
I think people are taking out their frustration with C++ on Swift by saying it's fine to churn the language so we don't end up with a mess like C++ because they just despise the way the past of C++ has marred the present by existing, no matter how hard the language is trying to be in the present.
They feel Swift should move fast and break things so that we don't have to live with the mistakes of the past like C++ does.
The problem is even if we think what Swift is doing is perfect and let it solidify, odds are in the future we'll still come to despise it, and the parts we despise will eventually be old and well used enough they can't reasonably be changed by breaking stuff, and then it will be time for a new language to repeat the cycle.
(Replace C++ with Java or some other older language as preferred)
I think people are taking out their frustration with C++ on Swift by saying it's fine to churn the language so we don't end up with a mess like C++ because they just despise the way the past of C++ has marred the present by existing, no matter how hard the language is trying to be in the present.
They feel Swift should move fast and break things so that we don't have to live with the mistakes of the past like C++ does.
The problem is even if we think what Swift is doing is perfect and let it solidify, odds are in the future we'll still come to despise it, and the parts we despise will eventually be old and well used enough they can't reasonably be changed by breaking stuff, and then it will be time for a new language to repeat the cycle.
(Replace C++ with Java or some other older language as preferred)
I think his main complaint is that Apple should stop publishing sample code (which they update sporadically at best) in Swift when the language is changing so much. At WWDC this year I believe virtually all code shown on screen was Swift, but ObjC would have been fine for almost everything.
More broadly, I think Apple should have marketed Swift as "beta" until at least v3, to really make clear (especially to managers) what it means to have a language with constant source-breaking changes.
More broadly, I think Apple should have marketed Swift as "beta" until at least v3, to really make clear (especially to managers) what it means to have a language with constant source-breaking changes.
" should stop publishing sample code (which they update sporadically at best)"
Ah? No. 'Sample code' is essential, often more valuable than the docs.
They are a $700 Billion dollar company.
You know what they can afford to do?
Have more sample code, better documentation - and update all of the goddam samples, moreover, to make it clear in each sample, which version applies.
Ah? No. 'Sample code' is essential, often more valuable than the docs.
They are a $700 Billion dollar company.
You know what they can afford to do?
Have more sample code, better documentation - and update all of the goddam samples, moreover, to make it clear in each sample, which version applies.
You cut the quote off too early, I think they should have sample code in ObjC rather than Swift
Objective C is going to "die" fast. It's basically an Apple only language, and the community is quickly moving to Swift.
If you don't know either language, simply compare the code. Objective C is a much noisier language.
https://h4labs.wordpress.com/2016/02/09/should-i-use-objecti...
Apple doesn't dwell on the past. Most of their examples are in Swift for a reason.
If you don't know either language, simply compare the code. Objective C is a much noisier language.
https://h4labs.wordpress.com/2016/02/09/should-i-use-objecti...
Apple doesn't dwell on the past. Most of their examples are in Swift for a reason.
I think that's completely reasonable and maybe the article would have been better with the much more sensible complaint that an official Apple code sample last updated at the end of October last year doesn't work in un-obvious ways today. That's just sloppy and frustrating and shouldn't happen - at a minimum it should be marked (temporarily) obsolete.
Hey, it's "continuous integration". It's moving fast and breaking things. Keep up or be roadkill.
After 3 years in Swift, the only clear drawback outside compile times, is exactly this.
It's a real shock coming from Objective-C. Ad hoc name-spacing by prefixing classes, and a language/core framework that's been stable for 30 years, made it extremely easy to Google and get an accurate answer immediately.
Moving to a language that adds major features twice a year, and invalidated large swaths of code by mass-renaming Cocoa in Swift 3, has made it much harder to find correct material
It's a real shock coming from Objective-C. Ad hoc name-spacing by prefixing classes, and a language/core framework that's been stable for 30 years, made it extremely easy to Google and get an accurate answer immediately.
Moving to a language that adds major features twice a year, and invalidated large swaths of code by mass-renaming Cocoa in Swift 3, has made it much harder to find correct material
core framework that's been stable for 30 years
That's perhaps a little overstated.
That's perhaps a little overstated.
Its always a tough decision, either you make no changes but then have to live with a less than ideal situation, or make changes but forces everyone to update their code.
Personally I think its ok to make incompatible changes once and then, as long as its not too many changes in one go (like python3), its preferable than later on ending up with inconsistent or overly complex languages.
Personally I think its ok to make incompatible changes once and then, as long as its not too many changes in one go (like python3), its preferable than later on ending up with inconsistent or overly complex languages.
I work in Swift 7 days a week (sadly 7) but I am quite happy despite the changes, it's an open source language built entirely in the open by contributions from people who care. What the hell is there to complain about, would you rather work in 50+ year old cobol? I've used ObjC since the NeXT days and despite much of our codebase (not our part) is still in that language I am always glad to be working on our part in a nice modern language. It's only 3 years old. Go is almost 5 (announced like 8 years ago and started 10), Ruby and Java are antiques in comparison at 20+, ObjC itself is 30 years old, C is 40, C++ is around 25. Rust is about the only comparable aged language, and it isn't used in any single environment as large as iOS and OSX. Swift is 3. Yet it's fun and productive to work in (other than compile times which suck, and debugging which is painful sometimes, and Xcode is ugh). Sure often I have to look up what the current syntax is, but it's still lightyears easier than remembering C++ details (another language I spent a fair amount of time in in the past) which also change from year to year. Debugging STL still gives me nightmares.
Cyanide is considered harmful. Opinions are just opinions, but calling something harmful when you just don't like it should be considered silly.
Cyanide is considered harmful. Opinions are just opinions, but calling something harmful when you just don't like it should be considered silly.
> What the hell is there to complain about, would you rather work in 50+ year old cobol?
I'd rather work on modern AND stable language (I actually do, its not Swift, buy that's not my point). Broken code samples is a good reason to complain. Swift is a moving target, it will be for a while, and this is real pain... but its not a secret. If it bothers someone, why would they choose to use it?
I'd rather work on modern AND stable language (I actually do, its not Swift, buy that's not my point). Broken code samples is a good reason to complain. Swift is a moving target, it will be for a while, and this is real pain... but its not a secret. If it bothers someone, why would they choose to use it?
> I'd rather work on modern AND stable language (I actually do, its not Swift, buy that's not my point)
Greetings fellow Rust user ;)
Greetings fellow Rust user ;)
You make it sound like what Swift does is inevitable. Kotlin is of a comparable age to Swift (both started in 2010) and has reached 1.0, which they now plan to maintain Java-like levels of compatibility with. The 1.1 release that's about to come out more or less does that. Certainly any example code you find on the internet today is likely to work fine.
Swift reminds me of java/C++ in the early days. Consumed a lot of memory, the JVM was slow, C++ compilers were janky and so on. Swift is definitely an unstable language although, and it has a lot of performance and stability improvements that need to be done with the debugger, source kit and compiler.
But this will all be fixed in time, in about 4-5 years I'm guessing. It still is definitely a beta language.
Swift work was started 4 years before release, so it's actually a 3+4=7 year language. Every language seems to need a decade before you could call it a stable language I've found, so we have 3 or 4 more years of instability left.
But this will all be fixed in time, in about 4-5 years I'm guessing. It still is definitely a beta language.
Swift work was started 4 years before release, so it's actually a 3+4=7 year language. Every language seems to need a decade before you could call it a stable language I've found, so we have 3 or 4 more years of instability left.
Nailed it.
If Apple can't keep its own sample, example code up-to-date on its website, maybe they are breaking things a little too quickly.
At a minimum, they should make sure their migration tool works on their own examples, that seems like a basic regression test.
At a minimum, they should make sure their migration tool works on their own examples, that seems like a basic regression test.
Apple has always been very bad about keeping its sample code up to do. They seem to only update it when they specifically get a radar about something being broken.
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/
[1] https://github.com/apple/swift-evolution
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/
[1] https://github.com/apple/swift-evolution
I thought they announced swift 4 would not finalize the ABI after all? http://mjtsai.com/blog/2017/02/16/deferring-abi-stability-fr...
"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.
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.
"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.
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.
> 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.
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.
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.
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.
> 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.
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.
"Lot of them have no budget (or will) for complete rewrite. "
I don't mean they should force people onto Swift. I mean that Swift, should be totally independent of ObjC, so that customers, if they choose to use it are not dependent on it.
Also - Apple could feasibly provide a 'lib/bridge' - just as Android can use C++ code as well, if you want to use it.
I think Apple could surely commit to keeping ObjC around for quite some time - maybe 4 years official support, and then maybe 8 years on the devices, but with no more documentation/support.
"All those things will come. If you want them, wait for them."
I don't agree - this is 'doing it wrong'. It's been out for years. This is way past 'early adoption'.
'Doing it right' means that it is easy for new and old developers. Right now - it's hard.
Doing Swift 'right':
1) Make Swift a clean break, get rid of some of the more obscure things that make it difficult. Get rid of relationship to ObjC.
2) Detailed docs, tons of examples. Examples for every single class, every single attribute. 100% of functionality should be 'explainable by example'.
3) Beta for 1 year, then production.
4) No backwards-incompatible changes after out of beta. (Easier said than done).
5) Docs, examples etc that clearly demarcate versioning.
6) Tons of support on Stack Exchange: dedicated staff to simply monitoring, answering, clarifying issues just on Stack Exchange.
7) 'Free Support and Training' for anyone who wants it and who can make it to a major city, i.e. NYC Jan 1-5 or 'weekend course' for anyone who registers. Free. Once every few months. At least 100 Engineers just doing training, and going into dev/studios companies to help them with stuff.
8) Free online courses, for newbs, and those coming from other languages, and Objc.
They made Swift a little too complicated, and left devs hanging in the dark on so many issues.
I don't mean they should force people onto Swift. I mean that Swift, should be totally independent of ObjC, so that customers, if they choose to use it are not dependent on it.
Also - Apple could feasibly provide a 'lib/bridge' - just as Android can use C++ code as well, if you want to use it.
I think Apple could surely commit to keeping ObjC around for quite some time - maybe 4 years official support, and then maybe 8 years on the devices, but with no more documentation/support.
"All those things will come. If you want them, wait for them."
I don't agree - this is 'doing it wrong'. It's been out for years. This is way past 'early adoption'.
'Doing it right' means that it is easy for new and old developers. Right now - it's hard.
Doing Swift 'right':
1) Make Swift a clean break, get rid of some of the more obscure things that make it difficult. Get rid of relationship to ObjC.
2) Detailed docs, tons of examples. Examples for every single class, every single attribute. 100% of functionality should be 'explainable by example'.
3) Beta for 1 year, then production.
4) No backwards-incompatible changes after out of beta. (Easier said than done).
5) Docs, examples etc that clearly demarcate versioning.
6) Tons of support on Stack Exchange: dedicated staff to simply monitoring, answering, clarifying issues just on Stack Exchange.
7) 'Free Support and Training' for anyone who wants it and who can make it to a major city, i.e. NYC Jan 1-5 or 'weekend course' for anyone who registers. Free. Once every few months. At least 100 Engineers just doing training, and going into dev/studios companies to help them with stuff.
8) Free online courses, for newbs, and those coming from other languages, and Objc.
They made Swift a little too complicated, and left devs hanging in the dark on so many issues.
> I don't mean they should force people onto Swift. I mean that Swift, should be totally independent of ObjC
If you will not provide seamless integration, you will seriously limit amount of people who migrate. There are other problems here too: what should library authors do? Write two versions?
> It's been out for years. This is way past 'early adoption'.
Looking at all programming languages I've ever used, getting out of this childhood period always took years. Sure, Apple could do better job perhaps in many aspects, but it really takes a very long time to get a language and stdlib to usable shape.
>Make Swift a clean break, get rid of some of the more obscure things that make it difficult.
If you make a clean break, you limit amount of your users. Without users, you can't tell what obscure things are difficult for those who didn't opt in.
I agree with all those beta periods, stability guarantees, docs and training. I am now appreciating more how well those things work in Rust.
If you will not provide seamless integration, you will seriously limit amount of people who migrate. There are other problems here too: what should library authors do? Write two versions?
> It's been out for years. This is way past 'early adoption'.
Looking at all programming languages I've ever used, getting out of this childhood period always took years. Sure, Apple could do better job perhaps in many aspects, but it really takes a very long time to get a language and stdlib to usable shape.
>Make Swift a clean break, get rid of some of the more obscure things that make it difficult.
If you make a clean break, you limit amount of your users. Without users, you can't tell what obscure things are difficult for those who didn't opt in.
I agree with all those beta periods, stability guarantees, docs and training. I am now appreciating more how well those things work in Rust.
"If you will not provide seamless integration, you will seriously limit amount of people who migrate. "
I don't agree at all.
Tons of people are 'starting out' on Swift - moreover - if Swift were done a little better - it would actually be used on other platforms, etc. - as opposed to an 'iPhone only' type thing.
New projects start all the time.
Major re-factors and re-writes happen all the time.
Second - I do not believe that the premise of: "well I can switch some of my code to Swift, but keep most of my libs on ObjC" - is reasonable. This is a minority case.
And of course - as I said - they could have provided access to ObjC libraries through an interface exactly as Android does.
You want to use 'legacy C++ code' on Android? You can do it. It's just not so clean, but you can do it. The same should have been provided for Swift-ObjC
So - companies who don't want to migrate - can stick to ObjC for a few more years.
The rest can switch over.
"If you make a clean break, you limit amount of your users."
Again I don't agree at all. Node.js has more developers than Swift. With Apple backing it (i.e. 'making it good' - but also making it 'the basis for iPhone) - they could have had an incredible number of users.
There's no reason that Swift couldn't have been used in internal-alpha for a while, then external beta for a while - then then have a 'solid v1'.
AS you say - many languages were 'around for a long time' - but they have also been stable for a long time!
Java for example, did not do anything at the .lang level that was not backwards compatible. The only non-backwards compatible bit was java AWT, which they replaced with Swing. But even AWT is still supported!
So, there's no excuse for rapid rollout of versions that are incompatible with one another, no excuses for huge gaps in documentation etc..
I don't agree at all.
Tons of people are 'starting out' on Swift - moreover - if Swift were done a little better - it would actually be used on other platforms, etc. - as opposed to an 'iPhone only' type thing.
New projects start all the time.
Major re-factors and re-writes happen all the time.
Second - I do not believe that the premise of: "well I can switch some of my code to Swift, but keep most of my libs on ObjC" - is reasonable. This is a minority case.
And of course - as I said - they could have provided access to ObjC libraries through an interface exactly as Android does.
You want to use 'legacy C++ code' on Android? You can do it. It's just not so clean, but you can do it. The same should have been provided for Swift-ObjC
So - companies who don't want to migrate - can stick to ObjC for a few more years.
The rest can switch over.
"If you make a clean break, you limit amount of your users."
Again I don't agree at all. Node.js has more developers than Swift. With Apple backing it (i.e. 'making it good' - but also making it 'the basis for iPhone) - they could have had an incredible number of users.
There's no reason that Swift couldn't have been used in internal-alpha for a while, then external beta for a while - then then have a 'solid v1'.
AS you say - many languages were 'around for a long time' - but they have also been stable for a long time!
Java for example, did not do anything at the .lang level that was not backwards compatible. The only non-backwards compatible bit was java AWT, which they replaced with Swing. But even AWT is still supported!
So, there's no excuse for rapid rollout of versions that are incompatible with one another, no excuses for huge gaps in documentation etc..
>compatible with ObjC was one of the big issues
Considering that was going to be hard requirement, maybe the problem was introducing so many things that are so incompatible with ObjC? There are tons of ways you could vastly improve the programming experience without introducing all this incompatible stuff.
Considering that was going to be hard requirement, maybe the problem was introducing so many things that are so incompatible with ObjC? There are tons of ways you could vastly improve the programming experience without introducing all this incompatible stuff.
As noted in the first link above, source compatibility isn't kept with Swift 3->4 anymore. There are changes to the String APIs.
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.
I don't understand... if those are the problems, write code in objc - it will be good for many years to come. Have some respect. You're looking at open source project, you can get involved yourself if you wish, you can follow design process - you have been given free access to "look into the future" in this area, the future that's being crystallised in front of your eyes - complaining from that position doesn't make sense.
I don't have any problem with the fact Swift is churning. I think its healthy for the language to be improved. I think it's great that there is so much open source activity and enthusiasm around it.
But I also think Apple have been premature about pushing it for sample code and WWDC talks. And some companies have adopted it too early given their resources, constraints and objectives.
Yes it's a lot of fun from an engineering perspective to be on that bleeding edge. It's not so much fun when your boss/client/own business has a tight deadline to ship something, but then you have the extra work to migrate your code to the latest Swift changes.
edits: fixed a couple of typos.