PDC 2009 Day 2: Microsoft Perspectives on the Future of Programming

An impressive array of speakers is sitting on the podium in front of us, taking live questions from the audience using Twitter. Here are some of the interesting thoughts provoked by these questions:

Worried About

Some of the things that the speakers are “worried about”: Concurrency, dependability (taking dependencies we don’t understand), developing rich applications easily, providing simple programming solutions and still give experts the opportunity to “complicate”, how do we make database access viable.

Concurrency and Parallel Programming

How do we do parallel programming simply? One take on it is that LINQ makes it easy to write parallel programs. Not all problems are easily decomposable in a way that allows for parallelism. The industry needs to do for parallelism what was done for GUI and for objects during the past decades with VB 1.0, MFC 1.0 and so on.

The biggest problem that remains is what to do about state, as opposed to functional style (like SQL). Dealing with state in a parallel program is the biggest problem.

Transactions

What about transactions? Are transactions in software or database the silver bullet that solves the problem with concurrency? Transactions are great when they work – they are like fairy dust. STM is another direction that has to be addressed in somewhat untraditional ways. Even if there are no transactions in the language for you, make sure every method on an object takes the object from a consistent state to another consistent state, even in face of exceptions – which is another hard thing to do.

Software tends to work when it works, and fail when it fails.

Don Box says that there will be support for optimized transactions with the in-memory coordinator and SQL Server, so if the transaction is only between these two RMs, there will be no distributed transaction (no two-phase commit, etc.). This is good news for software transactional memory.

Another observation: Transactions must be small. Big transactions don’t work. Big transactions work too, but require nesting and complexity management among multiple transactions.

Type Safety

For Herb Sutter, type safety would mean that an object can be used if all its invariants are met. (E.g. its constructor has run and completed, and its destructor or finalizer has not started to run yet.) Don’t rely on the type system for everything.

Herb Sutter: You can design a language without null pointers, but oddly you still have a NullPointerException!

For the question of whether you can live without pointers – well, even if you don’t have them, there is great (irreplaceable) value in having the semantics of a thing and a reference to the thing which is not the thing itself. It’s next to impossible to design a useful language that has only value semantics, and no references.

Boundaries

How we should treat distributed problems – make boundaries clear or hide them implicitly? Differences that don’t matter should be hidden; differences that matter should be explicit in the developer’s and user’s face. This applies to all boundary transitions. On the other hand – taking this to the extreme, the path between the cache and the RAM should also be made explicit.

Computation Diversity

How do we leverage the GPU? It’s underway, and what seems to happen is that there will be more diversity in the types of processing units, especially seeing that processing-power-per-watt considerations become more eminent. [See Multikernel about an OS targeting diverse types of processing units.]

With lots of variety in the hardware, languages, programming software – the interesting question becomes how to glue these components together, and glue becomes the most important factor. The answer is not any particular runtime.

Herb Sutter: No one wants multicore! We would like faster chips every year but we can’t get them anymore, and therefore we have to work hard to parallelize applications. [See “The Free Lunch Is Over”.]

Modeling

Is modeling the answer and we can stop modeling? We’ve seen a trend of extracting parts of the program specification to lots of external files (be it XML, DB, .ini files). Representation of the intent (instead of programming, implementing this intent) is meant to be easier. [Is it really?]

Also, if you have the model – you can reason against the model instead of against the program. On the other hand, static analysis (such as compilation – AST construction) are examples of reasoning against a program which is perfectly viable.

Modeling allows for proving theorems about programs. Extracting a model from a program is one thing, but having a declarative basis for the truths of a program (such as invariants) such as they can undergo formal verification is a whole different thing. And when faced with formal verification of programs and theorem proving, the question has to be where the theorem comes from? (The specification can be harder than the program to write. Right now we don’t have declarative means to specify the theorems that we want to prove about the program.)

Miscellaneous

Stanley Lipman: There are many pages on amazon.com that don’t work quite well or serve incorrect information. But it doesn’t matter if they serve 5% incorrect information. The only page that absolutely has to be right is the big orange Order button!

Herb Sutter, while answering a question about garbage collection in C++: “… what was the question again?”, the panel host: "His memory has been garbage collected!”

Graphical programming environments are useful when they are useless (five things on the screen, demos) but useless when they need to be usable (five hundred things on the screen). Don Box: “You will have to peel the text editor out of my cold dead fingers.”

This doesn’t mean we have to store programs as text, but we can use a more structured way. [See Kirill Osenkov’s structured program editor.]

All in All

The conclusive question: What will we talk about in 5-10 years? Some answers: Parallel programming, safety, composability, reliability. Another answer: What happens when Moore’s Law ends? After all, you can’t go exponential forever and then optimization will go very very sexy again.

All in all, there was quite little discussion of the FUTURE, which was the title of the talk. Nonetheless, there was some interesting insight.