... iOS developers are used to constant change anyway...
I certainly haven't seen "constant change" in iOS development. In many releases, Apple has made changes to their UI that require some minor redesign so that your app doesn't look dated, but that's mostly just piddly UI changes, most of which required few or no code changes. The core of most apps doesn't get rewritten unless something doesn't work or the developer adds major features that necessitate replacing bits to overcome limitations in the original design.
If an iOS developer is having to change his or her code constantly, that usually (but not always) indicates that he or she designed it wrong to begin with. And I think a big part of that is because so many inexperienced developers jumped on the iOS bandwagon early, hoping to make it big by writing apps for a hip new platform. The result was not only excessive amounts of rewriting, but also a proliferation of relatively simple apps that still manage to break with every new release somehow. I suppose it is possible that Swift will dominate the iOS landscape pretty quickly in terms of the number of apps, but only because such a high percentage of iOS apps have so little actual code behind them that you could rewrite them as a web app in a week or two.
But when it comes to any apps that are reasonably complex, I don't see that happening, nor do I see Swift dominating in terms of lines of code for many, many years. In particular, I'd expect most cross-platform game developers to strongly resist moving to Swift because of performance, difficulty integrating with underlying shared C code, etc. For example, good luck writing an OpenGL app in Swift. The function pointer headaches will knock decades off your life.
And that's assuming that developers decide that they care. There was a lot of interest as a result of the initial hype, but interest seems to have waned considerably since then. It's anybody's guess whether developers will actually decide to adopt it. Developers are a fickle bunch, particularly when it comes to programing languages, and iOS developers are no exception. For now, I think the sensible approach is to experiment with the language a bit and see if you like it. If you love it, adopt it. Otherwise, take a wait-and-see approach—wait and see if Apple fixes the initial performance and C compatibility limitations, wait and see if developers adopt it in significant numbers, and wait and see if Apple starts pushing people to adopt it in lieu of Objective-C.
What about the trolls who will say "hey this has been filed for X years and still nobody fucking fixes it!?? FAIL!!" Who needs that kind of drama in a bug db.
Better to have the complaining in a bug database than in a discussion forum where people who are looking for general information will see it. People are going to find a public forum where they can complain about bugs no matter what you do. If you have a bug tracking database, it will be there. If you don't, it will be in your general help forum. If you censor them there, they'll move it to Amazon's product reviews.
The best thing you can do is be open about the bugs and make a reasonable effort to fix bugs in a timely manner. And use bug aging policies that increase the priority of minor bugs if they go unfixed for too long. Then, when your competitors say that you're buggy because you show your bug lists, you can say, "Our bugs are few and minor. That's why we're willing to show our customers those bugs. What do you have to hide?" This will usually end any such silliness, but if your competitors continue down the path of claiming that your software is buggy, set up a public Bugzilla database for their product and watch the fun.
While you're busy learning obj-C, the rest of the ios developers will be learning Swift. In 5 years, by the time Apple has retired Obj-C, you'll be left with another out of date skillset. In 5 years companies will be looking for Swift developers, and you won't be ready, and you will once again find yourself behind everyone else.
It's a new language, not a new platform. It uses the same frameworks as Objective-C. So the five years you spent learning iOS development in Objective-C simultaneously taught you iOS development in Swift, aside from some syntactic sugar. If it takes you five years to learn the language itself, you should seriously consider a different career and leave programming to people who don't get hopelessly distracted by syntax.
Documentation is just the beginning. There's also also sample code, plus all the open source code out there, plus snippets on Stack Overflow, etc. It will take many years for Swift to catch up with all of that.
You don't know Apple, or iOS developers. Dominant over ObjC within two years...
From what I've read, Swift is not positioned as an Objective-C replacement. It's positioned more as a Ruby–Objective-C bridge replacement. It will be completely dominant over Ruby for OS X development purposes within two years. It will slowly gain traction among iOS developers, and some will use it for new code, but that doesn't mean it will be dominant by any means.
The fact remains that there are billions of lines of Objective-C code out there. If you honestly think that developers are going to rewrite all those billions of lines of code in another programming language within two years, or write an equivalent amount of Swift code in that time, then you don't know developers. Yes, maybe the fart apps will be predominantly Swift in two years, but not the nontrivial apps. The longer a language has been around, the longer it will take for another language to take its place.
In the best-case scenario for Swift, even if every developer stopped writing Objective-C code cold turkey today, assuming the lines of code written by iOS developers per year is mostly constant (I realize that isn't quite true, but it's nowhere near exponential growth), it should take close to seven years before iOS Swift code lines outnumber iOS Objective-C code lines. And it could take fourteen years to reach the balancing point for OS X. And that's the best-case scenario. The reality is, most developers will phase it in over a period of time, initially using it only for new projects (if that). So the real-world balancing points are even farther out.
Now if Apple were to release an Objective-C to Swift translator, that would change the situation pretty significantly, for two reasons: first, because it would mean that Apple considers Swift to be enough better than Objective-C to make it worth porting your old code, and second, because it would make it possible to quickly replace Objective-C code with machine-translated Swift code. At that point, Swift might be the language to learn first, depending in large part on how developers react. But unless and until that happens, although it's a good idea to learn Swift, it shouldn't be the language you learn first unless you just enjoy suffering from a lack of adequate code snippets and sample code.
... and by the end of next year that prediction will probably seem ridiculously conservative...
My predictions are rarely conservative. If anything, they're usually not cynical enough to adequately model developer apathy and resistance to change....
Very different situation. I work with a lot of companies that develop iOS applications, and it's extremely rare for them to be more than a couple of years behind the cutting edge.
Staying close to the cutting edge is easy when it's an incremental change. It's a very different thing when it means throwing out all of your your code. With the Carbon transition, you had to throw out and rewrite all of your code. Transitioning Objective-C code to Swift would have the same implication, because the language syntax is different.
Mind you, the effort in moving to Swift is lower, because the frameworks you're using are the same. On the other hand, the benefit is also lower, because the frameworks you're using are the same, and because the languages are designed to interact almost seamlessly, which largely eliminates any incentive to move existing code.
I expect most developers (and by that, I mean anybody not doing it as a hobby) to keep all of their existing code in Objective-C, but add new code in Swift, assuming they decide to adopt it at all. I could be wrong, but I really, truly don't see anything about the new language that makes me want to start rewriting those billions of lines of existing code in a new language. If I were starting a new app from scratch... well, I just did, and I chose Objective-C, because I don't think Swift is ready yet. Maybe in two or three years, I might start writing new from-scratch apps in Swift.
Modern Apple does it very infrequently, and usually, when they do, it's because they've got something newer to replace it. In this case, Swift is the newer thing.
I disagree. IMO, it's telling that Apple has never given even the slightest hint that Objective-C will ever be anything less than a first-class language. Instead, Apple is positioning this not as a replacement for Objective-C, but as a replacement for the Ruby/Python/Perl bridges—as a first-class, truly Apple-supported scripting language—something that Apple has never had before.
The only major uproot in Apple's history (no, the CPU architecture changes weren't major unless you were writing a lot of code in assembly language) was when they deprecated Carbon. The big difference here is that Carbon was always intended to be temporary. Initially, it wasn't even going to exist, but pressure from a few large developers convinced them to make a classic-Mac-compatible API available as a stopgap so that they could transition their code more gradually to OS X and Cocoa. Carbon was always going away from the day it first became available in OS X, yet even still, it took the better part of a decade before they released the first major feature (64-bit support) that was incompatible with Carbon. More to the point, Carbon code still works to this day, fourteen years later, and lots of apps still contain some vestigial Carbon code, albeit mostly non-UI code, much of which still works even in 64-bit apps.
Given the glacial pace at which Apple removed an API that was always supposed to be temporary, tell me why in the world you think that Apple won't take even longer to replace a non-temporary language that Apple says isn't going away with a language that Apple says isn't replacing it!?!
Finally, I'd add that for the moment, there's another very strong reason to not move to Swift: Preliminary third-party analysis of Swift shows that for many simple operations, it is more than an order of magnitude slower than Objective-C. Assuming their testing methodology does not prove to be invalid for some reason, I would consider Swift to be a good choice for the same sorts of hobby apps that you might write using the Objective-C–Ruby bridge. However, if you're thinking about writing a major app in Swift, you should probably think twice, at least for now. Presumably,
Don't listen to these ass clowns saying "Go with Obj-C". If they had any clue they would know that introducing Swift was the first step towards obsoleting Obj-C.
Here's why you should learn Objective-C first:
There are billions of lines of production Objective-C code out there, and remarkably close to zero lines of production Swift code out there. If Swift is the first step towards obsoleting Objective-C, then the second step must be waiting fifty years for all the Objective-C code out there to get rewritten.
Swift isn't finished. From what I've read, they expect to make syntax-incompatible changes. Although they plan to have translators to move old code forward, do you really trust automated translators enough to run them on huge chunks of production code?
There's no assurance that Swift has staying power. Over the years, Apple has released bridges to many different programming languages over the years. Java? Check. Perl? Check. Ruby? Check. Python? Check. Now ask yourself how many of those bridges are still supported by Apple. If you only have time to learn one language, it should be the one that you know will still be popular in ten years.
Swift is designed to make it easy to build apps that include a mix of Swift, C, and Objective-C. Therefore, there's no reason to believe that it won't be possible to write fully capable apps for iOS and OS X in Objective-C for the foreseeable future. And even if, God forbid, Apple decides to be a bunch of a**holes and starts shipping a bunch of Swift-only classes in a reckless and desperate attempt to pressure developers to switch to Swift, you'll still only be a tiny bit of glue code away.
That's not to say that Swift isn't interesting. The ability to test code on the fly is certainly cool, and if Swift proves to be a long-term-viable language, I'd imagine it will eventually (over a couple of decades) become the dominant language for OS X and iOS development. However, there's plenty of time to learn Swift. If you want to start writing real-world code today, you're better off learning Objective-C, because there are orders of magnitude more examples, you'll be more likely to find employment (there's way more Objective-C code out there to maintain), and more people can help when you run into problems.
Ask again in five years, and the answer might be different, but for now, IMO, Objective-C is the clear choice unless you don't already know any C-based language, and probably even then.
I didn't think it was "legal" to target an App Store-bound iOS App in anything but Obj-C and now, Swift. Could I hypothetically write an iOS App in ARM Assembly?
I don't see why not. AFAIK, Apple removed the restrictions on developers' choice of programming languages just five months after they added them—probably in response to developers with pitchforks....
I'm not sure what the DOJ did over the past few months, but whatever it was must have been seriously heinous to get Apple and Google to work together against them. I mean, we've only been demanding encrypted email communication for what, twenty years? And all of a sudden, Apple's DOJ abuse canary comes down, and Apple and Google are scrambling to encrypt everything.
Why do I have a feeling that Eric Holder's resignation is just the tip of the iceberg?
I live in the U.S. When I go to Check Order Status in my Apple on-line account (store.apple.com), I find hundreds of orders, none of which are mine, coming from all over Western Europe, dating back to July of this year. I see the items ordered, order numbers, mailing and shipping addresses and e-mail information for them all. I can track shipments, but I can't cancel orders.
Somebody with a volume purchase plan account probably made a typo when adding administrator email addresses or something.
Go here and see if it lets you sign in. If so, contact Apple Store support from within the VPP site and let them know that your Apple ID is incorrectly associated with a VPP plan.
By that standard, asking why the universe exists is equivalent to asking, "What information would have enabled me to predict that the universe exists without being in it." So even if we accept your meaning of "why" (which IMO stretches the actual meaning of "why" considerably), asking why the universe exists does posit the existence of the person asking the question (which goes without saying anyway unless you're in a philosophy class), but it does not posit the existence of a creator, as you seem to be claiming.
Perhaps the GP meant 2000. (The Cube and the early iMacs were fanless.)
Or perhaps the GP meant that (by default) the first MacBook Air's fans ran too slowly to keep the machine from overheating and throttling the CPU when under significant load.
I think you missed the GP's point. Big corporations exhibit almost insatiable greed, and will do just about anything to save money, from H1Bs to outsourcing. Yet they don't hire women more than men. There are two possible explanations:
They're ignoring their primary driving force—profit—in favor of hiring more men because they incorrectly believe that men are cheaper, when in fact women are.
Men really are cheaper, in spite of the higher base wages.
In theory, they are both equally plausible. And in practice, that's also true, at least up until the first study was published. But these days, given the sheer number of studies that all say that women are cheaper, you'd expect a significant number of the more forward-thinking execs to take it to heart and hire mostly women as a cost-saving measure. If that is not happening, it suggests the possibility that they have studied those cost differences internally and have come to different conclusions based on more complete information.
The only way to know for sure would be to find an exec willing to disclose a company's own internal studies on the subject, and that's not likely to happen. With that said, the longer we go without corporations deciding to hire more women, the greater the chances that those studies are flawed. After all, the alternative requires us to believe that something matters more to a corporation than money, which for most companies would require an almost unimaginable suspension of disbelief.
Another thing worth noting is that a small percentage of people choose the other two options. Thus, it can be logically inferred that there's an evolutionary advantage to having a few hermits and sociopaths as a sort of a failsafe in the relatively rare situations where being a hermit or a sociopath confers a survival advantage compared with normal, functioning members of a modern society, such as plagues or corporate boardrooms.
That's remotely possible, but if so, it means Samsung has no cojones. After all, they haven't strong-armed Apple into dropping support so quickly. Either way, it makes Samsung look bad, just for different reasons.
The closest anyone has come up with is the "was this review helpful?" but that gets abused easily.
The big problem with the helpful/not helpful dichotomy as a means for rating reviewers is that it fails to take into account why the reviewer didn't find it helpful. What the system needs, IMO, is to ask a second question at that point:
Did you find the review not helpful because (check all that apply):
It mainly covered things that I don't care about.
I disagree with the opinion.
It contains facts that are incorrect.
It had nothing to do with the product/service (spam and other abuse)
A review marked with the fourth one will get flagged for review by a human, and if verified to be crap, will lower the reviewer's reputation for everyone, and will be removed.
A review marked with the third one (factually incorrect) will just lower the reviewer's reputation, but at least initially by a smaller amount than a "Helpful" vote increases it. The more reviews this occurs in, the more negatively each negative impacts that person's score, so if a person consistently lies, the negatives count more and more, until they greatly outweigh the positives. However, that balance should only tip when those negatives come from unique users (so that one user can't just mark every review by a particular reviewer as unhelpful and have a bigger impact than marking a single review that way), and those ratings should be cancelled out by a sufficient number of positive reviews, ensuring that a small number of people can't attack a reviewer by each reporting one of his or her reviews as factually incorrect.
A review marked with the first two options ("not interested" and "I disagree") will lower the reviewer's reputation, but only for that reviewer and other people whose "not interested" and "I disagree" ratings on other goods and services are statistically similar to those of the reviewer. This allows users to get better, more individualized reviews that are more likely to match their interests and concerns, without adversely penalizing other people who might be interested in and concerned about the same things as the reviewer in question. To that end, instead of "44 out of 50 people found this helpful", it would say "44 out of 50 people whose tastes match yours found this helpful", such that other users of the site might well see completely different numbers.
And users who frequently give "not helpful" ratings with more than two boxes checked, but rarely give "helpful" ratings, should have progressively smaller impact on the overall helpfulness rating for the reviews that they rate, until at some point their helpful/not helpful ratings end up getting thrown away entirely (except in their own view).
Of course, if it's a minor road, you might be able to save a lot of power by not showing the lines unless there's somebody actually on the road (at least during the day, when cars cast shadows). Then again, I don't suppose you would typically need movable lines on a minor road, so... never mind.
Another approach might be something more passive, where the line areas become reflective when an electrical charge causes them to line up in a certain way, so that the sun provides all the light, and where the line areas change to be transparent when you polarize them the other way, thus showing the relatively dark surface of the solar cells. Then, you could use the LEDs only at night, when the light requirements are much lower, or come up with a means of tweaking the polarity so that the lines reflect the headlights.
He's wrong. The problem is that the concept of "God" is un-falsifiable. So you can always tack "because God wanted it that way" onto anything.
Which is relevant how? This is what makes religious belief not a science, but that has zero bearing on whether science makes religion irrelevant, except in the minds of people who already believe it to be.
This bizarre misunderstanding of science yields the paradox that even as we expect the impossible from science ("Please, Mr Economist, peer into your crystal ball and tell us what will happen if Obama raises/cuts taxes"), we also have a very anti-scientific mindset in many areas.
He thinks that Economics is a science. That's how wrong he is.
I think you seriously misread that bit. What he said was that people who don't understand science believe that it can explain things like what would happen if the President raises or lowers taxes. In other words, he's saying that economics is not a science.
And in that regard, he is wrong, and so are you (unless that was a typo). At its core, economics is about making hypotheses about how a complex system will react to an event, then observing how it actually reacts and falsifying those hypotheses. Or at least that's what economics is supposed to be about, Reagonomics notwithstanding.
When you ask "why is the universe here" the first thing to notice is you are giving human intent to something that has no intent. It is like asking "why does my shirt want to be blue?"
No, it is like asking, "Why does this shirt exist." It isn't anthropomorphizing the shirt; it is merely assuming that there is a reason for the shirt to exist. In that case, the answer is obvious: because someone created it. Asking the same question about a plant gets you the answer, "because the seed fell on fertile soil and grew." It may or may not have been planted by a human; if it was, then the answer is interesting. If it merely blew in, then the answer is also interesting, but for different reasons.
Asking why the universe exists is a reasonable question. It is a question that may or may not be impossible to answer with science in any useful fashion, if only because science occurs within the universe, and thus probably cannot answer questions about anything that occurs outside that universe.
Religion is one approach to answering the questions that science cannot feasibly answer. It is not the only approach, certainly, but that makes it no less useful than philosophy or any other nonscientific field that concerns the contents of the hearts of man. Where religion strays into problem territory is when it attempts to answer questions that science can answer. Those bounds are constantly shifting as science improves, hence the perceived conflict between the two. However, that conflict is illusory. After all, we can explain religion, or at least the evolutionary path that led us to have religion, scientifically. Therefore, religion is at its core a natural phenomenon that is no less a part of every human being than the desire for knowledge itself.
Slashdot Mirror
I certainly haven't seen "constant change" in iOS development. In many releases, Apple has made changes to their UI that require some minor redesign so that your app doesn't look dated, but that's mostly just piddly UI changes, most of which required few or no code changes. The core of most apps doesn't get rewritten unless something doesn't work or the developer adds major features that necessitate replacing bits to overcome limitations in the original design.
If an iOS developer is having to change his or her code constantly, that usually (but not always) indicates that he or she designed it wrong to begin with. And I think a big part of that is because so many inexperienced developers jumped on the iOS bandwagon early, hoping to make it big by writing apps for a hip new platform. The result was not only excessive amounts of rewriting, but also a proliferation of relatively simple apps that still manage to break with every new release somehow. I suppose it is possible that Swift will dominate the iOS landscape pretty quickly in terms of the number of apps, but only because such a high percentage of iOS apps have so little actual code behind them that you could rewrite them as a web app in a week or two.
But when it comes to any apps that are reasonably complex, I don't see that happening, nor do I see Swift dominating in terms of lines of code for many, many years. In particular, I'd expect most cross-platform game developers to strongly resist moving to Swift because of performance, difficulty integrating with underlying shared C code, etc. For example, good luck writing an OpenGL app in Swift. The function pointer headaches will knock decades off your life.
And that's assuming that developers decide that they care. There was a lot of interest as a result of the initial hype, but interest seems to have waned considerably since then. It's anybody's guess whether developers will actually decide to adopt it. Developers are a fickle bunch, particularly when it comes to programing languages, and iOS developers are no exception. For now, I think the sensible approach is to experiment with the language a bit and see if you like it. If you love it, adopt it. Otherwise, take a wait-and-see approach—wait and see if Apple fixes the initial performance and C compatibility limitations, wait and see if developers adopt it in significant numbers, and wait and see if Apple starts pushing people to adopt it in lieu of Objective-C.
Better to have the complaining in a bug database than in a discussion forum where people who are looking for general information will see it. People are going to find a public forum where they can complain about bugs no matter what you do. If you have a bug tracking database, it will be there. If you don't, it will be in your general help forum. If you censor them there, they'll move it to Amazon's product reviews.
The best thing you can do is be open about the bugs and make a reasonable effort to fix bugs in a timely manner. And use bug aging policies that increase the priority of minor bugs if they go unfixed for too long. Then, when your competitors say that you're buggy because you show your bug lists, you can say, "Our bugs are few and minor. That's why we're willing to show our customers those bugs. What do you have to hide?" This will usually end any such silliness, but if your competitors continue down the path of claiming that your software is buggy, set up a public Bugzilla database for their product and watch the fun.
It's a new language, not a new platform. It uses the same frameworks as Objective-C. So the five years you spent learning iOS development in Objective-C simultaneously taught you iOS development in Swift, aside from some syntactic sugar. If it takes you five years to learn the language itself, you should seriously consider a different career and leave programming to people who don't get hopelessly distracted by syntax.
Documentation is just the beginning. There's also also sample code, plus all the open source code out there, plus snippets on Stack Overflow, etc. It will take many years for Swift to catch up with all of that.
From what I've read, Swift is not positioned as an Objective-C replacement. It's positioned more as a Ruby–Objective-C bridge replacement. It will be completely dominant over Ruby for OS X development purposes within two years. It will slowly gain traction among iOS developers, and some will use it for new code, but that doesn't mean it will be dominant by any means.
The fact remains that there are billions of lines of Objective-C code out there. If you honestly think that developers are going to rewrite all those billions of lines of code in another programming language within two years, or write an equivalent amount of Swift code in that time, then you don't know developers. Yes, maybe the fart apps will be predominantly Swift in two years, but not the nontrivial apps. The longer a language has been around, the longer it will take for another language to take its place.
In the best-case scenario for Swift, even if every developer stopped writing Objective-C code cold turkey today, assuming the lines of code written by iOS developers per year is mostly constant (I realize that isn't quite true, but it's nowhere near exponential growth), it should take close to seven years before iOS Swift code lines outnumber iOS Objective-C code lines. And it could take fourteen years to reach the balancing point for OS X. And that's the best-case scenario. The reality is, most developers will phase it in over a period of time, initially using it only for new projects (if that). So the real-world balancing points are even farther out.
Now if Apple were to release an Objective-C to Swift translator, that would change the situation pretty significantly, for two reasons: first, because it would mean that Apple considers Swift to be enough better than Objective-C to make it worth porting your old code, and second, because it would make it possible to quickly replace Objective-C code with machine-translated Swift code. At that point, Swift might be the language to learn first, depending in large part on how developers react. But unless and until that happens, although it's a good idea to learn Swift, it shouldn't be the language you learn first unless you just enjoy suffering from a lack of adequate code snippets and sample code.
My predictions are rarely conservative. If anything, they're usually not cynical enough to adequately model developer apathy and resistance to change....
Now take that compiled code and turn it back into Objective-C.
Staying close to the cutting edge is easy when it's an incremental change. It's a very different thing when it means throwing out all of your your code. With the Carbon transition, you had to throw out and rewrite all of your code. Transitioning Objective-C code to Swift would have the same implication, because the language syntax is different.
Mind you, the effort in moving to Swift is lower, because the frameworks you're using are the same. On the other hand, the benefit is also lower, because the frameworks you're using are the same, and because the languages are designed to interact almost seamlessly, which largely eliminates any incentive to move existing code.
I expect most developers (and by that, I mean anybody not doing it as a hobby) to keep all of their existing code in Objective-C, but add new code in Swift, assuming they decide to adopt it at all. I could be wrong, but I really, truly don't see anything about the new language that makes me want to start rewriting those billions of lines of existing code in a new language. If I were starting a new app from scratch... well, I just did, and I chose Objective-C, because I don't think Swift is ready yet. Maybe in two or three years, I might start writing new from-scratch apps in Swift.
I disagree. IMO, it's telling that Apple has never given even the slightest hint that Objective-C will ever be anything less than a first-class language. Instead, Apple is positioning this not as a replacement for Objective-C, but as a replacement for the Ruby/Python/Perl bridges—as a first-class, truly Apple-supported scripting language—something that Apple has never had before.
The only major uproot in Apple's history (no, the CPU architecture changes weren't major unless you were writing a lot of code in assembly language) was when they deprecated Carbon. The big difference here is that Carbon was always intended to be temporary. Initially, it wasn't even going to exist, but pressure from a few large developers convinced them to make a classic-Mac-compatible API available as a stopgap so that they could transition their code more gradually to OS X and Cocoa. Carbon was always going away from the day it first became available in OS X, yet even still, it took the better part of a decade before they released the first major feature (64-bit support) that was incompatible with Carbon. More to the point, Carbon code still works to this day, fourteen years later, and lots of apps still contain some vestigial Carbon code, albeit mostly non-UI code, much of which still works even in 64-bit apps.
Given the glacial pace at which Apple removed an API that was always supposed to be temporary, tell me why in the world you think that Apple won't take even longer to replace a non-temporary language that Apple says isn't going away with a language that Apple says isn't replacing it!?!
Finally, I'd add that for the moment, there's another very strong reason to not move to Swift: Preliminary third-party analysis of Swift shows that for many simple operations, it is more than an order of magnitude slower than Objective-C. Assuming their testing methodology does not prove to be invalid for some reason, I would consider Swift to be a good choice for the same sorts of hobby apps that you might write using the Objective-C–Ruby bridge. However, if you're thinking about writing a major app in Swift, you should probably think twice, at least for now. Presumably,
Hmm. Maybe your Apple ID is associated with some magic sentinel value, like NULL. :-D
File a bug report at bugreport.apple.com.
Here's why you should learn Objective-C first:
Swift is designed to make it easy to build apps that include a mix of Swift, C, and Objective-C. Therefore, there's no reason to believe that it won't be possible to write fully capable apps for iOS and OS X in Objective-C for the foreseeable future. And even if, God forbid, Apple decides to be a bunch of a**holes and starts shipping a bunch of Swift-only classes in a reckless and desperate attempt to pressure developers to switch to Swift, you'll still only be a tiny bit of glue code away.
That's not to say that Swift isn't interesting. The ability to test code on the fly is certainly cool, and if Swift proves to be a long-term-viable language, I'd imagine it will eventually (over a couple of decades) become the dominant language for OS X and iOS development. However, there's plenty of time to learn Swift. If you want to start writing real-world code today, you're better off learning Objective-C, because there are orders of magnitude more examples, you'll be more likely to find employment (there's way more Objective-C code out there to maintain), and more people can help when you run into problems.
Ask again in five years, and the answer might be different, but for now, IMO, Objective-C is the clear choice unless you don't already know any C-based language, and probably even then.
I don't see why not. AFAIK, Apple removed the restrictions on developers' choice of programming languages just five months after they added them—probably in response to developers with pitchforks....
I'm not sure what the DOJ did over the past few months, but whatever it was must have been seriously heinous to get Apple and Google to work together against them. I mean, we've only been demanding encrypted email communication for what, twenty years? And all of a sudden, Apple's DOJ abuse canary comes down, and Apple and Google are scrambling to encrypt everything.
Why do I have a feeling that Eric Holder's resignation is just the tip of the iceberg?
Somebody with a volume purchase plan account probably made a typo when adding administrator email addresses or something.
Go here and see if it lets you sign in. If so, contact Apple Store support from within the VPP site and let them know that your Apple ID is incorrectly associated with a VPP plan.
smh
By that standard, asking why the universe exists is equivalent to asking, "What information would have enabled me to predict that the universe exists without being in it." So even if we accept your meaning of "why" (which IMO stretches the actual meaning of "why" considerably), asking why the universe exists does posit the existence of the person asking the question (which goes without saying anyway unless you're in a philosophy class), but it does not posit the existence of a creator, as you seem to be claiming.
Q.E.D.
The timing of this BusinessWeek story is quite amusing. It tells about a startup founder who is hiring mostly women because they're cheaper.
So there you go.
Perhaps the GP meant 2000. (The Cube and the early iMacs were fanless.)
Or perhaps the GP meant that (by default) the first MacBook Air's fans ran too slowly to keep the machine from overheating and throttling the CPU when under significant load.
I think you missed the GP's point. Big corporations exhibit almost insatiable greed, and will do just about anything to save money, from H1Bs to outsourcing. Yet they don't hire women more than men. There are two possible explanations:
In theory, they are both equally plausible. And in practice, that's also true, at least up until the first study was published. But these days, given the sheer number of studies that all say that women are cheaper, you'd expect a significant number of the more forward-thinking execs to take it to heart and hire mostly women as a cost-saving measure. If that is not happening, it suggests the possibility that they have studied those cost differences internally and have come to different conclusions based on more complete information.
The only way to know for sure would be to find an exec willing to disclose a company's own internal studies on the subject, and that's not likely to happen. With that said, the longer we go without corporations deciding to hire more women, the greater the chances that those studies are flawed. After all, the alternative requires us to believe that something matters more to a corporation than money, which for most companies would require an almost unimaginable suspension of disbelief.
Counterexample: Why is the sky blue?
Late-stage Ebola typically involves skin lesions. So any contact with the dead means you're touching bodily fluids.
Another thing worth noting is that a small percentage of people choose the other two options. Thus, it can be logically inferred that there's an evolutionary advantage to having a few hermits and sociopaths as a sort of a failsafe in the relatively rare situations where being a hermit or a sociopath confers a survival advantage compared with normal, functioning members of a modern society, such as plagues or corporate boardrooms.
That's remotely possible, but if so, it means Samsung has no cojones. After all, they haven't strong-armed Apple into dropping support so quickly. Either way, it makes Samsung look bad, just for different reasons.
The big problem with the helpful/not helpful dichotomy as a means for rating reviewers is that it fails to take into account why the reviewer didn't find it helpful. What the system needs, IMO, is to ask a second question at that point:
Did you find the review not helpful because (check all that apply):
A review marked with the fourth one will get flagged for review by a human, and if verified to be crap, will lower the reviewer's reputation for everyone, and will be removed.
A review marked with the third one (factually incorrect) will just lower the reviewer's reputation, but at least initially by a smaller amount than a "Helpful" vote increases it. The more reviews this occurs in, the more negatively each negative impacts that person's score, so if a person consistently lies, the negatives count more and more, until they greatly outweigh the positives. However, that balance should only tip when those negatives come from unique users (so that one user can't just mark every review by a particular reviewer as unhelpful and have a bigger impact than marking a single review that way), and those ratings should be cancelled out by a sufficient number of positive reviews, ensuring that a small number of people can't attack a reviewer by each reporting one of his or her reviews as factually incorrect.
A review marked with the first two options ("not interested" and "I disagree") will lower the reviewer's reputation, but only for that reviewer and other people whose "not interested" and "I disagree" ratings on other goods and services are statistically similar to those of the reviewer. This allows users to get better, more individualized reviews that are more likely to match their interests and concerns, without adversely penalizing other people who might be interested in and concerned about the same things as the reviewer in question. To that end, instead of "44 out of 50 people found this helpful", it would say "44 out of 50 people whose tastes match yours found this helpful", such that other users of the site might well see completely different numbers.
And users who frequently give "not helpful" ratings with more than two boxes checked, but rarely give "helpful" ratings, should have progressively smaller impact on the overall helpfulness rating for the reviews that they rate, until at some point their helpful/not helpful ratings end up getting thrown away entirely (except in their own view).
I know this one. It's something about the rightful beneficiary of the estate of Prince Akeem Joffer.
Of course, if it's a minor road, you might be able to save a lot of power by not showing the lines unless there's somebody actually on the road (at least during the day, when cars cast shadows). Then again, I don't suppose you would typically need movable lines on a minor road, so... never mind.
Another approach might be something more passive, where the line areas become reflective when an electrical charge causes them to line up in a certain way, so that the sun provides all the light, and where the line areas change to be transparent when you polarize them the other way, thus showing the relatively dark surface of the solar cells. Then, you could use the LEDs only at night, when the light requirements are much lower, or come up with a means of tweaking the polarity so that the lines reflect the headlights.
Which is relevant how? This is what makes religious belief not a science, but that has zero bearing on whether science makes religion irrelevant, except in the minds of people who already believe it to be.
I think you seriously misread that bit. What he said was that people who don't understand science believe that it can explain things like what would happen if the President raises or lowers taxes. In other words, he's saying that economics is not a science.
And in that regard, he is wrong, and so are you (unless that was a typo). At its core, economics is about making hypotheses about how a complex system will react to an event, then observing how it actually reacts and falsifying those hypotheses. Or at least that's what economics is supposed to be about, Reagonomics notwithstanding.
No, it is like asking, "Why does this shirt exist." It isn't anthropomorphizing the shirt; it is merely assuming that there is a reason for the shirt to exist. In that case, the answer is obvious: because someone created it. Asking the same question about a plant gets you the answer, "because the seed fell on fertile soil and grew." It may or may not have been planted by a human; if it was, then the answer is interesting. If it merely blew in, then the answer is also interesting, but for different reasons.
Asking why the universe exists is a reasonable question. It is a question that may or may not be impossible to answer with science in any useful fashion, if only because science occurs within the universe, and thus probably cannot answer questions about anything that occurs outside that universe.
Religion is one approach to answering the questions that science cannot feasibly answer. It is not the only approach, certainly, but that makes it no less useful than philosophy or any other nonscientific field that concerns the contents of the hearts of man. Where religion strays into problem territory is when it attempts to answer questions that science can answer. Those bounds are constantly shifting as science improves, hence the perceived conflict between the two. However, that conflict is illusory. After all, we can explain religion, or at least the evolutionary path that led us to have religion, scientifically. Therefore, religion is at its core a natural phenomenon that is no less a part of every human being than the desire for knowledge itself.