OOPSLA report

OOPSLA was great. I got a lot of positive comments and encouragement. It was quite heady to have established researchers, whose work I respect, introduce themselves and tell me that they liked my work. Perhaps a bit too heady: it wasn’t until the last day of the conference that I realized I should be using the opportunity to seek criticism and advice from the masters. Continue reading “OOPSLA report”

Now Playing

I have produced a Flash video of my upcoming OOPSLA presentation. It is divided into two parts, both about 15 minutes long. The first part recapitulates the previous video of building a factorial function. There are some new features, but if you already watched the older video, you can skip it without missing much. The second part demonstrates my new approach to I/O and mutable state.

I am excited about this development, not only because it addresses a big problem lacking good solutions, but also because it is going beyond “mere” usability issues. It has been easy up till now to dismiss my work as just repackaging standard language semantics into a different user interface. Now I am starting to show that fundamentally changing the way we represent programs can fundamentally change the way we think about them.

As always, please let me know what you think.

[10/24/05: updated the slides at the very end to match what I actually presented at OOPSLA]

The Currency of Development

One of the anonymous reviewers of my OOPSLA paper made the point, paraphrasing, that the main problem in software development is not the difficulty of programming, but the difficulty of getting a development project to function effectively. This is usually seen as the subject of methodology, with “extreme” and “agile” methods being the latest trends. My initial reaction to this criticism was to point to the example of spreadsheets, which make a certain class of problems simple enough to be solved by an end-user or power-user themselves, without enduring the trials and tribulations of a professionally staffed development project. Even on such multi-person projects, reducing the programming effort ought to reduce the size of the team and the number of interactions subject to error. However the fundamental point of the criticism remains true: the biggest problem in software development is teamwork. It has occurred to me that the design philosophy of Subtext can contribute to solving this problem. Continue reading “The Currency of Development”