Subscript is a way to extend common programming languages with features from the Algebra of Communicating Processes (ACP). Below, find why it would be needed, its starting points and the paradigms it supports.
Our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
These wise words are from the famous paper “Goto statement considered harmful” that Edsger Dijkstra wrote in 1968. In those days many programmers tended to use the “goto” statement, which too often obscured the control flow. The resulting programs were described as“spaghetti code”. In the years after this paper, the use of goto statements decreased, also by improving choice and iteration constructs in programming languages. By 1980, “structured programming” had become widely accepted.
But spaghetti code returned, although this was not immediately recognized. Programs got graphical user interfaces, and program behavior started to be driven by user generated events. At first, a “main event loop” handled these events. Programming such an event loop was tedious, but the code was still understandable. As the user interfaces became more advanced, the coding complexity increased. For instance, time consuming tasks required special care so that they would not block user input.
Around the year 2000 programming interactive applications had become really hard. Spaghetti code was needed to handle all kinds of input events; the screen needed to be updated in a specific thread, and background threads had to keep the application responsive. As a result these days, too many applications, even professional ones, freeze the GUI time and again.
The main cause for the trouble is that the applied programming languages offer inappropriate support for event-driven and parallel programming. Event handling and multithreading are usually implemented using dynamically created call-back objects. These data items largely determine the flow of control, resulting in “call back hell“. We would need something much like explicit control flow constructs, that programming languages offer for concepts such as choice and iteration.
SubScript had the following starting points:
- support ACP and other constructs such as or-parallelism that are not yet in ACP
- extend common programming languages so that their features are all accessible for the programmer
- intuitive appearance: minimize parentheses usage; use white space to decide between ambiguities; use arrows to depict communication; etc.
Programming languages are often classified in categories such as
In the Functional Programming course at Coursera, Scala creator Martin Odersky argues that object-orientation is a dimension orthogonal to the imperative/logic/functional dimension. Scala thus has both normal methods and closures inside classes.
We could argue in the same way that closures are an orthogonal feature as well. They may apply as well to refinement constructs in logic programming.
And this logic programming falls in a wider category known as non-deterministic programming, which is the complement to imperative programming; so let us rename it into non-imperative programming. Now a programming language can support at least one of the following paradigms:
and optionally any of the following two paradigms:
- supporting closures
SubScript specializes at the non-imperative paradigm, but it also contains support for imperative style. Closures are possible as well (although it is not yet described what they will look like), and object-orientedness would simply be inherited if the base language supports it.
Maybe a bit outside this characterization scheme, SubScript supports concurrent programming and within that, dataflow style programming.