4 ms·

My biggest "issue" with this generally rather decent article is that CPU-bound applications are rare. For the plethora of social, productivity and novelty apps

by mhd 13y ago

My biggest "issue" with this generally rather decent article is that CPU-bound applications are rare. For the plethora of social, productivity and novelty apps it doesn't matter at all. Optimizing the graphical stack certainly matters, but that's mostly an infrastructure issue, i.e. already dependent on the native parts of the OS/framework. And consider who actually might be asking themselves this very question, native or webapp: The very same social/productivity/novelty websites and services who are looking how to best present their product on a mobile platform. And I'd wager a guess that sheer performance often isn't the deciding factor here , it's mostly about the native look. (And even seems to get less important, although I wonder whether iOS 7 could rekindle that) And that whole talk about GCs sound awefully familiar. Didn't we have the very same conversation in the mid-90s when Java came out? Also there's the good old alternating hard and soft layers. Hybrid webapps (with some native compoents to speed up and slim down things) could easily bridge the gap until the browser standards/APIs/hardware catches up. It's really not an all or nothing question, especially considering how many Android/iOS apps are basically WebViews with a tiny veneer of native buttons, preferences and background storage. Not that I like the web platform all that well, but let's be serious about the "depth" of web apps...

hcarvalhoalves 13y ago
> My biggest "issue" with this generally rather decent article is that CPU-bound applications are rare. For the plethora of social, productivity and novelty apps it doesn't matter at all. Or we can argue the other way around. Maybe we only have social, productivity and novelties over and over again because the limitations make those feasible?
- mhd 13y ago
  Don't think so. We also have lots of games, which show that if you actually need the performance, people are willing to "drop down" to native. But the lion's share of the rest of the AppStore market could probably be replaced with webapps without CPUs being rent apart. But it won't look as native and you can't charge money for it as easily. We also have lots of social apps because, after all, most mobile devices are communication devices, so this comes naturally. Never mind that even when you consider full-fledged desktop apps and the backends of lots of web sites, there's not that much that is really CPU-bound (although it's getting back there with ubiquitous data mining, which is one of the main reason we're seeing a resurgence of native compilers) Two device sectors where this might be different are big tablets and low-end devices, pretty much both extremes of the mobile sector. Tablets used as full PC replacements would probably be the main users of the CPU-bound spreadsheet the author mentioned, as well as other almost-desktop apps that could require more resources, esp. considering multi-tasking. And they would be on for long stretches of time, so even if the quad-core processor could cope, it would be nice if it could cope for twice as long. And then we have low-end devices. When the Palm came out, all the people who learned 68k assembly on their Amigas/Ataris were in demand again, as there was little CPU and memory to spare. On the other hand currently the environment mostly targeted at those sectors is the one with the least support/demand for native: FirefoxOS. Which seems a bit weird at first, as they certainly could make use of every MIPS they can scrounge. But that's economics for you: If it's mostly cheap phones and (most likely) users with little income to spare on frivolous apps, why would you target it? On the other hand, you're probably writing a webapp for other devices, and FirefoxOS users can piggyback on that. Sometimes you rather have a slow app than none at all.
revscat 13y ago
> And that whole talk about GCs sound awefully familiar. Didn't we have the very same conversation in the mid-90s when Java came out? Yes, absolutely. The objections made by OP are not very different from those made in the 90s. But... Some of the core objections made then are still true today, they're just hidden from users because of advancements in both hardware and GC technology itself. In the case of mobile, however, you're much more hardware constrained, at least for now. This will likely change sooner rather than later, but for now that means that for hardware-constrained devices well designed apps written in non-GC languages will almost always outperform similarly designed apps written in GC languages. In other words: it's going to be easier to get good performance out of Obj-C on mobile than Java, and certainly easier than JavaScript. For the record: I like Java -- yes, even today -- and the JVM, currently use it for my day job. For webapps it's moderately neato. For mobile, though... Not as much.
- eonil 13y ago
  I think this is because users are changed. Unlike old days, now users basically expects realtime graphics. And in realtime fields...
- pjmlp 13y ago
  I think the main issue is that those environment so far insist in a VM model. Most likely if Android used native compiled Java, performance could be improved. Microsoft went this route with Windows Phone 8, as they replaced the .NET JIT with a proper native compiler when targeting Windows Phone.
rsynnott 13y ago
> And that whole talk about GCs sound awefully familiar. Didn't we have the very same conversation in the mid-90s when Java came out? Yes. Fortunately, all of those problems just went away, and now we use Java for writing GUI desktop apps all the time! Why, imagine how terrible it would be if Java GUI apps were slow and awful and tended to mysteriously pause when there was a nasty GC cycle! Oh, wait.
- smackfu 13y ago
  2003 Java is why Java is not popular on desktops, not 2013 Java.
  - rsynnott 13y ago
    As someone who uses Netbeans all day, well, I'd love to say you're right, but no, I can still feel the GC pauses, both the tiny disconcerting ones and the >1 second enraging ones.
coldtea 13y ago
>My biggest "issue" with this generally rather decent article is that CPU-bound applications are rare. For the plethora of social, productivity and novelty apps it doesn't matter at all. He addresses that in the very first paragraphs: if your mobile app is basicaly a "web page with some buttons" then you are OK. But the apps that takes us forward are more CPU bound than BS clients and novelty apps. The spreadsheet. The word processor. The image editor. The video editor. Realtime stuff. Voice processing. Etc. We have those on the desktop and we want them on the mobile. >And that whole talk about GCs sound awefully familiar. Didn't we have the very same conversation in the mid-90s when Java came out? Yes. And notice how Java never got anywhere in the Desktop space? How SUN failed to create a web browser in Java because the thing was dog slow? And how, even today, users curse Eclipse for it's long GC pauses? And that the Java (well, Dalvik) GC is behind many of the things that plague Android devs in the mobile space (a lot of examples of which are in the article)?

by mhd 13y ago

hcarvalhoalves 13y ago

> My biggest "issue" with this generally rather decent article is that CPU-bound applications are rare. For the plethora of social, productivity and novelty apps it doesn't matter at all. Or we can argue the other way around. Maybe we only have social, productivity and novelties over and over again because the limitations make those feasible?

mhd 13y ago
Don't think so. We also have lots of games, which show that if you actually need the performance, people are willing to "drop down" to native. But the lion's share of the rest of the AppStore market could probably be replaced with webapps without CPUs being rent apart. But it won't look as native and you can't charge money for it as easily. We also have lots of social apps because, after all, most mobile devices are communication devices, so this comes naturally. Never mind that even when you consider full-fledged desktop apps and the backends of lots of web sites, there's not that much that is really CPU-bound (although it's getting back there with ubiquitous data mining, which is one of the main reason we're seeing a resurgence of native compilers) Two device sectors where this might be different are big tablets and low-end devices, pretty much both extremes of the mobile sector. Tablets used as full PC replacements would probably be the main users of the CPU-bound spreadsheet the author mentioned, as well as other almost-desktop apps that could require more resources, esp. considering multi-tasking. And they would be on for long stretches of time, so even if the quad-core processor could cope, it would be nice if it could cope for twice as long. And then we have low-end devices. When the Palm came out, all the people who learned 68k assembly on their Amigas/Ataris were in demand again, as there was little CPU and memory to spare. On the other hand currently the environment mostly targeted at those sectors is the one with the least support/demand for native: FirefoxOS. Which seems a bit weird at first, as they certainly could make use of every MIPS they can scrounge. But that's economics for you: If it's mostly cheap phones and (most likely) users with little income to spare on frivolous apps, why would you target it? On the other hand, you're probably writing a webapp for other devices, and FirefoxOS users can piggyback on that. Sometimes you rather have a slow app than none at all.

revscat 13y ago

> And that whole talk about GCs sound awefully familiar. Didn't we have the very same conversation in the mid-90s when Java came out? Yes, absolutely. The objections made by OP are not very different from those made in the 90s. But... Some of the core objections made then are still true today, they're just hidden from users because of advancements in both hardware and GC technology itself. In the case of mobile, however, you're much more hardware constrained, at least for now. This will likely change sooner rather than later, but for now that means that for hardware-constrained devices well designed apps written in non-GC languages will almost always outperform similarly designed apps written in GC languages. In other words: it's going to be easier to get good performance out of Obj-C on mobile than Java, and certainly easier than JavaScript. For the record: I like Java -- yes, even today -- and the JVM, currently use it for my day job. For webapps it's moderately neato. For mobile, though... Not as much.

eonil 13y ago
I think this is because users are changed. Unlike old days, now users basically expects realtime graphics. And in realtime fields...
pjmlp 13y ago
I think the main issue is that those environment so far insist in a VM model. Most likely if Android used native compiled Java, performance could be improved. Microsoft went this route with Windows Phone 8, as they replaced the .NET JIT with a proper native compiler when targeting Windows Phone.

rsynnott 13y ago

> And that whole talk about GCs sound awefully familiar. Didn't we have the very same conversation in the mid-90s when Java came out? Yes. Fortunately, all of those problems just went away, and now we use Java for writing GUI desktop apps all the time! Why, imagine how terrible it would be if Java GUI apps were slow and awful and tended to mysteriously pause when there was a nasty GC cycle! Oh, wait.

smackfu 13y ago
2003 Java is why Java is not popular on desktops, not 2013 Java.
- rsynnott 13y ago
  As someone who uses Netbeans all day, well, I'd love to say you're right, but no, I can still feel the GC pauses, both the tiny disconcerting ones and the >1 second enraging ones.

coldtea 13y ago

>My biggest "issue" with this generally rather decent article is that CPU-bound applications are rare. For the plethora of social, productivity and novelty apps it doesn't matter at all. He addresses that in the very first paragraphs: if your mobile app is basicaly a "web page with some buttons" then you are OK. But the apps that takes us forward are more CPU bound than BS clients and novelty apps. The spreadsheet. The word processor. The image editor. The video editor. Realtime stuff. Voice processing. Etc. We have those on the desktop and we want them on the mobile. >And that whole talk about GCs sound awefully familiar. Didn't we have the very same conversation in the mid-90s when Java came out? Yes. And notice how Java never got anywhere in the Desktop space? How SUN failed to create a web browser in Java because the thing was dog slow? And how, even today, users curse Eclipse for it's long GC pauses? And that the Java (well, Dalvik) GC is behind many of the things that plague Android devs in the mobile space (a lot of examples of which are in the article)?