[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
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
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
Oxfordshire OX33 1HX
01865 484529 ireast@xxxxxxxxxxxxx