The Ada solution to a Paraffins problem contains a surprisingly low
number of executable statements relative to the total number of 
statements in the program - only about 25%. The bulk of the code 
contains definitions of various generic functions, modules, etc. The Sather 
ratio is quite a bit different: 66%.
<P>
The other very significant difference is in the implementation of partition
enumeration routine. One of the goals of the Paraffins problem is to test
the ability of different languages to facilitate the reuse of software
components. The code for partition enumeration is used in the program
in many different contexts. In all cases, the exact same semantics of
the enumeration routine is called for: it has to generate all ordered
partitions of a specified size with a specified sum of all elements such that 
all elements are within a given range. Partitions are supposed to be generated
in the ascending lexicographic order. 
<P>
What differs from one usage to another is the
operation(s) applied to the generated partitions. Ada solution adapted 
a Lisp style passing of apply_to_each function into the enumeration 
routine, thus exposing the enumeration code to the outside world. Ada
uses generic function mechanism for such parametrization. Each of the
clients of the enumeration abstraction needs to create its own specialized
version different from the rest only by the semantics of apply_to_each 
function. Moreover, the interface of apply_to_each is fixed (modulo some
limited parametrization). Thus all clients need to create a function with
a fixed interface that processes partitions generated by the enumeration
routine even though there is nothing in the semantics of the 
client/enumeration abstraction interaction that requires such restrictions.
Exactly the same is repeated for a tuple enumeration routine. As a result,
code gets polluted by lots of instantiations of the generic functions.
<P>
The Sather solution seems to show some certain software engineering benefits.
The partition enumeration abstraction is implemented as an iterator 
(enum_partitions!). Once initialized, the iterator produces a stream 
of partitions. Any action could be applied to each generated partition
by the client with no restriction on the interface whatsoever. Admittedly,
writing recursive iterator enum_partitions! is a bit tricky, however 
the advantages are obvious - the iterator implementing the enumeration
abstraction deals only with enumeration and nothing else. None of 
the peculiarities of possible usages of the generated partitions are exposed 
to partition generation itself, as opposed to Ada.
<P>
Finally, parallelization appears to be equally trivial in Ada and pSather.
Both rendezvous mechanism in Ada and parloop in pSather provide good and
simple abstractions with no obvious winner.