Parallel programming paper

Bruce Adams tortoise_74 at yeah.who.co.uk
Sun Apr 6 11:26:06 PDT 2008


On Sun, 06 Apr 2008 15:54:26 +0100, Edward Diener  
<eddielee_no_spam_here at tropicsoft.com> wrote:

> Bruce Adams wrote:

>>  To be fair, whatever you are writing you have to make certain  
>> assumptions about your
>> readers background knowledge. You can't introduce every term every time.
>> For academic papers the target audience is most certainly not the D  
>> newsgroup.
>> The range of abilities and backgrounds here is too vast to cover  
>> without several
>> weighty tomes many of which would be boring to some. GIYF (Google is  
>> your friend).
>
> If the word "process" meant exactly one thing in computer programming,  
> then I would agree with you. But the word "process" means something to  
> me that evidently has no relation to whatever way the author of the  
> article is using it, and I believe my understanding of it, after 30  
> years of programming, is that of the vast majority ( a process is a  
> separate executable running within an operating system's address space ).
>
> Perhaps the author of the article should use a much more specific term,  
> in general use, to describe whatever type of programming he means by  
> "process", or at least provide an early reference to wherever the term  
> is commonly defined.
>
> If you are arguing about the merits of OOP versus "process" programming,  
> it behooves you to explain very explicitly what you mean by the latter  
> term since the former has more than two decades of understanding behind  
> it and the latter is some concept you are trying to introduce and  
> promote.

Intrigued by this concept I googled and found:

http://citeseer.ist.psu.edu/126677.html

"Process programming refers to the activity of algorithmicly describing  
models of programming activities (processes). A serious limitation of  
process programming has been that it is often hard to describe a  
programming process a priori . In this paper we present an approach to  
process programming which overcomes this limitation. Our approach is based  
on the premise that process programs are easier to describe in hindsight  
rather than by foresight, and hence can be synthesized by observing and..."

So process programming has an academic background going back to at least  
1992 without reading any further.
I suspect there will be something in the references somewhere.

Now perhaps I should take a look at the paper you're complaining  about  
before I comment further :-)



More information about the Digitalmars-d mailing list