Wadler's Blog

A survey by François Pottier, which links a number of concepts and clarifies a cluttered landscape. Spotted via LtU.

Perhaps not too surprising, as Hal Abelson (of SICFP fame) is involved. Spotted by Mitch Wand. Thanks, Mitch!

I recently came across two excellent resources on climate change, and also list a third which I encountered a couple of years back.

• Sustainable Energy - without the hot air by David McKay. The following is quoted from the excellent ten-page synopsis. The entire book is available for free on the web

  Where numbers are used, their meaning is often obfuscated by enormousness. Numbers are chosen to impress, to score points in arguments, rather than to inform. In contrast, my aim here is to present honest, factual numbers in such a way that the numbers are comprehensible, comparable, and memorable. The numbers are made accessible by expressing them all in everyday personal units. Energies are expressed as quantities per person in kilowatt-hours (kWh), the same units that appear on household energy bills; and powers are expressed in kilowatt-hours per day (kWh/d), per person. ... [F]or example, driving an average car 50 km per day uses 40 kWh per day.... [and] covering 10% of the country with wind farms would yield 20 kWh per day per person on average.
  
  One reason for liking these personal units is that it makes it much easier to move from talking about the UK to talking about other countries or regions. For example, imagine we are discussing waste incineration and we learn that UK waste incineration delivers a power of 7 TWh per year and that Denmark’s waste incineration delivers 10 TWh per year. (1 TWh (one terawatt-hour) is equal to one billion kWh.) Does this help us say whether Denmark incinerates “more” waste than the UK? While the total power produced from waste in each country may be interesting, I think that what we usually want to know is the waste incineration per person. (For the record, that is: Denmark, 5 kWh/d per person; UK, 0.3 kWh/d per person. So Danes incinerate about 13 times as much waste as Brits.) By discussing everything per-person from the outset, we end up with a more transportable book, one that will hopefully be useful for sustainable energy discussions worldwide.

• Software Engineering for the Planet by Steve Easterbrook, a presentation at ICSE 2009: slides part 1, slides part 2, discussion. Challenges computer scientists to tackle the problems that will let them answer the question "Daddy, what did YOU do during the climate crisis?" Lists the unique resources we have to bring to bear on one of the key problems facing humanity.
  
  
• Heat by George Monbiot. Argues that we need to reduce carbon emissions by 90% by 2030, and lays out a plan to achieve this Herculean task. Attacks sacred cows on both sides of the arguments, both those with their eyes shut to the problem and those that think windmills on houses are the answer. Doesn't hesitate to point out radical solutions that could work (he envisions how we could replace most use of cars by a sensible network of trains and busses), or to reject solutions that can't work (after extensive consideration of the alternatives, he concludes with regret that the only way to reduce carbon from air travel is to reduce air travel).

A joint study by The Royal Academy of Engineering, the Institution of Engineering and Technology and the British Computer Society. The authors include Tony Hoare and Martyn Thomas.

"This study was undertaken by a group of Fellows of The Royal Academy of Engineering, the British Computer Society (BCS) and the Institution of Engineering and Technology (IET). The group focussed on how greater professionalism could be brought to bear on the tasks of specifying, procuring or developing software-based IT systems."

The report comes down strongly in favour of promoting chartered engineer status for IT professionals (which is currently rarely found in practice). The introduction notes university courses should reflect "the fact that most developments involve modifying or interfacing with pre-existing software." The conclusion points out "Testing is not enough" and "Errors should no longer be regarded as inevitable".

Objects as Modules in Newspeak, by Gilad Bracha et al.

We describe support for modularity in Newspeak, a new programming language descended from Smalltalk and Self. Like Self, all computation — even an object’s own access to its internal structure — is performed by invoking methods on objects. However, like Smalltalk, Newspeak is class-based. Classes can be nested arbitrarily, as in Beta. Since all names denote method invocations, all classes are virtual; in particular, superclasses are virtual, so all classes act as mixins. Unlike its predecessors, there is no static state in Newspeak, nor is there a global namespace. Top level classes act as module definitions, which are independent, immutable, self-contained parametric namespaces. They can be instantiated into modules which may be stateful and mutually recursive. Naturally, like its predecessors, Newspeak is reflective: a mirror library allows structured access to the program meta-level.

A simple, principled, and intriguing language design.

Decades ago, one of the major advances in programming language design was the claim that programming-in-the-small and programming-in-the-large require different constructs. Newspeak (along with Scala) reverses this trend, claiming classes are a good fit for both.

Type families represent a key example of program structuring that is difficult to support with current type systems (see, e.g., 'A statically safe alternative to virtual types' Kim B. Bruce, Martin Odersky, and Philip Wadler, ECOOP 1998). Newspeak, by virtue of using late binding everywhere and having no type system, supports type families easily. Thus, I view Newspeak as posing a key question: what is the type system that will support type families as elegantly as Newspeak?

Newspeak's innovation of prohibiting a global namespace is also interesting. Although Newspeak is very much an imperative language, this aspect is right in line with functional languages, as it argues that sometimes making a dependency painfully explicit is the better course, as it supports parameterization and reuse. In particular, this provides a simple and principled solution to the same problems tackled by complex frameworks for dependency injection.