How is the objective-c compiled and ran on Dalvik? Are you doing: objective-c -> LLVM -> dalvik bytecode?
It isn't. It runs natively via the NDK.
Or just the better alternative. It is hard to seriously argue that Boeing is so much behind Elon Musk, that anything space related should be given to the latter.
Given that Boeing will already be 3 years late to the party, when SpaceX has manned capability up and running this coming January? We're supposed to wait another couple of years for manned launch capability, when the Russians have already said they wouldn't be hailing our asses into orbit any more? I don't think "Time To Market" is a difficult argument.
One thing Swift will address... There are currently 3 memory management models in use in Objective-C, and for some of those models, you don't get a retain count automatically (for example, this is the case for a number of collection objects when doing an insertion).
Swift has the opportunity to rationalize this, which is not something you could do with the Objective-C libraries themselves, since doing so would change historical APIs and thus break old code.
It wasn't really until Metrowerks basically became incompatible with the Intel switchover and the 64 bit support had to drop certain types of support from Finder due to 64 bit inode numbers, and while I happily would have made them new header files so that they would have continued to work with the UNIX Conformance work, where Ed Moy and I basically broke their local private copies of their header files, since Motorola sold off the Intel version of the Metrowerks C the week because Apple announced Intel, it was pretty much DOA at that point.
So it basically took an Act Of God to get some people to get the hell off some of the old APIs we had been dooming and glooming about for half a decade.
Swift is another opportunity for that type of intentional non-exposure obsolescence to clean up the crappy parts of the APIs and language bindings that haven't been cleaned up previously due to people hanging onto them with their cold, dead hands. Hopefully, they will advantage themselves of this opportunity.
I maintain the GNUstep / Clang Objective-C stack. Most people who use it now do so in Android applications. A lot of popular apps have a core in Objective-C with the Foundation framework (sometimes they use GNUstep's on Android, more often they'll use one of the proprietary versions that includes code from libFoundation, GNUstep and Cocotron, but they almost all use clang and the GNUstep Objective-C runtime). Amusingly, there are actually more devices deployed with my Objective-C stack than Apple's. The advantage for developers is that their core logic is portable everywhere, but the GUIs can be in Objective-C with UIKit on iOS or Java on Android (or, commonly for games, GLES with a little tiny bit of platform-specific setup code). I suspect that one of the big reasons why the app situation on Windows Phone sucks is that you can't do this with a Windows port.
It would be great for these people to have an open source Swift that integrated cleanly with open source Objective-C stacks. Let's not forget that that's exactly what Swift is: a higher-level language designed for dealing with Objective-C libraries (not specifically Apple libraries).
Objective-C is a good language for mid-1990s development. Swift looks like a nice language for early 2000s development. Hopefully someone will come up with a good language for late 2010s development soon...
It wasn't just about interface. People tend to forget how search engines did an absolutely horrible job of intelligently ranking the sites you wanted to see.
I find it pretty easy to remember - I go to Google today.
The UI was what made me switch both to Google originally and from it some years later. When I started using Google - and when Google started gaining significant market share - most users were on 56Kb/s or slower modem connections. AltaVista was the market leader and they'd put so much crap in their front page that it took 30 seconds to load (and then another 20 or so to show the results). Google loaded in 2-3 seconds. The AltaVista search results had to be a lot better to be faster. I switched away when they made the up and down arrow keys in their search box behave differently to every other text field in the system.
There's a lot more to government than military intelligence gathering and law enforcement (although it would be a good idea for someone to remind most current governments that those are two things, not one). And most government projects end up spending insane budgets. This isn't limited to the US. It amazes me how often government projects to build databases to store a few million records with a few tens to thousands of queries per second (i.e. the kind of workload that you could run with off-the-shelf software on a relatively low-spec server) end up costing millions. Even with someone designing a pretty web-based GUI, people paid to manually enter all of the data from existing paper records, and 10 years of off-site redundancy, I often can't see where the money could have gone. Large companies often manage to do the same sort of thing.
The one thing that the US does well in terms of tech spending is mandate that the big company that wins the project should subcontract a certain percentage to small businesses. A lot of tech startups have got their big breaks from this rule.
A "Carrington-level" event nowadays would most likely be much less disruptive, as back then all the early radio and spark gap stuff was well under 50 MHz, which is where almost all of the natural noise winds up in the spectrum. Ever notice, for example you can hear your shaver motor on an AM radio but not an FM one. This is not due to AM vs. FM, (well, it is a little) but mostly due to the fact that AM is about 1 MHz and FM is about 100 MHz, well above the "static line" around 50 MHz.
It would take a much stronger signal than back then to cause the same level of disruption. Not saying that can't happen, but modern radio communications are quite a bit more robust than they were back over 100 years ago.
The real problem for Firefox is not the interface changes that people like you whine about, it's mobile. Now 30% of traffic is mobile and Firefox doesn't have an app for any Apple mobile devices and is effectively excluded from Android by Google's Microsoft-like illegal anti-competitive licensing deals with manufacturers (you can get the app, but it's not preloaded and only a few geeks ever would).
Huh? It's in the Google Play Market and is no harder to install than any other app. Once it's installed, the first time you click on a link from another app you're asked to choose the app that will handle links. I fall into the geek category (and so installed it from F-Droid, not Google Play), but found it trivial to switch to Firefox on the mobile. I mostly did because Chrome has spectacularly bad cookie management and I'd been trying to find a browser that did it better. Early Firefox ports were as bad, but now it's quite nice and with the Self Destructing Cookies add-on does exactly what I want.
The mobile is actually the only place I use Firefox...