ParametrizationOfComponents

FlowBasedProgramming (FBP) is an approach where reusable software components are linked together by streams of data chunks (called InformationPackets or IPs), which are generated and consumed (or passed on) by the components. Component instances run asynchronously with each other, and the data chunks travel across BoundedBuffer connections. No component knows the name of another component - instead a component sends an IP to a Port, and another component receives it from another port, and ports and connections are related by means of a separately defined network definition. See PortsAndConnections.

The idea of being able to use components in many different configurations, without changing their internals, which is of course standard in the real world outside of programming, was given the name ConfigurableModularity, by the senior IBM engineer NateEdwards.

Since many instances of a given software components can run asynchronously with each other, they usually have to be parametrized, normally by means of parameters specified in the network definition, known as InitialInformationPackets (IIPs). Since IIPs are received from ports like regular IPs, the designer is able to shift smoothly between static parameters and regular IPs being received at the same port from other components, which then act as parameters.

In FBP we see a spectrum of parametrization of components, from none (a process is so simple that it doesn't need parameters, or so rigid that its function never varies), all the way to a mini-language - see LittleLanguages - or even conceivably a not-so-little language.

As stated above, some components need no parameterization, while some, like I/O components, need very little, like a parameter specifying a file name or a DDname on a z/OS machine. Intermediate levels of parametrization are those required by the batch Sort, or SQL control language. Note that such little languages do not have to be TuringComplete. It is the network as a whole that has to be TuringComplete. This probably means that at least one process in the network has to be TuringComplete, but most of them don't.

A corollary of the above is that it might be very useful to be able to run interpreters in processes, but the interpreter shouldn't have to deal with multithreading itself. This means that one could combine compiled languages, script languages, SQL and other interpreters, all in the same network. This seems to me to be a very powerful concept, and a much better approach than trying to cram every paradigm and methodology into a single language.

For a sketch of a declarative language that could be run on one (or more) of these cooperating processes, see http://www.jpaulmorrison.com/fbp/bdl.htm.