Is the book about planning? Or parallel computing? Yes.

A few months ago, I said I'd be blogging about my new book... and now that it is really finally out (see www.elepar.com), it's time to actually do so!

The name of the book is "Scalable Planning: Concurrent Action from Elemental Thinking".  Wait!... Before you close this tab while muttering "I don't care about planning, whatever that means," let me explain:  I don't self-identify as a planner, either.  My "thing" (for almost 40 years) has been software. Or more specifically (for the last 25 or so), parallel software. Or even more specifically, architecture (or platform) independent parallel software.  And more recently, this has meant finding ways to write computer programs so that they can execute efficiently on a number of different platforms (read "hardware"), such as on a traditional sequential computer, or a multicore system (lots of processors on one chip), or in the cloud (or the "grid," as they used to say), or on a cluster ("farm") of interconnected but independent systems (e.g. workstations), or on a graphics processor unit (GPU), or what have you -- including collections or hybrids of the above.  The goal is to write one program (or algorithm) that runs on any suitable platforms (or hybrid platform) available at the time.  That goal was conquered decades ago for sequential computers, with the advent of high-level languages and compilers, but not really well with parallel systems.  It leaves the term "parallel algorithm" as an oxymoron -- algorithm implies independence from platform, but parallel usually doesn't.

So what has that to do with planning?  As it turns out, a lot.  Software is, by definition, a plan, a description of activity that you want to take place.  And many of the problems inherent in platform-independent parallel software -- problems like nondeterminism, and efficiency (including dealing with relatively long communication latencies), and scheduling, and fault tolerance, building larger plans out of smaller ones (or delegating smaller parts of bigger ones to other entities), and just trying to make sure that everything works together as it should to get the answer -- are present in other planning problems as well, especially those involving multiple people, or offices/branches, or devices, that all need to work together to produce a desired result.  Together, but not too closely together.  (One of our slogans, "Working together independently", sort of sums it up.)  In these non-computer cases, the people, or branches, or devices are the platform.

Besides, if the book had been named something related to "parallel computing", many readers would have expected it contain computer programs, and to list traditional models of parallelism (e.g. message passing and/or shared memory and PRAM), or newer approaches coming out of research labs, etc.  Although this book has hints of such things (mostly in chapters that are explicitly noted as optional), it's really about how to avoid dealing with such things during the planning (e.g. programming) phase -- or, put another way, to express a plan in such a way as to make it easier for another entity (called The Director in the book) to address those issues (like communication styles) later when the platform is known.  And the shape of that platform may even shift as the plan is underway.  (In fact, the plan/program itself can change on the fly, too, if necessary.)

If it's about expressing plans (e.g. programs) in a way to make them more portable among platforms, isn't that just yet another portable parallel programming language?  It is a language, in a sense, a visual one, called ScalPL (Scalable Planning Language).  Calling it a programming language might be confusing, since it doesn't even have the most basic mathematical operations or conditionals -- there are already plenty of languages to express those parts in -- but many would consider ScalPL a coordination language, or a component architecture language, or a process algebra (or calculus).  It can also be considered a pattern language.

So, if you are into platform independent parallel/concurrent software, or even just want to know what the issues are in those fields, I expect you will understand and appreciate this book.  And if you aren't, and are just into more traditional planning?  The title wasn't really intended to mislead you, and based on some very positive feedback from a few people who have seen the book so far, it appears that it may have exciting new approaches for traditional planners, too.  And because it straddles the software and concurrency and planning nomenclatures, there is some cross-fertilization between them, such as structured and object-oriented and refactoring approaches (from computer programming) being applied to the others.

Of course, this all leaves plenty of other questions -- including why I would be qualified to address some of these issues when plenty of others in the computer field have failed.  And to such things, I can only say that many of us have worked on these issues for decades, and continue to work on them.  We are all evaluating what each other is doing, and this book is my attempt to educate people on my thought processes on the matter, hopefully to be built upon and integrated into other work.  I have tried to make this work accessible to the lay person as well as the expert, so that it might be appreciated, utilized, and, yes, judged, by a wide audience.