RE: The world needs process-orientation

[neil@xxxxxxxxxxxxxxxxx]

> > 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.


When you spell it out, it becomes even more evident how slowly the
mainstream has moved!  There are always new languages pushing the
boundaries, and it seems that perhaps (with languages such as Ruby,
Python and PHP, whether you like them or not) developers' tastes are
diversifying which can't be a bad thing.  One thing that really amazes
me is this: 

http://www.gnu.org/prep/standards/html_node/Source-Language.html#Source-Language

GNU state quite clearly that everyone should use C.  They even rule out
C++, for goodness sake!  Very out-of-date.  I'm not suggesting that
there is an army of developers using C simply because of GNU, but I
think that page is emblematic of a lot of developers' mindsets.  C
works, C runs on everything, you'd have to give me a good reason not to
write in C.  There are many good reasons not to write in C - pointers
lead to an enormous amount of dangerous bugs, arrays lead to buffer
overflow vulnerabilities, there are few useful abstractions - and yet
people still write volumes of C code.

The reasons why are probably to do with legacy code - this is
particularly persuasive in the case of Open Source/Free software.  You
can't develop for the Linux kernel (as I believe Bernhard Sputh
elaborated on in a paper a few years back) unless you're using C.  The
same for every other major project of course - if the project uses C,
you must use C.  Microsoft accuse the GPL of being viral - they are
almost right in this case!  It allows C to spread virally.  As you may
notice, I have a particular dislike of C, but I don't think I'm wrong.
 
C++ is a multi-paradigm language, but you're right that a large amount
of C++ is C with a few tiny changes.  People like Boost have shown what
C++ is capable of (namely, most things - except good concurrency of
course...), which only seems to drive people away as they claim
(perhaps rightfully) that the language is too difficult unless you have
mastered it.

> > 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!

This sums up my argument concisely.  The more I try to convince people
to take the big step to things like occam, the more I begin to realise
that the CSP libraries for existing languages are a more likely bet. 
Not that that has stopped me tinkering with a new POP language, but
that's another story.  
 
> 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!

It's a weird situation now.  People are beginning to realise that
concurrency really *is* the way of the future.  For the most part
programmers realise that concurrency in C is hard.  The difficulty is
convincing them that concurrency can be easy!  They keep trying to find
nicer ways of dealing with threads and locks in C when POP awaits them. 
Our argument is sound, we just need the materials to provide support to
them, and show them how to do it.  Hence:

> > 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 think changing introductory CS is a very big step.  An interesting
parallel (excuse the pun) is that of secure programming - an issue I
have become familiar with over the past few years.  C allows
programmers to write the most insecure vulnerable code of any language.
 So those interested in security have two main solutions - drop C for a
better tool, or educate programmers on how to write secure code.  Sound
familiar?!  Yet year after year, programmers plug away writing buffer
overflow-vulnerable code in C, because C prevails, and education
(certainly at the degree level) rarely if ever teaches how to write
code securely.  Microsoft had to essentially re-train their *entire*
development teams and totally change their attitude (throughout the
organisation) to security in order to turn things around.  That's now
paying off, but it goes without saying that it seems unlikely a similar
change would occur with regards to concurrency.  Still, secure
programming is still usually done in C, but with the education to
understand what is going on.  I guess our expectation (from the above
thread) is that concurrency is most likely to happen in CTC/C++CSP - we
just need the education part.  Which all ties into the books and
web-pages that are needed.  I think, with my papers for CPA 2006 mostly
finished, it is time for me to make my own attempt with regards to
C++CSP.

Thanks for your opinions Marc,

Neil.