[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The world needs process-orientation

On Jun 10, 2006, at 5:29 AM, neil@xxxxxxxxxxxxxxxxx wrote:

I don't mean offence, but you make it sound as if there is a giant
conspiracy maintaining OOP's position.  The fact is, people are
resistant to change, and sometime about thirty years ago, OOP
succeeded, but POP-like (process-oriented) techniques were ruled out.
Quite possibly because concurrency was less of an issue when you
usually had a single-CPU.  So they still have OOP now, and don't want
to have to retrain everyone and lose legacy code. That is a legitimate reason for sticking with what you know - hence my suggestion that small
sub-optimal steps (such as C++CSP/JCSP) might actually be the best way
to convince people.

Every paradigm shift has been painful, and only partially successful. Sorry, I know better than to say "every," but the shift from goto's to structured programming was resisted, and we all know that structured programming wasn't a silver bullet for writing understandable, maintainable code. OOP, too, was resisted for a very long time, for all the reasons Neil mentions. Smalltalk didn't catch on with the masses. Stroustrup understood that baby steps were needed when he developed OO extensions to the ubiquitous C language. C++ was never intended to be an OO language, but rather to support multiple paradigms, so the programmer could choose the most appropriate tools for the problem at hand. C++ was criticized by the OO community for not being pure OO, but gradually, the masses learned the terminology and abstractions of OO, and this paved the way for Java (along with C's pthreads library, unfortunately, in influencing the choice of built-in threads and a stripped-down implementation of Hoare's monitors). And of course, Java is not purely an OO language...

In other words, Neil makes a very insightful point regarding sub- optimal (baby) steps! The masses have moved at a glacial pace from assembly-level abstractions to C-like code, to C++ (aside: ever notice that most C++ programmers are really programming in C, except possibly for using cin and cout?), to Java. But make no mistake, folks are never satisfied with the state of tools (languages) available, and more baby steps continue all the time, and these baby steps are often of the form, "one step forward, two steps back." (It could also reasonably be argued that we're talking about more than one or two steps in many cases.) Java 1.5 has introduced generics and loop constructs that conjure language features C++ had with templates a decade earlier, and Smalltalk a quarter century earlier! Everything old is new again. Well, maybe not everything, but you may see where I'm heading.

One tragedy here is that what OO has become has deviated far from its original intent: concurrent objects interacting through message passing, and elimination of the assignment statement! In its original intent, I don't believe these concurrent objects differed from what we refer to as processes. But side effects due to assignment statements make reasoning about concurrent objects (and concurrency in general) difficult and problematic. That Hoare described processes functionally is no accident. But back to Neil's observation:

I agree that we need more and more tools. KRoC, SPOC, Honeysuckle, CTJ,
JCSP, CTC(++), C++CSP, are all good.  The more the better!

I couldn't agree more. In particular, language "extensions" like JCSP and C++CSP are important, because they make (for example) PAR and ALT abstractions accessible to the masses, in much the same way that C++ made notions of classes and inheritance accessible to C programmers. KRoC and occam-pi are essential, because we must have languages in place for when the "aha!" moment occurs, just like Java was laying in waiting for the masses of C++ programmers who became ready for a more elegant syntax, and superior language support for the abstractions they begin to realize they can't live without!

So what happened to the concurrency? I came to CSP later than most in this group, both in terms of the year (1997), and in my own education (while working on my dissertation). I can understand the sentiment that OOP has academically and commercially hijacked important terminology and abstractions of process-oriented programming. It's easy to be discouraged by history (e.g., VHS beat the Betamax format) but there is an important difference here: The industry needs process- oriented design, they just don't know it yet! It's not a case of which format, because DVDs displaced video cassettes (for example). The shift to multi-core, I believe, is the second-coming of the transputer! (I missed the age of the transputer, so I'm personally very excited...) There is a slow realization that new tools and abstractions will be needed to leverage multicore technology. The masses just don't broadly realize that these tools, indeed an entire process algebra and calculus, already exist!

This is a
topic oft-mentioned, but what we need (as much as, if not more than
more tools) is good literature on the matter.  Whenever I advocate POP
to anyone, I lack a good place to point them for a good introduction to the matter. They say what is it, what can I use it for, where are code
examples, etc; I can usually point them to papers, which are not what
is needed.  Things like the IBM DevWorks JCSP article recently, pages
like Fred's on how to program occam, are what we want.

Yes, we need textbooks as much as language tools. Thanks to help from Peter, Fred, Ian East, and Dyke Stiles, I was able to include elements of CSP into my parallel course this past year. My students loved JCSP!! Unfortunately, I must add, all six of them loved JCSP (not a big number)... Textbooks will help us get the word out. But more importantly, and I'll echo Peter here, we teach introductory CS all wrong, as students should see concurrency from the start -- it's natural! But we can't do this without textbooks... (I realize this is somewhat of a Catch-22)

I'm as guilty as anyone else - I just can't find the time to write an
introduction to POP, or even a good guide to C++CSP.  I should, and I
encourage everyone else to consider the same.  Of course a major step
would be a book on the matter, but that's an even bigger undertaking.
In the mean-time, we need web resources explaining POP, the tools, and
how to use them. I know there are some people in Japan doing something
very similar to this, creating training materials and tutorials - we
need to do the same.

Writing a textbook doesn't help me get tenure, unfortunately, but I'm beginning at a new school, and I will raise the possibility once more. Anyone else willing to entertain such a project? We really must make this a priority, I feel.

Thanks for reading this far.