The ANGLE shader compiler used in most WebGL implementations already does enforce that loops terminate. The problem is that GPUs don't / didn't have HW interrupts to allow switching between tasks.
It's not easily solvable by a super-powered compiler either. Sure, you could write your own compute-driven preemptive graphics pipeline and break execution after every X billion simulated instructions & random memory accesses. You'd have to do reanalysis on every frame too, due to changing shader inputs.
The computation done is roughly (number of vertices * vertex shader compute time) + (number of pixels falling under the vertex primitives * fragment shader compute time). The shader compute times are the sums of instruction execution times + data fetch times. Then take into account early exits, data access patterns and cache sizes (otherwise the compiler'll think that e.g. a simple greyscaling fragment shader is going to cause a random memory access for every pixel and take forever to run, causing the compiler to spread the shader execution across multiple frames and kill performance dead.)
Ok, I'll bite. I found these fascinating. You could live in every one of them, it feels like I'm transported to different times and places, wondering what these people are up to, what's going on, enjoying the sunshine / snow / rain / rough seas. In a word, interesting.
Nokia was really good at competing in big markets. Back when everyone was using their various pre-Android stacks with similar levels of software prowess, Nokia was the biggest phone maker. Because they were competing in the biggest market and doing it well.
Then the market changed to "[Android] phones that are like the iPhone" and Nokia refused to compete in that market, going for the "[Windows] phones that are not like the iPhone"-market instead. And totally dominated it with a 90%+ market share.
But that market was tiny. And Nokia was size-wise geared to compete with Samsung and Apple. Cue massive collapse of business when expenses overtook sales.
I can imagine the Elop-to-all-employees memo as MS CEO: Windows 8 is a disaster. Windows 9 is not ready yet and won't be ready for years. We're on a burning oil platform in the middle of the night. The only way to survive is to jump into the icy cold waters of the Puget Sound.
We're announcing a platform shift to Symbian, which we'll be licensing from Accenture Consulting at $15/pop. But they're our strategic partners so they're going to give us marketing money to market the new Microsoft Symbian 800, so it's almost like it's free.
In order to take advantage of the synergic benefits of outsourcing our core business, I'm going to sell the Microsoft headquarters, fire all the obsoleted software engineers along with 50000 employees who cost too much to employ in our new revenue structure. We will also be EOLing Windows, Xbox, Windows Live, Hotmail and Office and focus on rocking the world with Bing and the Microsoft Symbian range of products, supported by the amazing Accenture Symbian App Store.
Our exclusive partnership with Lenovo to sell Microsoft Symbian in countries where we have traditionally done badly is going to form the cornerstone of our new strategy. The new $1999 Lenovo Symbian smart tablets are industrial-strength products designed to make a massive impact from Sichuan to Gansu.
I did a quick Finnish translation as a lark, then found the BabylScript project and added their translations to the page.
The main difference between the approaches is that BabylScript does things in a more Right Way (they do punctuation, number parsing, localised object property names) whereas js-i18n only maps translated tokens to JavaScript tokens. Token mapping is easy to implement and has no effect on the generated code (though you need to watch out for namespace collisions, as different words in language X may map into one word in language Y). From reading the paper, the BabylScript project needs to do some runtime dispatching to handle translated property names.
It's not easily solvable by a super-powered compiler either. Sure, you could write your own compute-driven preemptive graphics pipeline and break execution after every X billion simulated instructions & random memory accesses. You'd have to do reanalysis on every frame too, due to changing shader inputs.
The computation done is roughly (number of vertices * vertex shader compute time) + (number of pixels falling under the vertex primitives * fragment shader compute time). The shader compute times are the sums of instruction execution times + data fetch times. Then take into account early exits, data access patterns and cache sizes (otherwise the compiler'll think that e.g. a simple greyscaling fragment shader is going to cause a random memory access for every pixel and take forever to run, causing the compiler to spread the shader execution across multiple frames and kill performance dead.)