> Most people use their phone as...surprise surprise, a phone.
Yeah. Back in the day. Or in rural Nebraska.
Nowadays, smartphones are used for tons of things besides calling. I'd even go as far as to say that actual call time is far less than other-use time. Else we wouldn't have TONS of web traffic originating from mobile phones and 300,000 apps in the App Store.
> Speed is irrelevant to the majority of users I know
Are those the same "most users" that use their smartphone "as a phone"?
For those people even a smartphone is irrelevant. They can get by with some dumb device.
Now, speed is irrelevant as a goal in itself. But a faster CPU enables more powerful apps. Without that irrelevant "speed", we wouldn't have the ability to handle 8 megapixel images properly, or edit movies in iMovie mobile to name a few examples. And for 3D games, more speed is better.
> Further, I'd challenge you to name one non-game app that would be massively improved by a faster chipset over what is currently available on iPhone 4 devices. Just ONE.
Just one?
1) Any music app (like Fruity Loops, Beatmaker, Massive, etc) would be able to either play more samples / synthesize more voices = improved polyphony, or synthesize better voices = better sound quality.
2) Any video encoding/editing app, such as iMovie mobile will be massively improved in what it can do.
3) Any drawing app, like Brushes. Most use complicated code to render realistic brush responses and lag when live-painting.
4) Any app written with an "interpreted" layer, from Adobe's flash transcompiled apps to Mono Touch will feel more native. Also, MacRuby will be eligible for iOS apps soon, as the GC problem is solved, and it will greatly benefit from a faster CPU.
Oh, and a faster CPU also does stuff in less time, so if the power requirements per instruction are the same as the previous CPU (which often happens with next generation CPUs), a faster CPU means better battery life.
Basically what you're saying is: "640K should be enough for everybody".
> MacRuby will be eligible for iOS apps soon, as the GC problem is solved
If I didn't miss any recent developments, that was a misunderstanding from when ARC was leaked as iOS5 having "GC", then it turned out that it was actually compiler-supported reference counting. Which means that MacRuby is still stuck on iOS and doomed on OS X, with some people expecting the GC to be deprecated sooner or later.
With the current App Store rules, I don't see why Matz' C Ruby with 'dl' disabled wouldn't be eligible.
uhm.... I'm in rural ND and most people under 30 don't use their phone to talk. Text and Facebook seem to be the main phone uses. It is my understanding that due to the cost of voice, most people in Africa use SMS and not voice.
Yeah. Back in the day. Or in rural Nebraska.
Nowadays, smartphones are used for tons of things besides calling. I'd even go as far as to say that actual call time is far less than other-use time. Else we wouldn't have TONS of web traffic originating from mobile phones and 300,000 apps in the App Store.
> Speed is irrelevant to the majority of users I know
Are those the same "most users" that use their smartphone "as a phone"?
For those people even a smartphone is irrelevant. They can get by with some dumb device.
Now, speed is irrelevant as a goal in itself. But a faster CPU enables more powerful apps. Without that irrelevant "speed", we wouldn't have the ability to handle 8 megapixel images properly, or edit movies in iMovie mobile to name a few examples. And for 3D games, more speed is better.
> Further, I'd challenge you to name one non-game app that would be massively improved by a faster chipset over what is currently available on iPhone 4 devices. Just ONE.
Just one?
1) Any music app (like Fruity Loops, Beatmaker, Massive, etc) would be able to either play more samples / synthesize more voices = improved polyphony, or synthesize better voices = better sound quality.
2) Any video encoding/editing app, such as iMovie mobile will be massively improved in what it can do.
3) Any drawing app, like Brushes. Most use complicated code to render realistic brush responses and lag when live-painting.
4) Any app written with an "interpreted" layer, from Adobe's flash transcompiled apps to Mono Touch will feel more native. Also, MacRuby will be eligible for iOS apps soon, as the GC problem is solved, and it will greatly benefit from a faster CPU.
Oh, and a faster CPU also does stuff in less time, so if the power requirements per instruction are the same as the previous CPU (which often happens with next generation CPUs), a faster CPU means better battery life.
Basically what you're saying is: "640K should be enough for everybody".