Your list was interesting, and seems accurate with respect to the direction of agile development and the continuing debate in that regard. This topic, while large in and of itself, is nevertheless a narrow part of the overall question regarding research versus practice; the title of your article made it seem as though you were addressing that broader question. In that vein I wonder if you would consider widening the question to encompass all aspects of the relationship between computer theory and practice. Yes, it's a challenge, but one that I think would be of interest to the whole community.

Over the years, I have mainly been a practicing engineer, but I have done research and still keep my nose in that world. I have observed that, in more than one area of computer science, the gap between theory and practice is very wide, perhaps wider than almost any other field wherein you will find an engineering counterpart to the science. In programming languages for example, where I spent considerable time writing compilers and related tools, the academic side stresses a very formal mathematical approach, and most languages developed from those roots are not embraced in practice. In fact, the realm of industrial languages is almost a completely different, parallel universe.

Of course, it's not a black-and-gap, but large portions of the academic side of computer science are clearly not driven by the needs of practice per se â?? nor do I think they should be. But many researchers want to have this sort of connection, and are thus torn between the academic pull to deal with idealized theoretical problems and the pull of practice to deal with messy real-world problems.

It's these people who I think would be interested in the broader question. Some of my top items are:

1. Analysis of programs across languages and similar boundaries: For instance, in static or runtime analysis much has been done within a given language, and researchers take it deeper and deeper. But few if any systems are useful when a computational boundary needs to be crossed: call into a database, invoke a shell command, send messages from one process to another, and so on. Yet systems built from such heterogeneous sets of methods are common and what we have to deal with every day. (Note that "heterogeneous" is often just a kind way of saying "hodge-podge".)

2. Producing new languages that have a real effect on the efficiency of programming: Academia has focused on semantics, types, etc., and provable properties of programs expressed in typically idealized languages, many of them variants on lambda calculus. But not that much is going on in allowing the concise and possibly ambiguous expression of intent, with the language system resolving the details. Most practical work in that realm has been in industry, via domain-specific languages and systems, such as those for business apps or GUIs.

3. Large scale for the masses: Grid, Lambda-Net, and so on are largely "academic engineering" in the supercomputer space, providing tools to other sciences like biology, physics, and astronomy. These are highly idealized, elite settings. It took the cloud movement to get academia to look at large-scale models for the common man. I would like to see more leading-edge research here.

I should mention the other side of the coin: Researchers developing things that don't fly in industry, but are nevertheless practically-oriented. In this space we have, for example, the parallel-processing movement which peaked around 1990. Many of the techniques were pioneered in academia, then moved to industry where they had a relatively brief life in the high-end machine market. That dwindled, but now it's back because hardware vendors have declared we've hit the cycle wall. Academia was just ahead of the curve!

I hope to see an expansion of your studies.

Thanks,

Larry Stabile
Senior Architect
Iron Mountain Digital

Posted on 8/25/10 4:30 PM.