After five years, I remembered that I started this blog! Timely, now, because I'm finishing up a project I began years ago. It's time to fill people in on what I've been doing in the interim.
The short answer (which has been no great secret) is: Writing a book. Well, in addition to lots of other stuff. That invariably leads to more questions, that I rarely have time to answer, regarding what the book is about, why I've been driven for so long to complete it, why I think it can still be timely after all these years in a "rapidly moving technology field", etc. Let's see if I can answer some of those here without just rewriting the book in blog form, or interfering with its impending completion.
As most know, I am a computer guy -- PhD in Computer Science, worked at NASA Ames (I think my last title there was Senior Research Scientist), was involved in "cloud computing" there before it was called "the cloud" (usually instead "the grid", or more syllably-challenging, heterogeneous distributed computing). And my specialty is parallel processing, which, simply put, is getting lots of computers to work together on the same problem at the same time, usually to try to speed up the result. And, yes, the book is related to that.
But this book is not just for other "computer guys" (gender neutral "guys", feel free to substitute "dudes", or even "gals"). It is, more generally, about planning and concurrency, and specifically, about (scalable) planning for concurrency. In this context, a plan is considered as a description of some desired activity, to any desired level of specificity (or lack thereof), and concurrency is the property of having multiple activities occur in potentially overlapping time-frames.
So, if one considers an algorithm or computer program as a plan (and I do), and computer processes as activities (which I do), and parallelism as an example of concurrency (which I do), then one can indeed see how insight into planning for concurrency can also provide insight into parallel programming (and processing).
But a plan can also be the way a device, or an office, or an organization, is intended to work. And concurrency can describe the way that parts of that device or office or organization can act at the same time, often toward a single goal. And my book attempts to embody the concepts of planning and concurrency at a level which perhaps can be utilized in such diverse areas as those. Some of the examples I provide in the book are anything but computer-like -- perhaps the main one being a description of the activity of making and serving waffles, and having people request and eat those waffles.
But I do not consider my main contribution here as the broadening of planning and concurrency to fields other than parallel programming/processing. In fact, I am hardly the first person to use non-computer examples for concurrency (consider the candy machine example for Communicating Sequential Processes, CSP), and I don't even know how successful I will be at that particular goal (though I have hopes), so I am ensuring that parallel programmers will find plenty of meat here in traditional computer-oriented applications that they care about. No, the main contribution of the book is in the approach I am using to represent and reason about concurrent plans, something which I've worked on (intermittently, at least) for over two decades. It's called ScalPL, and I believe it is more intuitive, more precise, more flexible, and often more efficient, than approaches that others have been pursuing for that period. Yet although this representation is "novel" (to almost everyone) and different in form and function than existing textual approaches, it accommodates traditional (sequential, even object-oriented) approaches and reasoning in natural and often surprising ways.
It is difficult to justify such a divergence from accepted practice on a piecemeal basis, which is exactly what led me to write this book -- to address all of the "but why don't you just"s and "X already does this better and Y already does that better" and "then you can't handle this other thing" and "how does that relate to Z" aspects, all at one time, the big picture. And that is why I now feel I can begin to toss out tidbits and features of the book (and of the approach) in this blog: Because there is now (soon) to exist a complete readable description of how all of the seeming leaks in the dike have been covered, in a considered, theoretically sound, and hopefully well-explained fashion.
More tidbits forthcoming.
