Out of interest, BronsCon, how do you imagine those robberies would have gone if you'd had a gun of your own? I mean, would you have been able to point a gun back at them? And if so, what would have happened then?

I mean, it must be reasonably terrifying to be robbed at gunpoint, but I don't think putting an additional firearm into the situation is likely to improve matters.

Perhaps I'm wrong. It certainly seems that you Americans are altogether too fond of your guns.

Actually there's another issue here - Android's security model asks for all the apps permissions before you even get to install it. Whereas on iOS, permissions are asked for by the OS when the app attempts to access the protected APIs. iOS's model is far superior, since for one thing you get a feel for what the app wants the permissions for, and for another you can decline without un-installing the app.

So if a rogue game app were to suddenly ask for permission to access your contacts, you would be able to say 'no'. On Android, you get asked up front and (almost) everyone just says 'yes'. Doesn't work.

This is something I really completely and whole-heartedly agree with.

Related: At a conference earlier this year, a speaker made the point that since hardware speeds are not increasing at the rate they once were, it now makes more sense than ever (and it always made sense) to optimise your code.

Of course, it sounds like the type of optimisation you're talking about is basic algorithm choices and understanding complexity. Which is CompSci 101, but does rather appear to be on the wane. I guess that's a rant for another day.

That's completely true. But it remains the case that many of C++'s features can be used on those types of devices, and smaller ones too, and that includes templates. Though on programs of the size one tends to find on microcontrollers, there probably isn't much point. You certainly don't want to be dynamically allocating memory, but that's got nothing to do with C++ specifically anyway.

But you're certainly never going to running Java or anything else on those things. It's Assembly, C or C++, and that's it.

Yes it is.

This isn't necessarily true. Well-written templates will defer to base implementations that avoid duplicated code. For instance, templated containers of pointer types should all wind up using the exact same implementation, with the type-safety only being there to keep the compiler happy. That same implementation may be usable for any trivially-copyable data of the same size.

Templates and macros are really not even close to the same thing.

You know it's funny, but I do take issue with the suggestion that shadertoy is written in javascript. It's not, it's written in whatever they call that shader language these days. The javascript just ships a bunch of shader code onto the graphics card, and then sits back and takes the credit. It's not even really HTML5 either, it's just a bunch of code running on your graphics card.

If you were to attempt to write an actual game in HTML5, with things like physics and opponent AI and all the stuff we've grown to love, then the story gets a little bit different.

Also, the Unreal Engine has been written in asm.js, which isn't HTML5 or javascript either. And is even further away from general acceptance and widespread support that HTML5 is.

Jewellery should also be a work or art, or at a minimum superbly-crafted artisanal items, there's nothing "mere" about it.

Right. But on the other hand some people are demonstrably using a VPN to foil geolocation of their IPs. Since Hulu are required to ensure that those who view their videos are in the US, and since they can't ensure that this is the case for those behind a VPN, they have no choice but to block VPN users. Sucks, I agree, but there it is. If you were bound by those licence terms, what would your argument be for allowing known VPN IPs?

The whole business model of refusing people's money because of where they live is pretty spectacularly retarded, but some people clearly think it's a good idea, and some of those people run Hulu, and that's the end of that.

Well maybe. I'd argue the problem is the extent to which C allows you to shoot yourself in the foot, and therefore its suitability in security-critical environments like openSSL.

I'm sorry, but that's a really silly argument. You can't create a significant number of people doing a particular thing by doing the 'big number times small number = medium size number' trick. We hear that from marketing here at work, and it doesn't make any sense there either.

This. Have you seen the code that the heart bleed bug lay within? This love affair with bare-metal C, with hand-managing memory, etc etc - needs a really hard re-examination. Calling memcpy in a security-critical application? Seriously?

They may well think that - but the point is that they're wrong. Isn't it better to know that, than to continue to labor under the misapprehension that you're doing something useful?

But firmly believing that you absolutely do have the 'flu, will also cure your 'flu. So I'm not completely sure what your point is.

I submit to you that even if there were no god, you would still know that it was wrong to hurt other people. I don't see why we need to imagine the existence of an external arbiter of morality to support that it's a bad idea to hurt each other. And that honesty is probably a good plan too - and that it's not generally conductive of a productive society to steal each other's shit.

It seems to me that these moral rules are pretty damn self-evident. I don't believe in a god of any kind, let alone a Christian one, and yet these moral laws seem obvious.

Be nice. Be nice to other people. Why do we need a supreme being to work this one out?

Ok, fine that's all great. I get that.

But why, then, would this great experimentalist want us to worship him?