So why hasn't the US absorbed the much better date notation that the rest of the world uses?

Actually we - that is, the British - often say it that way too, although it is more common to say it as M-D-Y, especially when including the year. But my point is that basing a written, numerical short-form notation purely on natural language (which is variable anyway), without posing some kind of logical order on it, is the very basis of why the US convention is a bit daft. By the way, I already speak English (of the Queen's variety), and it seems highly unlikely that the American short-form date notation will ever become the global norm, so I'm not sure what assimilation you're referring to..

Natural sorting is only advantageous to computers, and they don't deal with partial dates. I can't remember ever needing to write code that handled dates in the form of strings that didn't even include the year. So that's not really a bonus. Come on, admit it: the US convention simply makes very poor sense - a fact supported by the fact that almost the entire rest of the world does it the other way round. Also, the metric system is great, not sure what you've got against that as well.

To be clear, the long delivery times were because the manufacturers couldn't make them fast enough to keep up with the high demand. I don't know which model you had, but I have a (type 1) model B, and it runs various distributions of XBMC/Kodi (i.e. Xbian, OpenELEC or OSMC) just fine. It is very slow updating the catalogue, though, so I don't have it do that at startup. It was annoyingly slow to respond to user input for a while, but I updated to a new version of Xbian and that sorted it.

Surely an advanced programmer should have little trouble using the stack trace and/or basic debugging tools to trace an error back to a /0 event? Or should be aware of when a 0 input is liable to cause problems and put in special handling for it? After all, even in a statically-typed language you won't get the error until runtime so you need to be aware of the pitfall when coding. I personally prefer it the way it is, since as a dynamically-typed language JS can handle a /0 without having to throw, and for all the interpreter knows it may be that the result is being handled correctly even when it is not a number, so for JS to throw an error at run time, and potentially in production, when it is by no means a given that an error has occured or will be caused by it, would be bad.

The thing is that that exception may not appear until your application is live. I don't think Javascript should throw application-crashing runtime errors in order to help you identify conditions in your code that may not even be bugs.

I should have put my statements the other way around. Your response to the one you quoted is fair enough, but your point is predicated on the assumption that the result of a division by 0 must always represent an error that should have been avoided before that point. This isn't necessarily the case.

PIEBALDconsult wrote:

keeping the application from crashing is the application developer's job

The language shouldn't crash the application unnecessarily, though. The result of a division operation isn't necessarily useless or invalid just because the divisor was 0. If you want to test that x/y === 10 then when y equals 0 you probably just want a false result, not an unhandled exception. This behaviour means that you only have to put in special-case handling for y === 0 if you need it. At the same time, if your use case does require it but you forget to put it in, then you'll probably get the error thrown anyway when you handle the result of the division, rather than the bug being masked.

But if it didn't do this you would just always have to test the inputs instead to ensure the application doesn't throw an error, which isn't necessarily any better. Besides, it's possible you may not have to test the results anyway, if you aren't relying on them being a number, e.g. in the below code it doesn't matter if b is 0:

if(a / b === 0.25){ ... }

Fair enough, *if* Spartan is significantly better than Firefox or Chrome (at least for your specific purposes) then yes, why wouldn't you switch to it? But that's a big "if". I don't really understand why you seem so desperate to abandon Firefox and Chrome. Most power users will already have the FF or Chrome extensions they want and also use their respective session sync services across machines and devices, and won't suddenly switch to Spartan just because it uses less memory and happens to be the default browser with Windows. If Spartan has a vibrant extension ecosystem, and a session sync service, and an Android/iOS client, and looks nice, and has a decent interface, then I will _consider_ switching to it. But somehow I doubt all that will be the case.