Lots of stuff in flight, waiting to see whether it gets accepted or not. Also, I'm deep in the thesis-writing process.
Anyway, we've memoized an amorphous computing paper that got rejected, since it might be a while before its next turn around the wheel of submission:
Building Spatial Computers, Jonathan Bachrach and Jacob Beal, MIT CSAIL Tech Report 2007-017, March 2007.
This was a submission to HotOS, talking about the operating system level problems of building Proto and making the amorphous medium abstraction actually work. Half the reviewers thought we'd already published the paper---no! This is the one where we actually talk about implementation, rather than sweeping it under the rug to focus on why somebody should care about our abstraction. A third complained that we didn't focus on the programming abstraction. The fourth had good, helpful feedback that will actually help us on the next turn of the wheel.
It seems to me like there's a fundamental problem in trying to present a non-incremental change in a computer science paper. If you try to present it all in five to ten pages, you can't give enough details to satisfy anybody. If you slice off a bite-sized chunk to talk about, then either you've already published on the idea or the reviewers complain that they wanted the other parts. I don't know whether other fields are like this too, or if this is just to be expected when you're working on problems that don't come with a pre-existing focussed sub-community dedicated to their study.
If I were a better writer, I might know how to present things to get the readers to reliably take that leap in five pages. For now, I'll keep struggling and getting frustrated every time I get a review that says something like "But why aren't you programming in C?"
