Re: should I be interested in ada?

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

I'm sticking to my contention, in this case, with no diminished strength.

My argument would be based on the assertion that the complexity of a piece
of code, given that the programmer is already well familiar with those
aspects of the language which are the same in every program (e.g. the
spelling or symbol used for each language primitive), will depend on those
aspects of the program which do vary from program to program (e.g. the
elements present, and their relationship to each other).

Let us first review the Fortran and Ada snippets:

   FORALL (I=1:N, J=1:M) A(I,J) = I + J

   for i in 1..N loop
      for j in 1..M loop
         A(i,j) := i+j;
      end loop;
   end loop;

Now let us reassign each primitive element of the Fortran structure as
follows:

[01]  the FORALL structure
[02]  the () structure enclosing the iteration schemes
[03]  the , separating the iteration schemes and array indices
[04]  the = separating the iterative variable from the iterative range, and
destination from assignment source
[05]  the : separating the range start from the range end
[06]  the () surrounding an array index
[07]  the + operation
[08]  the variable I
[09]  the variable J
[10]  the array A
[11]  the literal 1
[12]  the integer N
[13]  the integer M

And then the same for the Ada:

[01]  the loop ... end loop; structure
[02]  the for ... iteration scheme structure
[03]  the 'in' dividing the iterative variable from the range
[04]  the '..' dividing the range start from the range end
[05]  the () surrounding an array index
[06]  the , separating array indices
[07]  the := assignment operation
[08]  the + operation
[09]  the variable i
[10]  the variable j
[11]  the array A
[12]  the integer N
[13]  the integer M
[14]  the literal 1

Now let us show these two structures, in terms of their component elements
and their relationships, in a manner that bears direct comparison:

[01]( [02]( [03]( [04]( [08], [05]( [11], [12] ) ), [04]( [09], [05]( [11],
[13] ) ) ), [04]( [06]( [10], [03]( [08], [09] ) ), [07]( [08], [09] ) ) )

[01]( [02]( [03]( [09], [04]( [14], [12] ) ) ), [01]( [02]( [03]( [10],
[04]( [14], [13] ) ) ), [07]( [05]( [11], [06]( [09], [10] ) ), [08]( [09],
[10] ) ) ) )

And lo and behold!  They're almost identical in complexity.  This is
elementary language science.

I believe SLOCs are used as a measure between different programs written in
the same language mainly because it is the simplest method, rather than
because it is considered a particularly good method of measurement, and, in
any case, are (almost) never used to compare the same program written in
different languages.  If SLOCs were such a good measure, why would so many
scientists be seeking to develop other methods of code measurement (e.g. the
CGD of the GRASP project)?

Finally, if an Assembly equivalent of the above algorithm were to be
semiotically analysed in the same way as I have done above, it would produce
a result that was less deeply nested, but contained a much longer stream of
elements (five times or more).  The advantages of using a HLL over Assembly
are many, reduced complexity (or at least increased conciseness) being just
one.

-------------------------------------
Nick Roberts
-------------------------------------