Lambda the Ultimate

A write-up of the Commercial Users of Functional Programming meeting held this October is available, for those of us who didn't attend. The write-up is well written and thought provoking (it was written by Jeremy Gibbons, so that's not a surprise).

The goal of the Commercial Users of Functional Programming series of workshops is to build a community for users of functional programming languages and technology. This, the fourth workshop in the series, drew 104 registered participants (and apparently more than a handful of casual observers).

It is often observed that functional programming is most widely used for language related projects (DSLs, static analysis tools and the like). Part of the reason is surely cultural. People working on projects of this type are more familiar with functional programming than people working in other domains. But it seems that it may be worthwhile to discuss the other reasons that make functional languages suitable for this type of work. There are plenty of reasons, many of them previously discussed here (e.g., Scheme's uniform syntax, hygiene, DSELs), but perhaps the issue is worth revisiting, seeing as this remains the killer application for functional programming, even taking into account the other types of project described in the workshop.

A short audio presentation (Avi speaks for less than ten minutes, I guess), about the lessons the Ruby community should learn from Smalltalk. It's mainly about turtles-all-the-way-down, but Self (fast VMs), GemStone (transactional distributed persistence), Seaside (web frameworks) are also mentioned briefly.

David Lorge Parnas keynote from Oopsla 2007 is available as a podcast.

Computer Scientists have been talking about the use of of object-orientation (under a variety of rubrics) to achieve "separation of concerns" for more than 40 years. In all that time, it has been taken for granted that it was the structure of the program text itself that mattered. Whenever it was felt that additional information was needed it was assumed that this would be closely associated with the program text either as simple comments, as in-line assertions, or "woven" in with the program text using elaborate tools.

This talk takes a different position. It argues that for true separation of concerns we need an integrated set of separate documents, some of which are to be read by people who will never read the code, some that describe the structure of the code, and some that describe the behaviour of individual components. It describes a collection of mathematical ideas and notations that make it possible to produce documentation that is both precise and readable. We then describe the use of these documents in testing and inspection. Finally, it discusses the way that other programming paradigms, particularly functional programming, can be used to make these documents more useful.

In it he discusses the Table Tool System (TTS), a system for writing precise software documentation. He quotes some impressive quality results from using this system when developing real world software.

I ask the LtU community to comment on this as he mentions the fact that the tabular notation his group has developed is precise enough to allow the execution of it for e.g. testing purposes, although very inefficiently. It might therefore be interesting to ask if the TTS in fact constitutes a new programming language in itself (it seems to me it does) and whether it's just waiting for an optimizing compiler writer to come along. From the podcast I gather that the notation is in fact written in a pure declarative/functional style and it might be interesting to explore whether the tabular notation could be useful for writing code for an existing functional language and reap some of the benefits he claims, such as the "code" being accessible to non-programmers.