[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.
Sincerely,
Marc