Re: Flow based programming

[Ian East <ian.east@xxxxxxxxxxxxx>]

Tom plus occam folk

After only a quick look...
Is this not Data-Flow Programming, which sported a number of visual  
languages in the 80s? A spin-off from the Functional Programming  
community.

I found that paradigm very interesting back in the 90s after picking  
up a book in a second-hand store, and finding a free DFP Visual  
Language package on the net. I too wondered about the relation  
between DFP and CSP/occam. I ended up exchanging procedure for  
protocol - there's supposedly a law that says anything you can  
express as a procedure can be expressed as a protocol, but have never  
tracked down anything formal.

This does also relate to the question of exactly what a component- 
wise compositional language should look like. Like DFP (and CSP) it  
should surely have its roots in a functional notation.

Formal component-compositionality should be a major objective for the  
reasons you state. One of the reasons given by a reviewer for  
rejecting a grant application last year was that they didn't believe  
we could get that one nailed. Doubt it's easy, but anything's better  
than Java Classes...

Ian


On 12 Sep 2005, at 16:49, Tom Locke wrote:

> I stumbled across this a while back via del.icio.us
>
> "If you are wondering how a revolutionary new approach to  
> application development, which has won acceptance from some of the  
> leading thinkers in the IT industry, can have been in continuous  
> use for almost 30 years in one of Canada's major banks, read on! "
>
>  http://www.jpaulmorrison.com/fbp/
>
> They seem to have discovered the CPA style of programming entirely  
> independently from the stuff we're familiar with, and used it in a  
> business programming context with great success, e.g. (sorry for  
> the long quote, but this is exactly what I've been claiming about  
> CPA programming for years, so I found this very exciting):
>
> "Imagine that you have a large and complex application running in  
> your shop, and you discover that you need what looks like fairly  
> complex changes made to it in a hurry. You consult your programmers  
> and they tell you that the changes will probably take several  
> months, but they will take a look. A meeting is called of all the  
> people involved - not just programmers and analysts, but users and  
> operations personnel as well. The essential logic of the program is  
> put up on the wall, and the program designers walk through the  
> program structure with the group. During the ensuing discussion,  
> they realize that two new modules have to be written and some other  
> ones have to change places. Total time to make the changes - a week!
>
> "Quite a few parts of this scenario sound unlikely, don't they?  
> Users, operations people and programmers all talking the same  
> language - unthinkable! But it actually did happen just the way I  
> described."
>
> That's from the book, which is available in full on the web-site.
>
> I'd be very interested in your comments. Did you know about this  
> already? I did make a note of some of the differences between their  
> programming model and CSP/occam, but I think that file is currently  
> on a disembodied hard-disk, while the host computer is journeying  
> the high seas.
>
> Tom.

Dr. Ian Robert East
Department for Computing, School of Technology
Oxford Brookes University
Turing Building
Wheatley Campus
Oxfordshire OX33 1HX
01865 484529               ireast@xxxxxxxxxxxxx