Economics, in it's current form, is not much better that Ptolemy's vision of an Earth centric universe. Sure you can add cycles to explain the observations of planets, but the paradigm is not useful for making predictions.

Economists need to learn how to model the economy as it actually is, instead of making so many simplifying (and wrong) assumptions as to make their models useless. They need to learn from fields like weather forecasting, where complex dynamics have been embraced.

If it looks like a tail call, there's a pass that will turn it into a tail call. I think there's even a pass that can turn recursive code into a state machine.

I hope they do something like redgrep. Using the LLVM backend to compile the regex state machine into actual machine code.

FTFY

The housing bubble did actually stimulate the economy. Not because of construction, but because we borrowed all of that money from the banking sector, then spent it to keep the economy going.

But what goes up, must come down. It's inevitable that when we collectively try to pay back (or are forced to default on...) our mortgages, our income and money supply will shrink. Austerity policies will hasten the inevitable.

Pointing out a flaw in someone else's software should not, by itself, be a criminal act. Once the information is public, automating the exploit could be done by anyone proficient in the art.

But selling a tool that uses the vulnerability? They crossed a line, but throwing the book at them seems a little harsh.

Use the same USB trick, but run your OS in a VM under the TreVisor hypervisor. When the USB device is removed simply put the machine to sleep.

TreVisor only stores your encryption key in the debug registers of the processor. It places restrictions on running op-codes to read these registers or to overwrite itself via DMA. It encrypts both the disk and inactive pages of memory.

Once the CPU suspends, the debug registers are lost and you have to enter your passphrase before the guest VM can do anything at all.

A junior programmer fresh out of Uni, joining my team. Learning a new language / framework / application, working full time. Will usually take more of my time to help them than if I just wrote the code myself. I have to explain which existing functions they should use. I still have to flesh out most of the design and implementation of the tasks they are assigned. I may need to take over their keyboard and type some of the code in for them, as the fastest way to get the point across that I'm trying to teach them. And getting their patches up to scratch can take a number of iterations.

After about 3 months, this equation should start to shift. Even though they will still take far longer to complete a task than I would, it should take less of my time to get the same work done. At this point, the addition of someone to the team starts to pay back the initial training period. We can evaluate if this new person is still worth investing time in.

And that's for the graduates that I'd consider hiring in the first place. Most CompSci graduates I wouldn't consider employing at all.