Going down that road, you can discredit all RISC instructions sets on account of their lower code density.
As for the "only true for applications doing "bookkeeping"", since MIPS is already used in embedded so it's not an issue there, what exactly are you doing aside from bookeeping on a mobile SoC that won't be moved into the GPU core?
When ARM released the Cortex A15, there was no mention of a GPU. It's up to the SoC designer to integrate one.
Imagination Technologies already have their own GPU that is up there with the rest of them, the PowerVR series.
The only thing that matters is that there's going to be a GPU core to take care of those operations so you won't be missing them.
And, in ARM's case, there was the reference Mali GPU core...
There's a GPU core you know... Besides, it's not the CPU core but the memory bandwidth that matters.
to sell in it. They're not a monopoly so they don't need to excuse their decisions to not offer a product.
If you disagree with their policies, don't buy Apple.
Or more likely, another back-end for your engine of choice.
Many visually impaired individuals can't use anything but a terminal off a refreshable braille display... Are we to ban all GUIs now?
Computation speed doesn't mean memory size. It's quite possible compiled and yet garbage collected languages could be made to be as computationally efficient as C while possibly having a slightly bigger RAM footprint. So, you'd still want to avoid VMs and interpreters to save up on the CPU time, but no one would worry too much about binary sizes or garbage collection.
You'd still need to be precise and not leaking of course... But that just means the people writing the compiler should know what they're doing.
Why should I care about visits? I don't live off advertisements and page hits.
I'm interested in delivering information. A company's portfolio... A product's specifications... A personal contact page... A data sheet... Wikipedia with NoScript is done right as far as I'm concerned.
JavaScript was executed* over the course of two weekends so it was never built with much of anything in mind let alone security...
To be fair, the person in charge has repeatedly apologized and EcmaScript board members has explained both in public and in private that they all in agreement that JavaScript should be phased out and replaced completely.
Sadly, narrow business interests and squabbling amongst Microsoft, Mozilla and Google have been preventing any progress in the matter. Microsoft is pushing TypeScript, Google is pushing Dart, Mozilla is sticking to a EcmaScript for now... Mind you this is nothing new. Adobe's ActionScript is a JavaScript derivative born under similar conditions.
*designed would be a stretch...
same client's API...
What's wrong with using a simple, RESTful, HTTP API? You can even support a JavaScript client using the same client.
I'll ignore the web-based X programs issue since I've already mentioned I'm against serving application inside the browser.
As for the Slashdot comments, Slashdot should be an App. In fact, Slashdot is a prototype for apps like feedly.
Though the comments could still be served as read only on the html side... Somewhat like email lists archives.
As part of Chrome. Using the browser's own APIs.
Similarly, you can use Mozilla's Marketplace in the desktop version of Firefox... Like I said earlier, a pox on both houses.
Even if the security issues could be put to rest, there's no justification for running applications in a document viewer.
If Google is so concerned with serving up cross platform applications, they can package a VM and an App Store along with their browser. They can even conceive of their own URI scheme that will pass requests to the App Store to download and initialize Apps on the VM.
Is it really too much to expect something better then serving GUIs the likes of Facebook and Gmail inside the browser?
Yes. I am against both. Cross platform programming as an Interpreter running in a sandbox (JavaScript) or a bytecode VM (Java, NaCl...) shouldn't be done through the browser.
The Internet should be slightly expanded HTML1 and CGI as far as I'm concerned. Maybe with an exception for audio\video if we can agree on a codec...
Keep application development and serving to the likes of Android's Play Store + Dalvik.
Lots of folks confuse bad management with destiny. -- Frank Hubbard
