22 seconds? So the shooter was already outside in his own backyard with an appropriately loaded shotgun* just waiting for any old drone he had never seen to come by at random??
First, the new parent company is just called "Alphabet" - not "Google Alphabet", as the summary claims.
Technically, "Alphabet, Inc."
Second, on the face of it this seems more like a rebranding than anything else. Nothing seems to be changing; they're just renaming "Google" to "Alphabet", and then repurposing the Google name to be used for one already-existing division within the renamed company.
You have that inverted: Google will remain named Google, but it will become just one of several companies under the Alphabet umbrella. It's a refactoring and a modularization.
Stacking at 2x the depth produces 2x the heat per square unit of die size. We already have heat and power budget issues that give rise to "dark silicon". Therefore, there isn't very much vertical room to expand either. (And to think that the entire human brain runs at about 0.5 Watt...)
Tesla charge ports are always in the same position (at least for now, when there's basically one mainstream model). They don't need to solve such a complex controller problem (with this many degrees of freedom) to plug in the charger. They're just doing it because they can...
Um, I know that ECMAScript "IS" Javascript. Typescript is becoming much bigger than Microsoft itself. The only Microsoft products I have ever been interested in using before Typescript are their keyboards and mice. Typescript is, quite shockingly, actually really, really good, and Microsoft, even more shockingly, is suddenly becoming a really good citizen in the open source / Free software world, at least as far as some projects are concerned, and the stuff they're putting out there is really good. (See also: Visual Studio Code.)
Microsoft have also, quite suddenly and inexplicably, become extremely open about the development process of some of these newer open source projects, and they are working with, and responding to, other key players in the open source ecosystem. (Google adopted Typescript for Angular2, and Microsoft merged Angular's "AtScript" extensions into Typescript, and made Typescript a strict superset of ECMAScript 7, in order to satisfy Google's requirements, and to make Typescript a better player in the Javascript world. Microsoft was a key presenter at, and participant in, ng-conf 2015. etc. etc.
Haxe isn't very high-profile, but Typescript is an important language, if only for the fact that it is starting to drive the design of ECMAScript. Typescript has recently become a strict superset of ECMAScript functionality, and Typescript has become the new testing ground for features before they get incorporated into ECMAScript. (This may not always be true, because Typescript is developed by Microsoft, but it seems to be true at least for now. You know to sit up and start paying attention when Google decides to rebase one of their strategic platforms -- Angular -- on a Microsoft technology.)
What's actually wrong with Javascript as a compile target?
Where to even begin... maybe the fact that Javascript doesn't even have integers? Or that (other than in asm.js) it doesn't support C-style malloc/free heap-based allocation? Or that (again, other than in asm.js) the runtime is garbage collected? Or that it doesn't properly support threads (a huge deal given the demands of modern computing), or sharing of memory between WebWorkers and the main thread?
Sure you can argue the problems with the language itself but when it's a compile target all of those are abstracted away, the thing that is important then is speed. And it's not exactly slow, could it be faster? Most likely. Does it need to be? For most cases probably not.
Javascript wastes petawatt-hours of energy per year across the globe due to its computational inefficiency. That means your power bill is higher than it could be, your phone battery doesn't last as long as it could, and polar bears are dying in the Arctic because Javascript has been deemed "efficient enough".
UI latency irks our subconscious. Once we have native WebAssembly support in browsers, and a significant percentage of the major websites have moved across to compiling from better languages into WebAssembly, those new sites are going to feel amazingly snappy, and people aren't going to want to use old Javascript sites, because they'll feel janky.
How is that web assembly project coming along? It seems like a perfect fit for alternative languages like this instead of having to compile to JS.
WebAssembly is not currently a suitable target for Javascript compilation, because it lacks a garbage collector. Only languages that can base themselves on (the equivalent of) malloc/free can currently target wasm. Eventually garbage collection facilities will be provided, but they're not on the immediate drawing board, and even once garbage collection is possible, it's likely to be a long time before JS->wasm approaches the performance of v8 or similar. (Note that asm.js doesn't do garbage collection either.)
The nice things about wasm are (1) it gives the creators a chance to re-invent the web runtime from the ground up (e.g. native threads will be there almost from the start), (2) languages can evolve independently of the web platform, and the web platform becomes language agnostic, and (3) *all* the major players are fully on-board.
One of the nicest features of wasm, in my opinion, is that the intermediate representation is an AST of expressions to be computed. This is a far more sensible and flexible IR than some stack-based or register-based VM bytecode system. My prediction is that wasm will become the preferred compilation target for desktop/server applications, not just web applications: the same toolchain will be used to generate binaries for running in server containers as well as within a browser.
The set of hardware capabilities available on a smartphone has more or less stabilized on phones these days. Which means that the kernel API to the hardware could be frozen. Which means that everything above the kernel level could be OTA-upgraded (to stock, at least -- carrier customizations should be installed as an app and/or theme on top of the stock firmware anyway). Why in 2015 is the entire platform not hot-upgradeable? The inability to do so is just plain stupidity. (Memory limits / CPU speed etc. don't count -- in Android K and L, a lot of work was done to reduce the memory footprint and increase the VM speed... you only need half a gig of RAM to run Android L.)
Unfortunately we don't have good enough compilers yet to generate code for a multi-core brain. They may as well just use one cat brain rather than four rat brains, compiled code will still run faster.
I had a bad back from sitting all day, so I tried standing. I developed nerve compression issues in my feet. I had RSI in my right wrist from using my mouse all day, so switched to my left wrist, and the RSI spread there. The reality is that the human body is not designed to do the same thing all day every day.
It's more than just pre-compiled Javascript. It has proper types (like integers! In 2015!), unlike Javascript. It will be an easier compilation target than asm.js for both traditionally compiled languages (C/C++) and newer languages. There will be freedom to break from Javascript conventions that have held back the Web, such as the single-threaded nature of the Javascript VM (of course there are Web Workers, but no proper shared memory model currently etc. -- this slows down multithreaded code, requires a different programming model, and is not a good foundation for the future of multithreaded apps). Really WebAssembly is what NaCl and pNaCl were trying to be.
I love the BBC micro, Archimedes and RISC PC -- I grew up on them. But why is the BBC doing this now? Every kid in the UK has a supercomputer in their pocket already, by 1981 standards. What is needed is a simpler and more compelling way for kids to get into programming their phones, and a simpler way to interface their phones to external hardware.
I totally agree that Apple's keyboard should show the current character case on the keys, it's quite ridiculous that it doesn't. I suspect the reason for only displaying capital letters is that Apple is too emotionally attached to skeumorphism to ever change the design. (Hardware keyboards only show capital letters, "so why should a software keyboard change that?")
Latest predictions are that the heat death of the universe will occur at 2^64-1 seconds after the Unix epoch.
22 seconds? So the shooter was already outside in his own backyard with an appropriately loaded shotgun* just waiting for any old drone he had never seen to come by at random??
Entirely plausible in Kentucky.
s/conglomerate/chaebol/g
First, the new parent company is just called "Alphabet" - not "Google Alphabet", as the summary claims.
Technically, "Alphabet, Inc."
Second, on the face of it this seems more like a rebranding than anything else. Nothing seems to be changing; they're just renaming "Google" to "Alphabet", and then repurposing the Google name to be used for one already-existing division within the renamed company.
You have that inverted: Google will remain named Google, but it will become just one of several companies under the Alphabet umbrella. It's a refactoring and a modularization.
Stacking at 2x the depth produces 2x the heat per square unit of die size. We already have heat and power budget issues that give rise to "dark silicon". Therefore, there isn't very much vertical room to expand either. (And to think that the entire human brain runs at about 0.5 Watt...)
Let me guess: they disabled networking and all drives, memory card readers and USB ports?
Tesla charge ports are always in the same position (at least for now, when there's basically one mainstream model). They don't need to solve such a complex controller problem (with this many degrees of freedom) to plug in the charger. They're just doing it because they can...
It's the future. Go search for interviews with Brendan Eich on the subject of WebAssembly, and you'll see what I mean.
There's a polyfill, so the (very alpha) prototype binary format of WebAssembly works on all Javascript-capable browsers today.
There's a polyfill. Obviously.
You could do this with C/C++ too before C/C++ compiled to Javascript via Emscripten. That's kind of a tautology.
Um, I know that ECMAScript "IS" Javascript. Typescript is becoming much bigger than Microsoft itself. The only Microsoft products I have ever been interested in using before Typescript are their keyboards and mice. Typescript is, quite shockingly, actually really, really good, and Microsoft, even more shockingly, is suddenly becoming a really good citizen in the open source / Free software world, at least as far as some projects are concerned, and the stuff they're putting out there is really good. (See also: Visual Studio Code.)
Microsoft have also, quite suddenly and inexplicably, become extremely open about the development process of some of these newer open source projects, and they are working with, and responding to, other key players in the open source ecosystem. (Google adopted Typescript for Angular2, and Microsoft merged Angular's "AtScript" extensions into Typescript, and made Typescript a strict superset of ECMAScript 7, in order to satisfy Google's requirements, and to make Typescript a better player in the Javascript world. Microsoft was a key presenter at, and participant in, ng-conf 2015. etc. etc.
Haxe isn't very high-profile, but Typescript is an important language, if only for the fact that it is starting to drive the design of ECMAScript. Typescript has recently become a strict superset of ECMAScript functionality, and Typescript has become the new testing ground for features before they get incorporated into ECMAScript. (This may not always be true, because Typescript is developed by Microsoft, but it seems to be true at least for now. You know to sit up and start paying attention when Google decides to rebase one of their strategic platforms -- Angular -- on a Microsoft technology.)
What's actually wrong with Javascript as a compile target?
Where to even begin... maybe the fact that Javascript doesn't even have integers? Or that (other than in asm.js) it doesn't support C-style malloc/free heap-based allocation? Or that (again, other than in asm.js) the runtime is garbage collected? Or that it doesn't properly support threads (a huge deal given the demands of modern computing), or sharing of memory between WebWorkers and the main thread?
Sure you can argue the problems with the language itself but when it's a compile target all of those are abstracted away, the thing that is important then is speed. And it's not exactly slow, could it be faster? Most likely. Does it need to be? For most cases probably not.
Javascript wastes petawatt-hours of energy per year across the globe due to its computational inefficiency. That means your power bill is higher than it could be, your phone battery doesn't last as long as it could, and polar bears are dying in the Arctic because Javascript has been deemed "efficient enough".
UI latency irks our subconscious. Once we have native WebAssembly support in browsers, and a significant percentage of the major websites have moved across to compiling from better languages into WebAssembly, those new sites are going to feel amazingly snappy, and people aren't going to want to use old Javascript sites, because they'll feel janky.
How is that web assembly project coming along? It seems like a perfect fit for alternative languages like this instead of having to compile to JS.
WebAssembly is not currently a suitable target for Javascript compilation, because it lacks a garbage collector. Only languages that can base themselves on (the equivalent of) malloc/free can currently target wasm. Eventually garbage collection facilities will be provided, but they're not on the immediate drawing board, and even once garbage collection is possible, it's likely to be a long time before JS->wasm approaches the performance of v8 or similar. (Note that asm.js doesn't do garbage collection either.)
The nice things about wasm are (1) it gives the creators a chance to re-invent the web runtime from the ground up (e.g. native threads will be there almost from the start), (2) languages can evolve independently of the web platform, and the web platform becomes language agnostic, and (3) *all* the major players are fully on-board.
One of the nicest features of wasm, in my opinion, is that the intermediate representation is an AST of expressions to be computed. This is a far more sensible and flexible IR than some stack-based or register-based VM bytecode system. My prediction is that wasm will become the preferred compilation target for desktop/server applications, not just web applications: the same toolchain will be used to generate binaries for running in server containers as well as within a browser.
The set of hardware capabilities available on a smartphone has more or less stabilized on phones these days. Which means that the kernel API to the hardware could be frozen. Which means that everything above the kernel level could be OTA-upgraded (to stock, at least -- carrier customizations should be installed as an app and/or theme on top of the stock firmware anyway). Why in 2015 is the entire platform not hot-upgradeable? The inability to do so is just plain stupidity. (Memory limits / CPU speed etc. don't count -- in Android K and L, a lot of work was done to reduce the memory footprint and increase the VM speed... you only need half a gig of RAM to run Android L.)
You had me at "Ubuntu". Cough, Mir.
So far the only movie to get AI right is Star Trek IV: The Voyage Home.
Unfortunately we don't have good enough compilers yet to generate code for a multi-core brain. They may as well just use one cat brain rather than four rat brains, compiled code will still run faster.
I had a bad back from sitting all day, so I tried standing. I developed nerve compression issues in my feet. I had RSI in my right wrist from using my mouse all day, so switched to my left wrist, and the RSI spread there. The reality is that the human body is not designed to do the same thing all day every day.
It's more than just pre-compiled Javascript. It has proper types (like integers! In 2015!), unlike Javascript. It will be an easier compilation target than asm.js for both traditionally compiled languages (C/C++) and newer languages. There will be freedom to break from Javascript conventions that have held back the Web, such as the single-threaded nature of the Javascript VM (of course there are Web Workers, but no proper shared memory model currently etc. -- this slows down multithreaded code, requires a different programming model, and is not a good foundation for the future of multithreaded apps). Really WebAssembly is what NaCl and pNaCl were trying to be.
Weird metaphor.
I love the BBC micro, Archimedes and RISC PC -- I grew up on them. But why is the BBC doing this now? Every kid in the UK has a supercomputer in their pocket already, by 1981 standards. What is needed is a simpler and more compelling way for kids to get into programming their phones, and a simpler way to interface their phones to external hardware.
A lot of times a shark will bite something just because it's curious, like how a dog will sniff something and then pick it up in its mouth.
I totally agree that Apple's keyboard should show the current character case on the keys, it's quite ridiculous that it doesn't. I suspect the reason for only displaying capital letters is that Apple is too emotionally attached to skeumorphism to ever change the design. (Hardware keyboards only show capital letters, "so why should a software keyboard change that?")