> In what freezing fucking hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved?
Sounds to me like you've never developed seriously on an ARM chipset. These devices are worlds apart from your standard desktop, there is a reason that both Android and IOS dropped Adobe flash. It's partly the hardware and partly shitty ARM code, its not really much to do with the specs. I can do things much more easily on an underpowered x86 than an overpowered ARM.
> Sounds to me like you've never developed seriously on an ARM chipset.
You're selling cucumbers to the gardener, I was actually one career choice away from designing chips, and wrote ARM assembly before there was anything such as a tablet.
A mobile phone is slow in comparison to a desktop, but not slow enough to afford an excuse for lagging in most of today's mobile applications. If a Facebook client, a mail application, a simple 2D game or a music player lags on such a mobile phone, it does so because it's a piece of crap.
> If a Facebook client, a mail application, a simple 2D game or a music player lags on such a mobile phone, it does so because it's a piece of crap.
Fair point. It has more to do with the way these apps are cobbled together out of heterogeneous chunks of code, just to make them look "cool". The native frameworks are lacking in terms of their ability to easily customize the controls, so people start applying crazy hacks just to mimic some functionality seen in another app, without any regard for the performance. It just has to "work".
That's my understanding, too. Developers are using high-level frameworks that generate an absurd number of redraws. In many cases, the bottleneck isn't even the CPU or the memory, but simply pushing too many pixels to the screen. It doesn't help that we expect much snappier response from touch interfaces than from 10-year-old desktops. Two seconds to open a new screen was somewhat acceptable in a VB6 application. Try to do that in an Android app, and see the kind of rating you get.
I don't think that's a fair assessment. The challenge is that developing for mobile is nowhere near _as_ _easy_ as desktop. So we have a legion of desktop devs coming over to mobile and getting lost, their code doesn't "suck" its fine for desktop its just not good mobile code.
Also, power management.
> their code doesn't "suck" its fine for desktop its just not good mobile code
IMHO, code that is not adequate for a platform on which it is intentionally deployed, by definition, sucks. There's no such thing as good application that is fine for any computer except those it is ran on.
As a person who used an LG "smart"phone that couldn't handle the bare Android OS without lagging (and turning on Wi-Fi would freeze it to death), I agree wholeheartedly. Intentionally selling crap that doesn't work is evil in my book.
The original iPhone, back when these decisions were made to not support flash, used an arm 1176 processor underclocked at 412MHz. That was a single-issue, in-order core without SIMD. Consider the Cortex-A15 and the latest Qualcomm parts; they're at least three-wide fully out-of-order cores supporting 128b SIMD operation with fused multiply-add, clocked at 1.5-2GHz in two- and four-core configurations. They are far more similar to a low-voltage Core2 package than they are to the armv6 processors of the first iPhone and Android devices (and in some ways they’re actually nicer to program for), and would easily be capable of handling a flash runtime.
I just think adobe didn't really work to optimize flash for this processor in particular. Flash is a complex piece of software, and it's not properly made.
I think modern Android and iOS devices could do that just as well.
I believe not supporting Flash has more to do with Apple/Google strategies (i.e. not depending on propietary third party software) than actual hardware limitations.
Yep. Who wants to make bad ports easier? Their goal is to keep their users hooked, and people are cheap (or stupid if you prefer) and approach value from the wrong direction, money spent instead of value gained.
Even on the slow (by smartphone standards) Nexus One, Flash ran quite decently. The Nexus 5 is a good magnitude faster in every way (I can't find specific parity-version benchmarks, so perhaps I'll fire both of them up and give it a go), moreso in some ways like the GPU, and is as powerful as some desktops that people still use in business settings. It would of course have no problem with Flash.
Flash failed because a good percentage of existing content relied upon the accouterments of a desktop, namely the keyboard and the mouse. Minus these it just made for a frustrating experience for a lot of users. Add the fact that sites were loaded with obnoxious, taxing Flash ads, and it just gave users of Flash-enabled devices a very negative experience. It also reflected poorly on the product as a number of popular tech sites compared Android and iOS web page loading times, the former seriously hindered by the loading and overhead of Flash.
There were later changes to make it activate on click, but that just made it even more of a usability burden.
In a way, at the time this whole debate was raging, iOS users got to enjoy essentially a free "adblock" in the absence of Flash.
I have to entirely disagree with any notion that smartphones are underpowered: I am currently working on a very intense real-time image processing system and with each iteration I'm finding that I'm increasing the scope and featureset because the performance continually blows me away. Even when I work on "older" devices like the Galaxy S3, with good code and good parallelization (incl. the GPU), it is just a ridiculous platform.
Sounds to me like you've never developed seriously on an ARM chipset. These devices are worlds apart from your standard desktop, there is a reason that both Android and IOS dropped Adobe flash. It's partly the hardware and partly shitty ARM code, its not really much to do with the specs. I can do things much more easily on an underpowered x86 than an overpowered ARM.