Other than a handful of obvious edge cases (the worst of which were fixed with fast enumeration and string and number constants), I'd argue that it mostly isn't Objective-C that is too verbose, but rather the Cocoa APIs themselves. And you'll be using those same ginormous scrubtheKitchenSink:withBrilloPad:andCleanser:byHand:usingExcessiveForce: methods in Swift, just with slightly different punctuation....
yes they do. Around here you can not legally live in your home if you do not have electrical service at your home. it specifically says, electrical utility with an active account.
Want to get that law changed really quickly? Find yourself a prosecutor who grew up poor. Get that person to press charges against the power company for cutting off people's power when they fail to pay their bills, because doing so forces people to choose between committing a crime and leaving the area, which potentially constitutes election tampering.:-)
I suspect that the solution, assuming FTL travel is possible, is to ignore the time dilation problem. Time dilation occurs at speeds less than c, but IIRC, at least one theory posits that the effects of relativity are backwards for speeds greater than c, so if you traveled at something approaching infinite speed, there's some magic point at which no time dilation would occur, I think. Either that or time would run backwards. I'm not sure which. Either way, the net effect would be the same.:-)
Not a lot, actually. The most important aspect of real security is compartmentalization—ensuring that you don't have any high-value individual targets:
Every desktop has individual credentials for the local user, and except when unavoidable, you don't grant any network users (LDAP, etc.) any access. Every desktop has a separate external hard drive used for backup.
For shared projects, you have project servers, one per major project. Just like desktop machines, access is granted only to people working on the project. It has its own credentials, and it is backed up separately—ideally to an off-site server, and stored encrypted on that server.
Every email not involving a mailing list is sent encrypted, so that it never exists in a decrypted form on a centralized server.
None of those things should cost significant amounts of money. They're just simple policy decisions. And with a scheme like the above, you typically wouldn't see attacks like this being successful in the absence of a massive zero-day remote kernel exploit.
If you want added security, you could write a piece of software in a few minutes that logs all traffic by IP address and port, then compares it with traffic requested by the user's web browser (by continuously reading the browser's history and uploading any new locations every couple of minutes), and flags anything that doesn't match. Automatically ignore any automatic updates by software that your IT department installed, plus any known addresses owned by your OS manufacturer. If you see any other traffic, shut off the port immediately, and contact the user to verify that the traffic is expected. If so, whitelist that IP and port after verifying that the software the user is running is legit.
Finally, add mail server rules that sanity check any email attachments, and similar rules for your HTTP proxy. If someone receives a disk image, ZIP archive, or other archive, extract the contents and ensure that there are no executables within it. If there are, allow the attachment if the executable is signed by a trusted authority. Otherwise, store a copy of the attachment in a secure location, and either filter it from the mail archive or refuse to send the final packet of data to the web browser. Flag it for review.
Like the two guys running away from the grizzly bear, security doesn't have to be flawless; it just has to be robust enough to convince the attacker to go after an easier target.
It's clear the movie companies themselves are to blame.
You joke, but IMO, they are largely responsible—a lot more so than ISPs who merely failed to prevent the normal use of their networks by people doing nefarious things. After all, these movies were stolen off of the movie studios' machines, which means they clearly didn't take security seriously enough.
Back on topic, yes, Chernobyl is still dangerous, but probably not that dangerous unless you eat or breathe the dirt. From what I've read, some of the most contaminated objects (300 microsieverts per hour) will give you a year's background radiation in half a day, which is about 30 times the level you'd get flying on an airplane. But for the most part, it's about an order of magnitude less than that.
Just to clarify, there are a few spots that are considerably higher than that—particularly indoors near the reactor, and outdoors downwind from the reactor. Those areas are clearly still unsafe. But a fair percentage of the abandoned areas could potentially be resettled, in theory.
Just because people are doing it doesn't make it safe, it just makes them ignorant.
It's true that the risk from consuming small amounts of produce from the area is low. If you are a reporter visiting for a while the risk is low, but if you live there it's a different story. Children are at particular risk, but even adults who allow long lived radioactive particles to accumulate in their bodies are facing an increased risk of health problems.
Assuming they cleared the top few inches of soil in those farm areas and replaced it with soil from elsewhere, and assuming that they use well water rather than surface water, I'd expect the extra risk from eating local produce to be negligible. If they didn't do those things, then yeah, I'd be a bit concerned.
To be pedantic, that's subtly inaccurate. In English if we say something negative "to the person", we're talking about a face-to-face conversation, whereas an ad hominem attack need not be a conversation at all. A better translation would be "towards the person" or "at the person". In fact our word "at" comes from the Latin word "ad".
Back on topic, yes, Chernobyl is still dangerous, but probably not that dangerous unless you eat or breathe the dirt. From what I've read, some of the most contaminated objects (300 microsieverts per hour) will give you a year's background radiation in half a day, which is about 30 times the level you'd get flying on an airplane. But for the most part, it's about an order of magnitude less than that.
Yeah, that's what I get for taking a number from skimming the first Google hit.:-)
The real problem is that you can't assume you'll have 4 seconds, and that isn't because of the cow running out in the road. The problem is that at 80mph it will take 7.8 seconds to stop, which is over 900ft.
Except you don't. For one thing, at 85 MPH, the total stopping distance is only about 532 feet. You forgot to factor in the fact that your speed isn't 85 MPH for that entire 7.8 seconds.:-) For another, you don't have to stop. You just have to get slow enough to either avoid hitting the animal or scare the animal out of the lane. And even if you were unable to avoid it, and even if you only had half the stopping distance, the difference between hitting it at 45 MPH and 85 MPH makes a huge difference in terms of how much damage you take.:-)
On straight, flat ground 20 and 55 are going to be about the same for something large and slow like a cow. 80 gets into different territory because most people don't have good enough distance vision, so by the time the supposed shrubbery resolves into a cow, there isn't enough stopping distance left.
That seems like a good reason to keep vegetation clear of the highways. You'll never mistake a nonexistent bush for a cow. I've never seen a 65 MPH (or faster) road without at least a twenty or thirty foot exclusion zone on both sides of the road. Most normal cows can run at about five or six miles per hour—about the speed of a person walking fast. So in the worst case, it will take about four seconds for the animal to get out onto the road. So at a maximum run, the cow will get there about a half second before you're fully stopped. You might hit it, but you'll hit it at maybe 15–20 MPH.
It's realistic, so long as the quoted EPA highway fuel economy is 45 mpg or higher, it should get around 30 mpg at 85 mph: http://www.mpgforspeed.com/ [mpgforspeed.com]
Or if the vehicle has additional gears to give you a higher gear ratio at higher speeds.
I'm completely for stopping all kinds of discrimination, but when you're taking things from the grandchildren of the people who actually performed the discrimination, you're doing it wrong.
Yup. And if you introduce systemic biases (quotas, lowered entrance requirements, etc.) to encourage girls to do something, then invariably some of those girls will be less qualified than the boys who get excluded. When the boys notice this (and they will), then they'll start to assume that all girls are less qualified. And thanks to confirmation bias, this perception will tend to strengthen over time, because they'll always notice the underqualified women and won't notice the qualified women. Thus, in the long run, using reverse biasing to counter discrimination almost invariably leads to more discrimination, not less.
And although it is unclear whether contests that are strictly for women will have the same effect, at a minimum, they'll cause envy, which is almost certainly not an effective way to encourage men to take women in STEM more seriously.
You can't fix discrimination with more discrimination. The only way to fix discrimination is with marketing—by hyping the heck out of members of underrepresented groups who are good at what they do, so that they'll serve as examples for other people in those underrepresented groups, and will encourage them to work harder to overcome the discrimination and take jobs in particular fields. This approach is also the only way to counteract the confirmation bias that is the source of nearly all discrimination—by repeatedly showing examples that contradict the biased expectations, and by showing those counterexamples far more often than they see confirmatory examples.
For example, if you want to get more girls into a contest like this, when you advertise the contest, use mostly pictures of girls. Don't change the rules; don't change the requirements; change the image you project. Unlike every other strategy, this works, and has been repeatedly proven to work through decades of advertising research.
The entire networking stack has no Swift documentation except for a very trivial NSURLSession example.
NSURLConnection [apple.com] seems to have full Swift documentation (though it doesn't show up by default under all for some reason).
It has reference documentation. It has no sample code, and no conceptual docs.
Or you could just use one of the countless online examples [google.com] of networking with Swift, even the AlamoFire library written by the same guy that did AFNetworking...
99% of which still fall into the "trivial examples" category. The AlamoFire is a little bit more complex, but still doesn't come close to demonstrating all of its capabilities.
GC on ObjC was never revolutionary, it was added on because everyone else had it - ARC was a much better idea, and they aren't dropping that.
Fair enough. I thought GC was a mistake from the very beginning, personally. Either way, IIRC, lots of people initially touted it as the solution to the complexity of retain-release schemes.
I don't see a history of Apple dropping much of anything as all other frameworks and technologies they've developed have pretty much stayed and evolved. Can you provide any other example, because I con't think of any that I was using that ever got dropped... hell, even iCloud document support which has historically had a ton of issues is still there, evolving and iterating...
Apple's Java implementation and WebObjects both come to mind, though both predate iOS. And Apple developed and dropped bridges for Ruby, Python and Java. And the Message framework (NSMailDelivery), Instant Message framework, and QTKit framework were also fairly short-lived, IIRC, or at least they seemed that way.
For most Objective-C classes, that's true, but I was under the impression that Swift's array and dictionary support consists of wrapper code around NSArray/NSDictionary; I'm not certain of that, though.
I'm sorry, how are Tuples mere syntactic sugar over ObjC? Or operator overloading?
Operator overloading is, IMO, almost inherently a mistake. And tuples are pure syntactic sugar. Anything you can do with tuples can typically be done without tuples in just a couple more lines of code.
Point at one aspect of iOS development that has no Swift documentation. Just one.
The entire networking stack has no Swift documentation except for a very trivial NSURLSession example. And last I checked, large chunks of WebKit (which may or may not be available on iOS) and Accelerate were still undocumented, forcing developers to learn about them by reading the C/Objective-C headers. So if you don't know C or Objective-C....
What intro documents are those exactly?
The conceptual docs for pretty much every technology area, for starters. You can say all you want to that the language doesn't matter in conceptual docs, but IMO, that's not the case if you truly don't know any Objective-C, particularly for technology areas that are particularly complex (networking, security, etc.).
In two or three years, assuming Apple doesn't drop Swift like they did their last three or four scripting language bridges
And I'll leave you with that dangling statement for the ages... *facepalm*
I'm not saying I expect Apple to drop Swift, but you have to admit that Apple has a long history of coming up with what seems like revolutionary improvements in technology, and then dropping them a couple of years later—Objective-C Garbage Collection, for example. For that reason, I'm being very cautious when it comes to Swift adoption. I'll play with it, but I won't be using it for any nontrivial code until I'm sure it is going to stick.
There's going to be tons of Cocoa stuff to mess with. You're basically using all the Cocoa classes, just with a bunch of extra wrapper code, in a language that's slower than Objective-C, for little real benefit beyond syntactic sugar.
Worse, as things stand right now, if you start out using Swift, you're going to quickly start running into walls where the introductory documentation you need just doesn't exist yet. And when you get into trouble, you're going to go searching for code snippets on Stack Overflow and using Google, and approximately 100% of those snippets are going to be in Objective-C, not Swift, which means you'll have to know enough Objective-C to translate those snippets into Swift. In other words, if you don't already know Objective-C, learning Swift requires a fair degree of masochism right now.
So no, new developers to the platform should definitely start by learning Objective-C, and should reevaluate that decision after they have gotten comfortable with Objective-C. In two or three years, assuming Apple doesn't drop Swift like they did their last three or four scripting language bridges, there should be enough Swift documentation and code snippets to support developers who are just starting out, and companies will be just starting to hire a non-negligible number of Swift developers for serious work. Learn Swift then.
None of what you're talking about has the slightest bearing on what we're talking about. I fully agree that screwing your customer to extort money out of Netflix (or whoever) is bad. What I'm saying is that if you're on a capped connection—capped in terms of total data quantity, not instantaneous speed—there's no neutrality violation involved if Netflix agrees to pay your ISP so that their usage doesn't count towards your cap. That's not a double dip. It is quite literally exactly the same as calling a toll-free number; you pay your ISP for service, plus you pay for your use, but the company on the other end chooses to pay for your use instead.
What would be a violation is if the ISP demands that Netflix do so, or else they won't provide the instantaneous bandwidth required for a satisfactory customer experience. Similarly, if an ISP charges extortionate overage fees for going beyond your data cap, rather than something reasonable and proportional, that's a potential net neutrality violation in that it essentially forces Netflix to become a toll-free service to avoid screwing over their customers.
It does violate net neutrality, because it affects the cost of delivery of data to and from the end user.
But it doesn't. The cost is still the same, regardless of who is paying it. What it does is shift the burden, at the request of one of the parties. That's not the same as shifting the burden at the request of someone who isn't a party to the communication (your ISP). And changing the cost of the communication isn't really any different from changing the cost of the content. If Apple (for example) chooses to pay your bandwidth bill for downloading a movie, they could lower the cost of the movie by a few bucks and it would have exactly the same effect on the customer in practice. In fact, they would probably be better served by lowering the price, because customers see the price of the movie, and probably pay for their bandwidth bill using auto-debit.:-)
Either way, the TCP/IP equivalent of toll-free calling certainly isn't in the same category of wrongness as your ISP limiting the rate of traffic in a way that makes your communication impossible or impractical, and the reason most of us want net neutrality is to prevent that sort of abuse, not to prevent any slight distortion of pricing.
If every other website on the Internet besides Netflix and Amazon pays a fee to be included in that "premium" quota, then yes, it is consistent with Net Neutrality. It is also about as likely as Santa Claus getting the Tooth Fairy pregnant.
No - they want all internet connections to be paid for according to last-hop bandwidth to their endpoint and to
work according to the standardized protocols of the internet when sending/recieving data to other destinations from that link,
and for any other business related decisions concerning traffic to occur according to those same principles
Which is precisely the same thing as saying that traffic priority should not be dependent upon endpoint—i.e. that all destinations are treated equally—but with about forty-two extra words.
Firstly it's not about content delivery companies at all. It's about network operators, and network link pricing. Period.
Network operators are a pipe to content providers, so any definition of net neutrality that ignores the content providers is fundamentally missing the whole point of the network. The purpose of net neutrality is to ensure that your link provider cannot artificially distort traffic in a way that makes it impractical to use arbitrary services, forcing you to the services of their choosing. Manipulating network link pricing is just one mechanism for distorting traffic, and is quite possibly the least interesting, least effective way to do so.
And yes, when 'the tools at their disposal' include bandwidth tiering (free vs non-free) in an effort to distort end
user preferences towards their internet-based service, and thereby shift the fundamental usage of the
internet itself (away from free, open standards p2p protocols and towards proprietary 'walled-garden' services), this is, in fact,
not a neutral practice, and is in fact a problem.
Your argument is illogical. There is no difference between a content provider paying for the user's data usage and lowering the price of the content provider's service by enough money that the user can pay for a connection with a higher data cap on his or her own. Thus, paying for the user's usage does not violate any fundamentally sound concept of net neutrality in any meaningful way. Admittedly, in the case of Wikipedia, they're taking it one step farther and charging a negative fee for their service, which is a little odd, but if that's the way they want to spend their donations, so be it.
Now taken to the extreme—unusably low data caps combined with provider-paid exceptions—could potentially be a net neutrality issue, if only because it would be harmful to free content providers. However, that scenario is pretty darn unlikely. There are too many dozens of free, moderately high-traffic content providers for that to happen in the foreseeable future. If that changes—if all the world's websites consolidated themselves into just a handful of server farms—then it would make sense to reevaluate things. Unless and until that happens, however, it makes little sense to create laws in an attempt to prevent problems that are purely hypothetical. Doing so adds extra regulatory burden without solving actual problems, and worse, gives businesses more time to look for ways around those regulations, ensuring that by the time they are actually needed, they don't work.
And more importantly, none of the proposed solutions for net neutrality that I've seen would prevent this sort of "collect calling" anyway.
The thing is, every company could do those things if they want to. Individuals could do so if they wanted to. It's no different than having a 1-800 number. You pay so that the person calling you doesn't. There's no neutrality violation there; if anything, it improves net neutrality by providing a reasonably priced mechanism for allowing other companies to be on equal footing with Comcast, who almost certainly does not charge their customers for the use of their own, in-house video-on-demand service. You might reasonably argue, however, that it does so only if the cost of said toll-free service is regulated.
Slashdot Mirror
Other than a handful of obvious edge cases (the worst of which were fixed with fast enumeration and string and number constants), I'd argue that it mostly isn't Objective-C that is too verbose, but rather the Cocoa APIs themselves. And you'll be using those same ginormous scrubtheKitchenSink:withBrilloPad:andCleanser:byHand:usingExcessiveForce: methods in Swift, just with slightly different punctuation....
Want to get that law changed really quickly? Find yourself a prosecutor who grew up poor. Get that person to press charges against the power company for cutting off people's power when they fail to pay their bills, because doing so forces people to choose between committing a crime and leaving the area, which potentially constitutes election tampering. :-)
Just the ones that didn't get eaten by the Morlocks and the Reavers.
And by run backwards, I mean as perceived by an outside observer, i.e. that you would arrive before you left.
I suspect that the solution, assuming FTL travel is possible, is to ignore the time dilation problem. Time dilation occurs at speeds less than c, but IIRC, at least one theory posits that the effects of relativity are backwards for speeds greater than c, so if you traveled at something approaching infinite speed, there's some magic point at which no time dilation would occur, I think. Either that or time would run backwards. I'm not sure which. Either way, the net effect would be the same. :-)
Not a lot, actually. The most important aspect of real security is compartmentalization—ensuring that you don't have any high-value individual targets:
None of those things should cost significant amounts of money. They're just simple policy decisions. And with a scheme like the above, you typically wouldn't see attacks like this being successful in the absence of a massive zero-day remote kernel exploit.
If you want added security, you could write a piece of software in a few minutes that logs all traffic by IP address and port, then compares it with traffic requested by the user's web browser (by continuously reading the browser's history and uploading any new locations every couple of minutes), and flags anything that doesn't match. Automatically ignore any automatic updates by software that your IT department installed, plus any known addresses owned by your OS manufacturer. If you see any other traffic, shut off the port immediately, and contact the user to verify that the traffic is expected. If so, whitelist that IP and port after verifying that the software the user is running is legit.
Finally, add mail server rules that sanity check any email attachments, and similar rules for your HTTP proxy. If someone receives a disk image, ZIP archive, or other archive, extract the contents and ensure that there are no executables within it. If there are, allow the attachment if the executable is signed by a trusted authority. Otherwise, store a copy of the attachment in a secure location, and either filter it from the mail archive or refuse to send the final packet of data to the web browser. Flag it for review.
Like the two guys running away from the grizzly bear, security doesn't have to be flawless; it just has to be robust enough to convince the attacker to go after an easier target.
They're engaged in competition with avians? Neat. I'd pay to see that.
Just make it high enough that the planes can go under it. :-D
You joke, but IMO, they are largely responsible—a lot more so than ISPs who merely failed to prevent the normal use of their networks by people doing nefarious things. After all, these movies were stolen off of the movie studios' machines, which means they clearly didn't take security seriously enough.
Just to clarify, there are a few spots that are considerably higher than that—particularly indoors near the reactor, and outdoors downwind from the reactor. Those areas are clearly still unsafe. But a fair percentage of the abandoned areas could potentially be resettled, in theory.
Assuming they cleared the top few inches of soil in those farm areas and replaced it with soil from elsewhere, and assuming that they use well water rather than surface water, I'd expect the extra risk from eating local produce to be negligible. If they didn't do those things, then yeah, I'd be a bit concerned.
To be pedantic, that's subtly inaccurate. In English if we say something negative "to the person", we're talking about a face-to-face conversation, whereas an ad hominem attack need not be a conversation at all. A better translation would be "towards the person" or "at the person". In fact our word "at" comes from the Latin word "ad".
Back on topic, yes, Chernobyl is still dangerous, but probably not that dangerous unless you eat or breathe the dirt. From what I've read, some of the most contaminated objects (300 microsieverts per hour) will give you a year's background radiation in half a day, which is about 30 times the level you'd get flying on an airplane. But for the most part, it's about an order of magnitude less than that.
Yeah, that's what I get for taking a number from skimming the first Google hit. :-)
Except you don't. For one thing, at 85 MPH, the total stopping distance is only about 532 feet. You forgot to factor in the fact that your speed isn't 85 MPH for that entire 7.8 seconds. :-) For another, you don't have to stop. You just have to get slow enough to either avoid hitting the animal or scare the animal out of the lane. And even if you were unable to avoid it, and even if you only had half the stopping distance, the difference between hitting it at 45 MPH and 85 MPH makes a huge difference in terms of how much damage you take. :-)
That seems like a good reason to keep vegetation clear of the highways. You'll never mistake a nonexistent bush for a cow. I've never seen a 65 MPH (or faster) road without at least a twenty or thirty foot exclusion zone on both sides of the road. Most normal cows can run at about five or six miles per hour—about the speed of a person walking fast. So in the worst case, it will take about four seconds for the animal to get out onto the road. So at a maximum run, the cow will get there about a half second before you're fully stopped. You might hit it, but you'll hit it at maybe 15–20 MPH.
Now moose are a different story....
Or if the vehicle has additional gears to give you a higher gear ratio at higher speeds.
Yup. And if you introduce systemic biases (quotas, lowered entrance requirements, etc.) to encourage girls to do something, then invariably some of those girls will be less qualified than the boys who get excluded. When the boys notice this (and they will), then they'll start to assume that all girls are less qualified. And thanks to confirmation bias, this perception will tend to strengthen over time, because they'll always notice the underqualified women and won't notice the qualified women. Thus, in the long run, using reverse biasing to counter discrimination almost invariably leads to more discrimination, not less.
And although it is unclear whether contests that are strictly for women will have the same effect, at a minimum, they'll cause envy, which is almost certainly not an effective way to encourage men to take women in STEM more seriously.
You can't fix discrimination with more discrimination. The only way to fix discrimination is with marketing—by hyping the heck out of members of underrepresented groups who are good at what they do, so that they'll serve as examples for other people in those underrepresented groups, and will encourage them to work harder to overcome the discrimination and take jobs in particular fields. This approach is also the only way to counteract the confirmation bias that is the source of nearly all discrimination—by repeatedly showing examples that contradict the biased expectations, and by showing those counterexamples far more often than they see confirmatory examples.
For example, if you want to get more girls into a contest like this, when you advertise the contest, use mostly pictures of girls. Don't change the rules; don't change the requirements; change the image you project. Unlike every other strategy, this works, and has been repeatedly proven to work through decades of advertising research.
It has reference documentation. It has no sample code, and no conceptual docs.
99% of which still fall into the "trivial examples" category. The AlamoFire is a little bit more complex, but still doesn't come close to demonstrating all of its capabilities.
Fair enough. I thought GC was a mistake from the very beginning, personally. Either way, IIRC, lots of people initially touted it as the solution to the complexity of retain-release schemes.
Apple's Java implementation and WebObjects both come to mind, though both predate iOS. And Apple developed and dropped bridges for Ruby, Python and Java. And the Message framework (NSMailDelivery), Instant Message framework, and QTKit framework were also fairly short-lived, IIRC, or at least they seemed that way.
For most Objective-C classes, that's true, but I was under the impression that Swift's array and dictionary support consists of wrapper code around NSArray/NSDictionary; I'm not certain of that, though.
Operator overloading is, IMO, almost inherently a mistake. And tuples are pure syntactic sugar. Anything you can do with tuples can typically be done without tuples in just a couple more lines of code.
The entire networking stack has no Swift documentation except for a very trivial NSURLSession example. And last I checked, large chunks of WebKit (which may or may not be available on iOS) and Accelerate were still undocumented, forcing developers to learn about them by reading the C/Objective-C headers. So if you don't know C or Objective-C....
The conceptual docs for pretty much every technology area, for starters. You can say all you want to that the language doesn't matter in conceptual docs, but IMO, that's not the case if you truly don't know any Objective-C, particularly for technology areas that are particularly complex (networking, security, etc.).
I'm not saying I expect Apple to drop Swift, but you have to admit that Apple has a long history of coming up with what seems like revolutionary improvements in technology, and then dropping them a couple of years later—Objective-C Garbage Collection, for example. For that reason, I'm being very cautious when it comes to Swift adoption. I'll play with it, but I won't be using it for any nontrivial code until I'm sure it is going to stick.
Only the API reference documentation, not the conceptual docs, the sample code, etc.
There's going to be tons of Cocoa stuff to mess with. You're basically using all the Cocoa classes, just with a bunch of extra wrapper code, in a language that's slower than Objective-C, for little real benefit beyond syntactic sugar.
Worse, as things stand right now, if you start out using Swift, you're going to quickly start running into walls where the introductory documentation you need just doesn't exist yet. And when you get into trouble, you're going to go searching for code snippets on Stack Overflow and using Google, and approximately 100% of those snippets are going to be in Objective-C, not Swift, which means you'll have to know enough Objective-C to translate those snippets into Swift. In other words, if you don't already know Objective-C, learning Swift requires a fair degree of masochism right now.
So no, new developers to the platform should definitely start by learning Objective-C, and should reevaluate that decision after they have gotten comfortable with Objective-C. In two or three years, assuming Apple doesn't drop Swift like they did their last three or four scripting language bridges, there should be enough Swift documentation and code snippets to support developers who are just starting out, and companies will be just starting to hire a non-negligible number of Swift developers for serious work. Learn Swift then.
None of what you're talking about has the slightest bearing on what we're talking about. I fully agree that screwing your customer to extort money out of Netflix (or whoever) is bad. What I'm saying is that if you're on a capped connection—capped in terms of total data quantity, not instantaneous speed—there's no neutrality violation involved if Netflix agrees to pay your ISP so that their usage doesn't count towards your cap. That's not a double dip. It is quite literally exactly the same as calling a toll-free number; you pay your ISP for service, plus you pay for your use, but the company on the other end chooses to pay for your use instead.
What would be a violation is if the ISP demands that Netflix do so, or else they won't provide the instantaneous bandwidth required for a satisfactory customer experience. Similarly, if an ISP charges extortionate overage fees for going beyond your data cap, rather than something reasonable and proportional, that's a potential net neutrality violation in that it essentially forces Netflix to become a toll-free service to avoid screwing over their customers.
But it doesn't. The cost is still the same, regardless of who is paying it. What it does is shift the burden, at the request of one of the parties. That's not the same as shifting the burden at the request of someone who isn't a party to the communication (your ISP). And changing the cost of the communication isn't really any different from changing the cost of the content. If Apple (for example) chooses to pay your bandwidth bill for downloading a movie, they could lower the cost of the movie by a few bucks and it would have exactly the same effect on the customer in practice. In fact, they would probably be better served by lowering the price, because customers see the price of the movie, and probably pay for their bandwidth bill using auto-debit. :-)
Either way, the TCP/IP equivalent of toll-free calling certainly isn't in the same category of wrongness as your ISP limiting the rate of traffic in a way that makes your communication impossible or impractical, and the reason most of us want net neutrality is to prevent that sort of abuse, not to prevent any slight distortion of pricing.
If every other website on the Internet besides Netflix and Amazon pays a fee to be included in that "premium" quota, then yes, it is consistent with Net Neutrality. It is also about as likely as Santa Claus getting the Tooth Fairy pregnant.
Which is precisely the same thing as saying that traffic priority should not be dependent upon endpoint—i.e. that all destinations are treated equally—but with about forty-two extra words.
Network operators are a pipe to content providers, so any definition of net neutrality that ignores the content providers is fundamentally missing the whole point of the network. The purpose of net neutrality is to ensure that your link provider cannot artificially distort traffic in a way that makes it impractical to use arbitrary services, forcing you to the services of their choosing. Manipulating network link pricing is just one mechanism for distorting traffic, and is quite possibly the least interesting, least effective way to do so.
Your argument is illogical. There is no difference between a content provider paying for the user's data usage and lowering the price of the content provider's service by enough money that the user can pay for a connection with a higher data cap on his or her own. Thus, paying for the user's usage does not violate any fundamentally sound concept of net neutrality in any meaningful way. Admittedly, in the case of Wikipedia, they're taking it one step farther and charging a negative fee for their service, which is a little odd, but if that's the way they want to spend their donations, so be it.
Now taken to the extreme—unusably low data caps combined with provider-paid exceptions—could potentially be a net neutrality issue, if only because it would be harmful to free content providers. However, that scenario is pretty darn unlikely. There are too many dozens of free, moderately high-traffic content providers for that to happen in the foreseeable future. If that changes—if all the world's websites consolidated themselves into just a handful of server farms—then it would make sense to reevaluate things. Unless and until that happens, however, it makes little sense to create laws in an attempt to prevent problems that are purely hypothetical. Doing so adds extra regulatory burden without solving actual problems, and worse, gives businesses more time to look for ways around those regulations, ensuring that by the time they are actually needed, they don't work.
And more importantly, none of the proposed solutions for net neutrality that I've seen would prevent this sort of "collect calling" anyway.
The thing is, every company could do those things if they want to. Individuals could do so if they wanted to. It's no different than having a 1-800 number. You pay so that the person calling you doesn't. There's no neutrality violation there; if anything, it improves net neutrality by providing a reasonably priced mechanism for allowing other companies to be on equal footing with Comcast, who almost certainly does not charge their customers for the use of their own, in-house video-on-demand service. You might reasonably argue, however, that it does so only if the cost of said toll-free service is regulated.