A Review of ``Out of the Tar Pit'' by Ben Moseley and Peter Marks

Information concerning the document under review may be found in that menu linking to 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.
.