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.

There is no "wrapper code".

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.

Also ALL of Apple's documents currently present side by side the ObjC and Swift API.

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.

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.

They want all destinations to be equal

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.

Yeah, but nobody talking about net neutrality wants all packets to be equal. They want all destinations to be equal, i.e. they want traffic from Netflix to have roughly the same likelihood of reaching its destination as traffic from the cable company's VOD service.

Subsidizing traffic doesn't violate net neutrality, because it doesn't affect the delivery of data, only the cost to the end user. Even if the Internet were regulated in precisely the same way as telephone, subsidized traffic would still be allowed, because it is fundamentally no different than a 1-800 number or a collect call.

So using that as an excuse to argue against net neutrality represents a very fundamental misunderstanding about what net neutrality is about. It isn't about preventing content delivery companies from using the tools at their disposal to deliver content better and faster; it's primarily about preventing content delivery companies who also own last-mile infrastructure from having an unfair competitive advantage over content delivery companies that don't.

Tapes aren't really archival, either, unless you have several copies. I've done batch recapture off of DV after a few years, and swore when I found serious dropouts. That's relatively low density data compared with LTO (though admittedly with less redundancy and error correction). After that, I dug around and found a copy of the captured files on some old hard drives, which unlike the tape, were intact.

So basically, from what I've seen, nothing is truly archival unless you have multiple copies, and if you have multiple copies, just about everything is archival, so the difference between tape and hard drives is that tape drives require a large up-front investment in a drive in exchange for cheaper per-TB costs for the media and higher physical density (because you don't have redundant electronics going along for the ride). If the per-TB costs aren't less and the density isn't higher, then tape offers no real advantage over spinning disks, IMO, unless your data storage needs are so massive that you have automatic libraries, and even then, only if you can't find a company willing to build a hard-disk-based librarian robot.

At various times, it has been professional, and might be again sporadically, but mostly it's serious hobby.

For home users, it is not a useful identifier because it usually changes regularly. For government users and business users, it is a fairly robust identifier, because most of those folks have static IPs (or at least fixed IPs assigned by a DHCP server).

Of course, there's not a 1:1 mapping between user and IP. So it would be more accurate to describe it as familially identifying information.

I'd rather not have an ultra-competent authoritarian as President, regardless of party. That's the absolute last thing this country needs.