A common, if somewhat informal, observation about a large code base is that there are "too many moving parts" in it. In my experience, this is especially true for large Java systems but is probably universally true.
What do we mean by ‘too many moving parts’?
Simply put, there is always a significant semantic gap between a programming language and the program. The larger this gap, the more that has to be expressed in the language, as opposed to simply using it.
For example, consider the problem of traversing a recursive tree structure. In Java, we can iterate over an Iterable; structure using a loop, for example, to count elements:
int count = 0;
for(E el:tree)
{
count++;
}
If the Tree class did not implement Iterable we would be forced to construct an explicit iterator (or worse, write a recursive one-off function):
int count = 0;
for(Iterator<E> it=tree.iterator(); it.hasNext();)
{
E el = it.next();
count++;
}
This version illustrates what happens when a programming language does not quite meet us halfway in our programming task. There is a lot of extra clutter (managing the iterator) that makes it hard to see what is really going on.
In this case, Java's for notation makes it significantly easier to see the program. However, there are many cases where this is not true. For example, you cannot use a similar technique for reading files, searching or removing elements from a tree, etc. etc.
Language Extensions
One way of reducing clutter is to permit the programmer to extend the language. Of course, the designers of Java set their face against this — there is no macro facility in Java — for a reasonable if misguided reason: to prevent programmers lying to each other.
The Star language does permit language extensions to be introduced by the programmer. This has the effect of encapsulating not only data abstractions but also control abstractions.
For example, to count the elements of a tree in Star, we can do:
var count:=0;
for E in tree do
count := count+1;
The program depends on the programmer implementing the type contract for _search and a macro expansion rule:
# for ?Ptn in ?Exp do ?Act ==>
__search(Exp,procedure(X){ if X matches Ptn then Act})
No apologies for the macro definition itself, but the effect is that the language has been lifted into one that fits the requirements more closely. This, in turn, reduces the semantic gap between the language as used by the programmer and the application.
Of course, there is quite a bit more to reducing clutter than macro definitions. However, it should be an important goal of language design to ensure that programmers can express themselves with minimum extraneous concepts.