Ron Amadeo (via Nick Heer):
Looking back, Android’s existence has been a blur. It’s now a historically big operating system. Almost a billion total devices have been sold, and 1.5 million devices are activated per day—but how did Google get here? With this level of scale and success, you would think there would be tons of coverage of Android’s rise from zero to hero. However, there just isn’t. Android wasn’t very popular in the early days, and until Android 4.0, screenshots could only be taken with the developer kit. These two factors mean you aren’t going to find a lot of images or information out there about the early versions of Android.
The problem now with the lack of early coverage is that early versions of Android are dying. While something like Windows 1.0 will be around forever—just grab an old computer and install it—Android could be considered the first cloud-based operating system. Many features are heavily reliant on Google’s servers to function. With fewer and fewer people using old versions of Android, those servers are being shut down. And when a cloud-reliant app has its server support shut off, it will never work again—the app crashes and displays a blank screen, or it just refuses to start.
Android History
David Owens II has some criticisms along this line that differ from those I mentioned before (via Christoffer Lernö):
Gone is the dynamic nature of ObjC; it has instead been replaced by a rigid, generic based type system. I know the world of C++, Java, and C# programmers have rejoiced. Myself, having worked in Visual Studio building tools for .NET and Windows developers for many years and leaving that for the world of Cocoa and ObjC, I am greatly saddened by this turn of events.
I do not think we got “ObjC without the C”, rather, we got something much more like C# that compiles on clang and bridges into Cocoa a bit haphazardly.
[…]
Yes, generics can be useful in particular cases. However, they are not helpful, ironically, in the generic use case. I would argue that simply sticking with a stronger-type base instead of fully type-safe and generic based language would have been a more pragmatic route to take.
[…]
I have to wonder, what is the pragmatic goal of Swift? From where I sit, it gets all of the defaults wrong because the defaults should have been about the interaction with the Cocoa API. Until there are native Swift versions of those, all of code looks and feels much messier and far less elegant than what we have today.
Christoffer Lernö:
I realize that it’s a vain hope that this bug report will be anything than summarily dismissed, but I feel I have to make the attempt nonetheless.
[…]
My conclusion is that dynamic dispatch must be a first class citizen in order to make Swift suitable for UI programming. Also, the generics must be much simplified and permissive in order to not obstruct and complicate the day-to-day programming work.
Update (2014-06-17): See more about the JSON example and also Edge Cases on Swift and C++ culture.
Update (2014-06-22): David Owens II has a further update on the JSON example.
Blocks Language Design Message Passing Objective-C Programming Swift Programming Language
