Iain M. Banks had the notion of a 'mind state abstract', where you'd send a copy of (part of) your mind and then either discard it or reintegrate. It would either be downloaded into a drone or biological construct, or just used in VR. It made a lot more sense to me than the transporter, as long as you solve the reintegration problem. Especially on a dangerous mission, I'd prefer to send a copy down and then merge their memories into mine if they survived...

Apparently I've not had enough coffee yet (or have spent too long staring at MIPS CPU traces to spot the error) and thought that you said the exact opposite of what you said.

More general hint: The principle of minimum scope exists for a reason. Declare your variables at the point where they can be initialised, not at some arbitrary point and you make life easier for people trying to understand the lifetime of the variable.

The issue is only when you pass standard library objects across a library boundary between two libraries compiled for different standard library implementations. It's perfectly safe to pass C and Objective-C values between libraries that use libc++ and libstdc++ internally.

This isn't even a good troll. If you don't know one actor-model programming language and one pure functional programming language, then you have no business describing yourself as a programmer. You certainly don't get to use your ignorance as the benchmark for others.

Various ML dialects had that before Python. The thing Python brought was a poor performance implementation of a language from the C++ school of language design: keep adding features without regard to how they interact and expect programmers to know all of them (if they ever work with anyone else) but only use a subset if they don't want totally unmaintainable code.

Understanding monads is very helpful if you're writing code that wants to do speculative execution or is highly concurrent, even if you end up implementing the code using something purely imperative.

Not everyone can learn to win Olympic races, but most people can learn to run moderately competently. Not everyone can learn to be a great manager, but most people can learn not to be an incompetent one.

For the branch instructions with the reused opcodes, this means that you need to do it up front. This means that things like JVMs and anything else with a JIT requires rewriting. This is where a big part of the cost of the software ecosystem comes from. It also means that disassemblers and debuggers (which are another big investment) also need significant rewriting, rather than just adopting.

Trap and emulate and trap and patch will only work if your MISPr6 processors have a special mode that will trap on any instructions that have had their opcodes reused. In such a mode, trap-and-patch usually won't work, because the compact branch instructions that are intended for use in the patching are in this set.

The new ISA is a lot nicer than classic MIPS, but it's almost as much effort to support in software as RISC V or ARMv8. This is part of the reason why we (with my FreeBSD hat on) have been working closely with Cavium on ARMv8 recently. Existing customers for Cavium's MIPS parts (certain storage and networking vendors) have looked at MIPSr6 and seen that the cost of migrating their code from MIPS III or MIPS64r1 to MIPSr6 is about the same as the cost of migrating to ARMv8. They've also seen the lack of serious investment in LLVM (until very recently, and even then it's far smaller than ARM alone - Apple, Google and ARM are investing an order of magnitude more effort than the MIPS ecosystem) and decided that it's worth working out the cost of an ARMv8 migration.

I mentioned this to Daniel over a year ago, but apparently ImagTec decided that keeping their customers' customers on MIPS wasn't a priority.

There are two problems with this idea. The first is that EMPs, like other EM phenomena, disperse via an inverse square law. Anything high enough to be line-of-site to the ground in most of the USA would need to have an enormous explosive yield (even by nuclear weapon standards). There are some designs that try to channel more energy into the EMP than normal, but they're very complex to build (a good 10-20 years more R&D beyond the Fat Man / Little Boy style bombs).

The second problem is the delivery. Iran does not have a significant ballistic missile capability. Getting something into space above the USA would require launching something in a suborbital trajectory. A very high suborbital trajectory if it were intended to explode that high up. The size of such a rocket would be such that it would be pretty hard to miss on satellite observation. The time in the air would give the US a very long time to formulate a response and destroying it would be relatively easy (remember, the problem with strategic defence shields in the cold war was not shooting down a missile, it was shooting down the large number of real and decoy rockets that the Soviet Union was capable of launching).

I was really surprised to learn recently that Chrome's support for OS X 10.6 is one of the main things blocking Skia from adopting C++11 library features (i.e. the things that make C++ not completely suck as a language). 10.6 has been officially unsupported for over a year and the last security update was a few months before that. It has known security holes (including one from missing bounds checking in DMA requests to the GPU that allows privilege escalation and might be exploitable from WebGL). Keeping these machines on the Internet is not really doing anyone a favour.

It's also a bit surprising that Chrome on 10.6 can't just bundle a copy of libc++.dylib, since none of the system APIs are C++ and the only problem with linking libc++ and libstdc++ is if you use standard library types at library boundaries.

Even if we didn't nuke Iran in response to an attack on Israel, you really don't want to be using high-yield nuclear weapons on someone that close to you - fallout blows in the wind quite a long way. The USA, Russia, India, and China are all good targets for strategic nukes, but smaller countries are likely to end up not containing the effect and Iran would be very unpopular if they covered their neighbours in radioactive dust. Given that they're already quite unpopular with their arabic neighbours, they'd likely expect a fairly large conventional response if they fired nuclear weapons anywhere in the middle east.

My girlfriend has one (she wanted one with a good camera and the Nokia Lumina some-unmemorable-number had the best one). The UI is nicer than any other phone I've used, but the selection of apps is a big limitation. Around half of the things that I use on a regular basis on my Android phone have no Windows phone equivalent. Being able to run Android apps would make it much more attractive.

BERI (our processor) has register renaming, forwarding, branch prediction, and so on (and can boot a full 64-bit OS), but it is not exactly like an industrial processor because it simply doesn't make sense to use the same techniques when targeting an FPGA as an ASIC. For example, most of our TLB is direct mapped, because block RAMs are very cheap on an FPGA so we can have 128 TLB entries in a BRAM and look them up based on a hash of the virtual address. Some techniques such as the nearly-associative memory stuff from UPenn can improve this. On an ASIC, this would be a silly way of doing it, as TCAMs are cheap (on an FPGA, they use large numbers of logic units and so burn through area very quickly in comparison to using the BRAM blocks). Generally, people who prototype ASICs on FPGA don't care much about the performance of the FPGA instantiation (or the cost, as the most expensive FPGAs are orders of magnitude cheaper than a fab run).

Showing an industrial core is not really possible. MIPSfpga is actually simpler than BERI in a number of ways (though, being written in Verilog, likely to be much harder to understand than something like BERI or Rocket). A real core aimed at anything other than the embedded microcontroller market is going to be impossible to get access to. The kind of things that are substantially different from BERI or Rocket are the high-end out-of-order superscalar chips that no company is going to show you without paying a very big license fee.

The Ribbon wasn't too bad as an idea. Unifying the toolbar and menu bar makes a lot of sense, though on small-screen devices it was a problem. The thing that made it a UI disaster was automatically moving things around, breaking muscle memory and making it impossible to use anyone else's version of Office.