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

Re: Flow based programming

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


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


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.


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