You could ignorantly say the same thing about several Asian languages. The fact of the matter is that there are more things than just vowels and consonants in human speech. Tone is very much an important part of language. Western languages usually don't put a lot of weight on tone to carry information, but French is notable exception. And even English sounds "funny" if implicit tone isn't pronounced properly.
Languages such as Mandarin, Cantonese, and Vietnamese are entirely unintelligible if tones aren't pronounced properly. In these languages, tones carry just as much information as vowels and consonants.
Japanese is apparently a language with a hidden tonal dependency. If you don't pronounce the tones properly, a native speaker won't be able to understand a word of what you are saying. But tones don't actually carry additional information. The correct tone can be derived from the rest of the sounds in the word. That's why Japanese words can be written in hiragana without needing any accent marks. To add extra complexity, tones do vary somewhat from region to region.
I think that is mostly a myth. It intuitively seems plausible that a more optimized keyboard layout would allow typists to be more efficient than when typing on QWERTY.
And there certainly have been several studies that place layouts such as Dvorak ahead of QWERTY. But a closer look at these studies shows that they are all heavily biased and flawed. More scientifically thorough studies surprisingly give Dvorak only a tiny lead over QWERTY if even that. With adequate practice, a good typist is pretty damn fast no matter the layout; OTOH, even the nicest layout can't make up for lack of practice.
You are correct though that there are horrible keyboard layouts that end up slowing you down, no matter how much you practice. I don't have any first-hand experience with AZERTY. But maybe, it's one of those really bad layouts; I wouldn't want to rule that out. And there obviously is an advantage to have a standardized keyboard. QWERTY is one of those standards that are readily available in most parts of the world. There is something to be said about that being useful. And it's the main reason I personally never bothered learning Dvorak.
Finally, if you really want to get substantially faster than QWERTY, you have to look at cording keyboards in combination with lots of macros. That's how real-time transcription of speech works. But the learning curve is said to be incredibly difficult. So, definitely not something you'd want to do unless you really need it.
I technically know how to type both on German and US keyboards. In practice, I find German layouts to be incredibly tedious -- even when typing German.
I much rather prefer a US keyboard layout and a working "Compose" key. Typing accented character is very straight forward and logical when composing the character from its underlying parts. Yes, it requires multiple keystrokes to type a single character; but I have gotten pretty fast at typing those.
Alternatively, some of my friends/relatives have switched to a US layout and refuse to enter native accented characters altogether. German officially sanctions the use of substitutes "ä" becomes "ae", "Ö" becomes "Oe" and "ß" becomes "ss". Maybe, the French should come up with a similar system.
The more the utilities push towards charging decentralized solar, the more it becomes attractive to get battery banks and to completely go off the grid. Technology isn't quite there yet. Batteries are still too expensive, capacities are too low, and they need replacement too frequently. But the trend is definitely in the right direction. In a few years, it'll make sense for many current home owners to install batteries and disconnect from the grid altogether.
Why would you want to pay a monthly interconnection-fee, if you don't really need the grid and if you can't sell excess energy.
Humans are used to see higher color temperature (i.e. more bluish light) in brighter environments. This naturally mimics the light around noon time. We are also used to see lower color temperatures (i.e. more yellow'ish light) in darker environments. This would mimic the light during dawn and dusk.
If the color temperature indoors doesn't match these expectations, we often feel uncomfortable. This is the reason why office environments often opt for more bluish lights; they also tend to run everything at much higher brightness. And restaurants are often kept darker and then the color temperature is adjusted towards a more yellow'ish tint. If you get this wrong (e.g. install bluish neon lights in a dimly lit corridor), it is blatantly obvious that something is wrong. Similarly, if you install lots and lots of yellowish lights, most people complain that things are unnaturally yellow.
With incandescent lights, we never had this much control, and people mostly got it right by installing the right number of light fixtures, and or the right type of light fixture (i.e. light bulb vs. halogen light vs. fluorescent tube). With LED lights, there is a lot more control; but that also means there is a lot more that can go wrong, if you don't pick the right temperature when buying the lights.
And to get back to your original question, yes, a dimmer that also adjusted the color temperature would be very nice to have. And with RGB-style LED lights, that's in principle possible to do. I haven't actually seen a product targeted at your average consumer that does this though.
For most travelers, a ChromeOS device is probably a better fit. You can get them as a small PC, a stick, a laptop or a tablet (technically a convertible laptop) depending on your preferred form factor. They're all super cheap, really secure even on a hostile network, and require not set up. And if the airlines breaks it, they're essentially disposable as they don't hold state.
Been traveling with different Chromebooks for the last couple of years, and I love it
Actually, if you're on T-Mobile USA, then all calls from, to, and within France are currently free. I am really happy to see big business put compassion before profit.
JetMan's flying wing is not going to be of any use to fire fighters. It gets about 10min of flight time. The entire body of the pilot is the control surface; so, don't even think of handling any fire-fighting tools while flying. It's not even possible to turn your head in arbitrary directions or the whole things becomes unstable. There is pretty much zero extra payload. And unless there is significant forward movement, the wing is not going to provide any lift and stay airborne. This is utterly and completely useless for anything other than fun YouTube videos.
Have you been buying any new hardware recently? My laptop has four physical cores and eight cores when using hyper threading (4/8). My desktop is 6/12 and my always-on home server has 12/24. The newest one of these devices is about two years old; the oldest one closer to five years.
Multiple cores are a pretty standard feature for a lot of hardware these days. Heck, even cellphones have between four and eight cores these days. So, no, you won't see many home PCs running on 36 cores. But there clearly is a trend towards a lot more cores. If Intel can figure out a way to make good use of this many cores, then they definitely will. It's good for their CPU business.
There have been technology demos that show successful charging through metal. But it's not Qi compatible and it won't really be ready for the mass market for at least another year or so. So, yeah, at this point, they would have had to avoid using a metal case. But next year, that's no longer a good argument.
Yeah, MTP has always been a little flaky for me. I usually just use "adb" from the command line.
I have looking for a way to integrate "adb" into Nautilus as a virtual file-system. There is an "adb" FUSE filesystem, but I am not quite sure I like that all that much. So, for now, I recommend getting these scripts instead: http://forum.xda-developers.co...
Also, if you don't want to use Nautilus, there is an "adb" based file manager called aafm. Maybe that's a good solution for some people.
You actually have it exactly the wrong way round. The nice thing about wireless charging is that I can use it while it is being charged, and I don't even need to do anything special (e.g. plug in a cable) to do this.
The difference is, you are talking about a desktop charger, whereas I am talking about a car charger. That's really the niche where wireless charging shines. Get in the car, hold the phone next to the car dock, it magnetically attaches itself and starts charging. All completely seamless. When you arrive at your destination, pick up the phone and leave the car.
And if you need to the phone in the car (take calls, use the GPS, listen to music), you can perfectly do that. Heck, if you need to briefly pick it up to enter an "OK Google" command, you can do that as well -- and then afterwards you place it back into the dock.
Wear and tear is definitely one of the factors. With wireless charging I don't have to worry that my kids trip over the cord and rip it out of the phone -- together with the phone's USB socket. But there are other benefits, too.
I have a magnetic wireless charger in my car. When I get into the car, I just hold the phone against the charger, it positions itself thanks to the magnets, and it then stays in place and keeps getting charged for the entire trip. I can keep the GPS and the music player running on a long road trip and I don't have to worry about ever running out of battery.
I also have a wireless charging pad next to my bed. Rather than trying to find the USB port when the lights are out and I am already half asleep, I just hold the phone roughly in the right spot and it attaches itself to the charger. It charges (almost) as fast as with my USB 2.0 cable, but probably not as fast as with a 15W fast charger. But who cares if it takes 2h to fully charge while I am asleep.
Look into the "workstation" offerings from PC vendors such as Dell, HP and Lenovo. They all tend to accept ECC memory. I think, the Dell T7610 that I bought recently takes up to 256GB of ECC memory, although I currently only have 32GB in it.
If you don't need the absolute latest model and/or if you are OK with a "scratch & dent" computer, you can often find amazing deals. With a little bit of shopping, I have regularly found top of the line Dell workstations for about 30% off list price. Hypothetically, if I split it for parts and sold just the RAID controller and the CPU online, I'd already make all my money back. And that's not even mentioning the included 3 year next-business-day on-site service contract.
I have generally had great luck with my Dell purchases. Their high-end professional models aren't as cheap as a bottom-of-the-barrel PC from Best Buy. But the extra money does give you a much better machine; better performance, much better reliability, and just a really well-thought-out design. I find, I often use my computers for 6+ years before they are retired entirely. That kind of amortizes the cost.
Call up Amazon. They'll most likely refund you the money for one of your accounts.
That doesn't solve your single sign on problem, but at least it gets you your $99.
As for the problem with the accounts my best suggestion is to set up multiple profiles with Android... assuming your OS is sufficiently recent to support this feature. Sorry that I don't have a better suggestion.
The bug is stupid. No doubt about that. But it's not quite as stupid as you think.
The bug is not actually in the setuid application, but it is in the system wide dynamic loader that is needed to execute the setuid application.
So, a naive programmer could be excused to think that they don't need to worry about security as it is not immediately obvious that the code executes with elevated privileges.
Of course a more seasoned developer should have noticed. It's not that difficult to spot, especially as dynamic loaders are known to have had security bugs before. I think even Linux was affected at one time.
WebWorkers allow multiple threads of execution, but they don't support a shared address space. For some applications this is acceptable. For others, not so much.
And for any application that previously existed as a C++ application using pthreads, WebWorkers just don't work at all.
WebAssembly is working on a solution to this problem. This is one of the most exciting features that WebAssembly promises.
JavaScript has a couple of really ugly warts (I'm surprised you mentioned variable hoisting, but left type coercion out), but fortunately with a little bit of discipline most of these issues can be avoided quite easily.
It is extremely flexible, and you can implement a large variety of programming paradigms with it. Unfortunately, it lacks some of the syntactic sugar to make this easy. So, short to medium size programs usually work great. Larger programs get cumbersome at some point.
Fortunately, there are all sorts of pre-processor style languages that can help with this. And browsers have source maps these days, so that's even reasonably seamless.
As far as embeddable language, JavaScript is overall not a bad design. Not surprisingly, it made a lot of the same trade-offs that other embeddable languages (e.g. Lisp or LUA) did. It is deceptively simple, but sufficiently different that it is really easy to falls into the trap of not learning it properly and trying to write JavaScript as if it was C++ (or Java, or...). I suspects that's the main reason why people don't like it.
On the positive side, it made a couple of decisions that paid off really well. First and foremost its decision to only ever have a single thread of execution really stands out. This makes it much easier to write a secure virtual machine, and that's really the most important question when embedding a language in a web browser; of course, the single thread of execution also is the one thing that gets into the way when taking existing non-JavaScript code and trying to execute it in a JavaScript VM. WebAssembly is an attempt to bridge this gap.
That is possibly true, although details will still need to be seen. asm.js programs typically allocate a single static memory region that they than manage themselves without bothering the JavaScript VM to track memory references. In fact, a asm.js program doesn't have access to garbage collected objects. As soon as it tries to access those, it falls back to JavaScript mode (every asm.js program is by definition also a valid JavaScript program, but not necessarily vice versa).
WebAssembly programs at least originally will do the same as asm.js. It is possible that as more experienced is gained with this feature, there will be a way for WebAssembly to tap into the garbage collected pool of objects. Only time will tell.
6502 is a very restrictive architecture. This wasn't too bad, when problems were usually trivial enough that 8 bit operations or at best 16 bit operations were needed the bulk of the time. But for any non-trivial problem these days, that's just not the case. And the limitation of a single general purpose register, a 256 byte zero page, a 256 byte stack and almost no addressing modes is just way too restrictive, if you want to start writing your programs in a high-level language; if you write tiny trivial hand-optimized assembly programs, that might not be obvious.
On top of that, the tiny address space made it impossible to write anything but the most trivial applications (by today's standards).
For simple programs written during that time period, the code was reasonably dense, but certainly not ground breakingly so. If you tried to write any modern programs, you'd be wasting a lot of space emulating 32 bit (or wider) operations, switching memory banks, and figuring out how to work around the lack of an FPU; let alone a MMU. The code would be horribly verbose.
x86 is actually not horribly bad by modern standards. It is almost the most compact encoding that anybody has managed to come up with, and that's a good thing. These days, memory bandwidth is a serious bottle neck and as a first approximation, the more compactly the compiler can encode your program, the faster it'll run. Code density is one of the driving forcing in going from asm.js to WebAssembly. asm.js is intrinsically verbose, but relies on compression to fix this issue.
On the other hand, WebAssembly will have its own dense binary encoding. The encoding is probably not going to look very similar to traditional instruction sets, but instead mimic the internal representations used by compilers and JIT based virtual machines (such as modern JavaScript implementations). It is expected to be very dense, so that even bit web applications load quickly. But as far as I can tell, the binary format hasn't been finalized yet; in fact, I don't think there are any detailed proposals yet. Although that might have changed since I checked a few weeks ago.
Exactly. Think of asm.js as the proof-of-concept and WebAssembly as the production-ready solution.
asm.js was a very valuable first step to get the browser vendors on board. But WebAssembly will push much further. Most importantly, it intends to support POSIX threads for languages such as C++. That's something that asm.js never knew how to address.
An awful lot of work has gone into making JavaScript virtual machines both high-performance and super secure. This is a difficult thing to get right. It is good to see that this work can now be leveraged for other languages, rather than forcing browser manufacturers to redo the work for each and every language. In the process they'd inevitably get something wrong, and that's quite dangerous; insecure browsers mean compromised computers.
JavaScript isn't necessarily such a bad language; otherwise, we wouldn't see Node.js gaining so much popularity.
But you are of course right, that there isn't a one-size-fits-all language, and there are plenty of problems that can better be solved in other languages. Allowing more choice of languages for web apps is a good thing.
Also, some of the more advanced JavaScript features that are in the pipeline (or starting to be deployed) are really cumbersome to program manually. All the work that will allow implementing pthreads in JavaScript is really low-level. It'll be nice to have compilers that target these features.
You can write asm.js by hand, no so sure about WebAssembly, although there could be rare corner cases where this is warranted.
But in almost all cases this is not the expected deployment scenario. Rather, you'll write your web app in one of many different high-level languages, and it will get compiled to WebAssembly. Interestingly enough, one of these languages is C++, which has a vastly different thread and memory model compared to JavaScript. This has always been a big stumbling block as there is existing C++ code that people would like to run in browsers, but up to now there was no good solution that works across browsers.
The roadmap suggests that JavaScript will retain its robust memory and thread model, but gain enough features to support the less robust but higher-performant model used by C++. We truly live in interesting times.
This will also address the problem that JavaScript could never effectively take advantage of multiple cores, but CPUs tend to add more performance by adding cores rather than by improving single-thread throughput.
Slashdot Mirror
You could ignorantly say the same thing about several Asian languages. The fact of the matter is that there are more things than just vowels and consonants in human speech. Tone is very much an important part of language. Western languages usually don't put a lot of weight on tone to carry information, but French is notable exception. And even English sounds "funny" if implicit tone isn't pronounced properly.
Languages such as Mandarin, Cantonese, and Vietnamese are entirely unintelligible if tones aren't pronounced properly. In these languages, tones carry just as much information as vowels and consonants.
Japanese is apparently a language with a hidden tonal dependency. If you don't pronounce the tones properly, a native speaker won't be able to understand a word of what you are saying. But tones don't actually carry additional information. The correct tone can be derived from the rest of the sounds in the word. That's why Japanese words can be written in hiragana without needing any accent marks. To add extra complexity, tones do vary somewhat from region to region.
I think that is mostly a myth. It intuitively seems plausible that a more optimized keyboard layout would allow typists to be more efficient than when typing on QWERTY.
And there certainly have been several studies that place layouts such as Dvorak ahead of QWERTY. But a closer look at these studies shows that they are all heavily biased and flawed. More scientifically thorough studies surprisingly give Dvorak only a tiny lead over QWERTY if even that. With adequate practice, a good typist is pretty damn fast no matter the layout; OTOH, even the nicest layout can't make up for lack of practice.
You are correct though that there are horrible keyboard layouts that end up slowing you down, no matter how much you practice. I don't have any first-hand experience with AZERTY. But maybe, it's one of those really bad layouts; I wouldn't want to rule that out. And there obviously is an advantage to have a standardized keyboard. QWERTY is one of those standards that are readily available in most parts of the world. There is something to be said about that being useful. And it's the main reason I personally never bothered learning Dvorak.
Finally, if you really want to get substantially faster than QWERTY, you have to look at cording keyboards in combination with lots of macros. That's how real-time transcription of speech works. But the learning curve is said to be incredibly difficult. So, definitely not something you'd want to do unless you really need it.
I technically know how to type both on German and US keyboards. In practice, I find German layouts to be incredibly tedious -- even when typing German.
I much rather prefer a US keyboard layout and a working "Compose" key. Typing accented character is very straight forward and logical when composing the character from its underlying parts. Yes, it requires multiple keystrokes to type a single character; but I have gotten pretty fast at typing those.
Alternatively, some of my friends/relatives have switched to a US layout and refuse to enter native accented characters altogether. German officially sanctions the use of substitutes "ä" becomes "ae", "Ö" becomes "Oe" and "ß" becomes "ss". Maybe, the French should come up with a similar system.
The more the utilities push towards charging decentralized solar, the more it becomes attractive to get battery banks and to completely go off the grid. Technology isn't quite there yet. Batteries are still too expensive, capacities are too low, and they need replacement too frequently. But the trend is definitely in the right direction. In a few years, it'll make sense for many current home owners to install batteries and disconnect from the grid altogether.
Why would you want to pay a monthly interconnection-fee, if you don't really need the grid and if you can't sell excess energy.
There actually is a good argument to be made for changing the color temperature with the amount of light output.
Take a look at the Kruithof Curve: https://en.wikipedia.org/wiki/...
Humans are used to see higher color temperature (i.e. more bluish light) in brighter environments. This naturally mimics the light around noon time. We are also used to see lower color temperatures (i.e. more yellow'ish light) in darker environments. This would mimic the light during dawn and dusk.
If the color temperature indoors doesn't match these expectations, we often feel uncomfortable. This is the reason why office environments often opt for more bluish lights; they also tend to run everything at much higher brightness. And restaurants are often kept darker and then the color temperature is adjusted towards a more yellow'ish tint. If you get this wrong (e.g. install bluish neon lights in a dimly lit corridor), it is blatantly obvious that something is wrong. Similarly, if you install lots and lots of yellowish lights, most people complain that things are unnaturally yellow.
With incandescent lights, we never had this much control, and people mostly got it right by installing the right number of light fixtures, and or the right type of light fixture (i.e. light bulb vs. halogen light vs. fluorescent tube). With LED lights, there is a lot more control; but that also means there is a lot more that can go wrong, if you don't pick the right temperature when buying the lights.
And to get back to your original question, yes, a dimmer that also adjusted the color temperature would be very nice to have. And with RGB-style LED lights, that's in principle possible to do. I haven't actually seen a product targeted at your average consumer that does this though.
For most travelers, a ChromeOS device is probably a better fit. You can get them as a small PC, a stick, a laptop or a tablet (technically a convertible laptop) depending on your preferred form factor. They're all super cheap, really secure even on a hostile network, and require not set up. And if the airlines breaks it, they're essentially disposable as they don't hold state.
Been traveling with different Chromebooks for the last couple of years, and I love it
Actually, if you're on T-Mobile USA, then all calls from, to, and within France are currently free. I am really happy to see big business put compassion before profit.
JetMan's flying wing is not going to be of any use to fire fighters. It gets about 10min of flight time. The entire body of the pilot is the control surface; so, don't even think of handling any fire-fighting tools while flying. It's not even possible to turn your head in arbitrary directions or the whole things becomes unstable. There is pretty much zero extra payload. And unless there is significant forward movement, the wing is not going to provide any lift and stay airborne. This is utterly and completely useless for anything other than fun YouTube videos.
Have you been buying any new hardware recently? My laptop has four physical cores and eight cores when using hyper threading (4/8). My desktop is 6/12 and my always-on home server has 12/24. The newest one of these devices is about two years old; the oldest one closer to five years.
Multiple cores are a pretty standard feature for a lot of hardware these days. Heck, even cellphones have between four and eight cores these days. So, no, you won't see many home PCs running on 36 cores. But there clearly is a trend towards a lot more cores. If Intel can figure out a way to make good use of this many cores, then they definitely will. It's good for their CPU business.
There have been technology demos that show successful charging through metal. But it's not Qi compatible and it won't really be ready for the mass market for at least another year or so. So, yeah, at this point, they would have had to avoid using a metal case. But next year, that's no longer a good argument.
Yeah, MTP has always been a little flaky for me. I usually just use "adb" from the command line.
I have looking for a way to integrate "adb" into Nautilus as a virtual file-system. There is an "adb" FUSE filesystem, but I am not quite sure I like that all that much. So, for now, I recommend getting these scripts instead: http://forum.xda-developers.co...
Also, if you don't want to use Nautilus, there is an "adb" based file manager called aafm. Maybe that's a good solution for some people.
You actually have it exactly the wrong way round. The nice thing about wireless charging is that I can use it while it is being charged, and I don't even need to do anything special (e.g. plug in a cable) to do this.
The difference is, you are talking about a desktop charger, whereas I am talking about a car charger. That's really the niche where wireless charging shines. Get in the car, hold the phone next to the car dock, it magnetically attaches itself and starts charging. All completely seamless. When you arrive at your destination, pick up the phone and leave the car.
And if you need to the phone in the car (take calls, use the GPS, listen to music), you can perfectly do that. Heck, if you need to briefly pick it up to enter an "OK Google" command, you can do that as well -- and then afterwards you place it back into the dock.
Wear and tear is definitely one of the factors. With wireless charging I don't have to worry that my kids trip over the cord and rip it out of the phone -- together with the phone's USB socket. But there are other benefits, too.
I have a magnetic wireless charger in my car. When I get into the car, I just hold the phone against the charger, it positions itself thanks to the magnets, and it then stays in place and keeps getting charged for the entire trip. I can keep the GPS and the music player running on a long road trip and I don't have to worry about ever running out of battery.
I also have a wireless charging pad next to my bed. Rather than trying to find the USB port when the lights are out and I am already half asleep, I just hold the phone roughly in the right spot and it attaches itself to the charger. It charges (almost) as fast as with my USB 2.0 cable, but probably not as fast as with a 15W fast charger. But who cares if it takes 2h to fully charge while I am asleep.
Look into the "workstation" offerings from PC vendors such as Dell, HP and Lenovo. They all tend to accept ECC memory. I think, the Dell T7610 that I bought recently takes up to 256GB of ECC memory, although I currently only have 32GB in it.
If you don't need the absolute latest model and/or if you are OK with a "scratch & dent" computer, you can often find amazing deals. With a little bit of shopping, I have regularly found top of the line Dell workstations for about 30% off list price. Hypothetically, if I split it for parts and sold just the RAID controller and the CPU online, I'd already make all my money back. And that's not even mentioning the included 3 year next-business-day on-site service contract.
I have generally had great luck with my Dell purchases. Their high-end professional models aren't as cheap as a bottom-of-the-barrel PC from Best Buy. But the extra money does give you a much better machine; better performance, much better reliability, and just a really well-thought-out design. I find, I often use my computers for 6+ years before they are retired entirely. That kind of amortizes the cost.
Call up Amazon. They'll most likely refund you the money for one of your accounts.
That doesn't solve your single sign on problem, but at least it gets you your $99.
As for the problem with the accounts my best suggestion is to set up multiple profiles with Android ... assuming your OS is sufficiently recent to support this feature. Sorry that I don't have a better suggestion.
The bug is stupid. No doubt about that. But it's not quite as stupid as you think.
The bug is not actually in the setuid application, but it is in the system wide dynamic loader that is needed to execute the setuid application.
So, a naive programmer could be excused to think that they don't need to worry about security as it is not immediately obvious that the code executes with elevated privileges.
Of course a more seasoned developer should have noticed. It's not that difficult to spot, especially as dynamic loaders are known to have had security bugs before. I think even Linux was affected at one time.
WebWorkers allow multiple threads of execution, but they don't support a shared address space. For some applications this is acceptable. For others, not so much.
And for any application that previously existed as a C++ application using pthreads, WebWorkers just don't work at all.
WebAssembly is working on a solution to this problem. This is one of the most exciting features that WebAssembly promises.
JavaScript has a couple of really ugly warts (I'm surprised you mentioned variable hoisting, but left type coercion out), but fortunately with a little bit of discipline most of these issues can be avoided quite easily.
It is extremely flexible, and you can implement a large variety of programming paradigms with it. Unfortunately, it lacks some of the syntactic sugar to make this easy. So, short to medium size programs usually work great. Larger programs get cumbersome at some point.
Fortunately, there are all sorts of pre-processor style languages that can help with this. And browsers have source maps these days, so that's even reasonably seamless.
As far as embeddable language, JavaScript is overall not a bad design. Not surprisingly, it made a lot of the same trade-offs that other embeddable languages (e.g. Lisp or LUA) did. It is deceptively simple, but sufficiently different that it is really easy to falls into the trap of not learning it properly and trying to write JavaScript as if it was C++ (or Java, or ...). I suspects that's the main reason why people don't like it.
On the positive side, it made a couple of decisions that paid off really well. First and foremost its decision to only ever have a single thread of execution really stands out. This makes it much easier to write a secure virtual machine, and that's really the most important question when embedding a language in a web browser; of course, the single thread of execution also is the one thing that gets into the way when taking existing non-JavaScript code and trying to execute it in a JavaScript VM. WebAssembly is an attempt to bridge this gap.
That is possibly true, although details will still need to be seen. asm.js programs typically allocate a single static memory region that they than manage themselves without bothering the JavaScript VM to track memory references. In fact, a asm.js program doesn't have access to garbage collected objects. As soon as it tries to access those, it falls back to JavaScript mode (every asm.js program is by definition also a valid JavaScript program, but not necessarily vice versa).
WebAssembly programs at least originally will do the same as asm.js. It is possible that as more experienced is gained with this feature, there will be a way for WebAssembly to tap into the garbage collected pool of objects. Only time will tell.
6502 is a very restrictive architecture. This wasn't too bad, when problems were usually trivial enough that 8 bit operations or at best 16 bit operations were needed the bulk of the time. But for any non-trivial problem these days, that's just not the case. And the limitation of a single general purpose register, a 256 byte zero page, a 256 byte stack and almost no addressing modes is just way too restrictive, if you want to start writing your programs in a high-level language; if you write tiny trivial hand-optimized assembly programs, that might not be obvious.
On top of that, the tiny address space made it impossible to write anything but the most trivial applications (by today's standards).
For simple programs written during that time period, the code was reasonably dense, but certainly not ground breakingly so. If you tried to write any modern programs, you'd be wasting a lot of space emulating 32 bit (or wider) operations, switching memory banks, and figuring out how to work around the lack of an FPU; let alone a MMU. The code would be horribly verbose.
x86 is actually not horribly bad by modern standards. It is almost the most compact encoding that anybody has managed to come up with, and that's a good thing. These days, memory bandwidth is a serious bottle neck and as a first approximation, the more compactly the compiler can encode your program, the faster it'll run. Code density is one of the driving forcing in going from asm.js to WebAssembly. asm.js is intrinsically verbose, but relies on compression to fix this issue.
On the other hand, WebAssembly will have its own dense binary encoding. The encoding is probably not going to look very similar to traditional instruction sets, but instead mimic the internal representations used by compilers and JIT based virtual machines (such as modern JavaScript implementations). It is expected to be very dense, so that even bit web applications load quickly. But as far as I can tell, the binary format hasn't been finalized yet; in fact, I don't think there are any detailed proposals yet. Although that might have changed since I checked a few weeks ago.
Exactly. Think of asm.js as the proof-of-concept and WebAssembly as the production-ready solution.
asm.js was a very valuable first step to get the browser vendors on board. But WebAssembly will push much further. Most importantly, it intends to support POSIX threads for languages such as C++. That's something that asm.js never knew how to address.
A application that only sells in the Apple store is very different from a web site that can only be viewed with an iPhone.
An awful lot of work has gone into making JavaScript virtual machines both high-performance and super secure. This is a difficult thing to get right. It is good to see that this work can now be leveraged for other languages, rather than forcing browser manufacturers to redo the work for each and every language. In the process they'd inevitably get something wrong, and that's quite dangerous; insecure browsers mean compromised computers.
JavaScript isn't necessarily such a bad language; otherwise, we wouldn't see Node.js gaining so much popularity.
But you are of course right, that there isn't a one-size-fits-all language, and there are plenty of problems that can better be solved in other languages. Allowing more choice of languages for web apps is a good thing.
Also, some of the more advanced JavaScript features that are in the pipeline (or starting to be deployed) are really cumbersome to program manually. All the work that will allow implementing pthreads in JavaScript is really low-level. It'll be nice to have compilers that target these features.
You can write asm.js by hand, no so sure about WebAssembly, although there could be rare corner cases where this is warranted.
But in almost all cases this is not the expected deployment scenario. Rather, you'll write your web app in one of many different high-level languages, and it will get compiled to WebAssembly. Interestingly enough, one of these languages is C++, which has a vastly different thread and memory model compared to JavaScript. This has always been a big stumbling block as there is existing C++ code that people would like to run in browsers, but up to now there was no good solution that works across browsers.
The roadmap suggests that JavaScript will retain its robust memory and thread model, but gain enough features to support the less robust but higher-performant model used by C++. We truly live in interesting times.
This will also address the problem that JavaScript could never effectively take advantage of multiple cores, but CPUs tend to add more performance by adding cores rather than by improving single-thread throughput.