Under review is this document.
This is a similarly short document as my last review, and I read it in this order. I took two weeks to finish it, although it was a much lighter read. I recommend reading this, and in the same order.
The first half of the paper concerns itself with describing complexity and causes thereof; similarly to Backus' paper, reading this will help bring about a lasting clarity with the ideas. Both testing and informal reasoning are described as approaches to coping with complexity, such caused by: state, control, and size of the code, and described against these methods. Unlike state, the discussion of control will be more novel to most programmers, such as being forced to specify orderings where none are wanted nor needed, and the difficulty an environment must go to re-establish this same knowledge for analysis. The size of code is suggested to be dealt with purely by decreasing it to start with.
The paper describes further causes of complexity and then analyzes these and related issues in terms of object-oriented, functional, and logic programming; it introduces the ideas of ``accidental'' and ``essential'' complexity. Similarly to Backus' paper, I saw some of my prior ideas in this as well.
Primarily, this was in the idea of ignoring performance optimization in a system, but allowing for a completely separate system of directives for such. This is in contrast to a language such as Common Lisp, which inlines these with the program itself. Mine envisioning of this differs from the paper, which suggests a simple declarative approach for suggesting important, but minor, properties of that program; mine idea is of having an environment provide all intermediate data characteristics and the like, and being able to suggest it use refinements or alternative representations thereof, including such things as using more general storage, to avoid unnecessary allocations. Of particular interest is the suggestion to use different languages for specifying different parts of that overall program.
The second half of the paper introduces the barke skeleton of a system seeking to entirely avoid the issues outlined, ``Functional Relational Programming'', and the characteristics of an infrastructure which would support it. Of particular interest is that it entirely avoids that aforementioned issue of control, and how it eliminates code by declaratively specifying invariants. The end of the paper is concerned with giving a more tangible example of what such a system would look like, but I didn't find it so pretty in absolute terms. While it introduces a system which perhaps seems more relevant than Backus', it also seems much less actionable in comparison, and this is because Backus goes into much greater detail in his specification. Both systems are an inverted design in the sense of being a set of floating, disconnected definitions to be used. That example program provided would be much smaller if specified with Backus' system; I feel that entire program should've been but a lone page.
Ultimately I prefer Backus' paper, but this being reviewed goes into interesting detail with related topics Backus doesn't mention. So mine advice is to read this second; both are still good, and both will influence future thinking. Still, walking out of the tar pit can be done with much more style.