Lambda the Ultimate

The problem of void calls, or null pointer dereferencing, plagues programs written in any language using pointers or references with a "null" or "void" value. Tony Hoare recently described it as his "one-billion dollar mistake". The problem is very simple to state: in the typical object-oriented call

x.f (args)

x, a reference, should normally denote an object but can be void, in which case the call will fail and produce an exception, often leading to a crash. This is one of the main sources of instability in today's software.

The void-safety mechanism of Eiffel, as defined in the ISO/ECMA standard (2006), is now fully implemented in EiffelStudio and guarantees the absence of void calls. With version 6.4, beyond the mechanism itself, all libraries have been updated to be void safe.

With Alexander Kogtenkov and Emmanuel Stapf I wrote an article describing not only the principles but also the delicate engineering issues that we have encountered and tried to address in making Eiffel void-safe. An abstract, and a link to the PDF of the article, can be found at http://bertrandmeyer.com/tag/void-safety/.

Alex Stepanov and Paul McJones's Elements of Programming has been published by Pearson/Addison Wesley. I picked up a copy at the Siggraph conference in New Orleans and skimmed it on the plane home. Under the covers it's an apologia for STL, and as such will doubtless stir debate. Examples are written in an extremely spare dialect of C++.

The slides from Tim Sweeney's High Performance Graphics 2009 keynote expand upon his Next Mainstream Programming Language talk we discussed some year back. To summarse, Tim makes the following points (in my interpretation):

• The current GPU pipeline is too limiting and too difficult to program
• The CPU roadmap from Intel and others show a convergence between the CPU and GPU. We're going to see a lot of cores with vector units hanging off a shared cache. The cores are getting simpler but programming them is getting harder
• Programs that are purely functional can be automatically vectorised, and the new CPUs are going to extend the scope of vectorisation to general programs
• Economic reality demands tools to make programming this hardware easier. New languages seem the only viable way forward

It's an interesting talk with a bit more detail at the bit-bashing end than previous talk. The question is: who is going to make this language?

A quick link (and one that will cause google haters to jump on me, surely): http://googleresearch.blogspot.com/2009/08/under-hood-of-app-inventor-for-android.html

Does anyone have any reference material or thoughts on the idea of a method in an object oriented language always being allowed access to the sender of that message? It seems to be universally true that the sender of a message is unknown to the method unless explicitly passed as a parameter. I'm curious as to why that seems to be the default assumption. My gut instinct is that the rationale is connected with the idea of preserving encapsulation, but I wonder if that's really been tested or if that's more of a gut feeling that's been passed down through the years? (I know of no language that would prevent a sender from sending a reference to itself along as a message parameter - and indeed that is a common way around this limitation when the need arises. Why enforce the barrier in one case in the name of encapsulation, but not another if that is indeed the reason?)