Simon Peyton-Jones from Microsoft Research in Cambridge enthused about transactional memory during the “Sneak Peeks” session at Mix07 in the UK.
I have mentioned this before on this blog; it is also favoured by Herb Sutter as a better way to do concurrent programming.
Peyton-Jones says it will eliminate a whole class of bugs from our code; perhaps this was one reason for the warm reception for his presentation.
He is a Haskell fan, and says this is best way to experiment with transactional memory now. It is not something that can easily be introduced into other languages, but will require some radical re-engineering.
Technorati tags: transactional memory, haskell, simon peyton-jones, mixuk:07, mix07, microsoft
One development I would really like to see come to fruition is a proper transactional file system. This is, admittedly, based upon my horrid experiences writing countless VBScripts to install and maintain packaged software in a corporate environment. I find that the burden this kind of script writing imposes on one results in constantly looking over your shoulder to make sure that certain tasks have been performed. Then, when (not if) it goes wrong on installation you have to make sure that you can back out.
The best solution on the table at the moment is something like the Windows Installer: a sprawling mess full of heffalump traps for the unwitting sofware author to fall into. What was it you said about it some time ago, that it had about 74 caveats you had to be aware of before you were using it properly?
Now, how about a transactional file/registry/general storage system that you could use from an advanced scripting environment like the Powershell? If the whole thing goes wrong, due to say lack of filespace, you just issue a rollback command and the system is exactly as it was before you started. I’m not saying that the Installer wouldn’t have a role when installing to such a system, just that it would be a good deal less complicated – and that can only be a good thing.