Intentional Software

Feature X Considered Harmful

I was just reading Chenglie Hu's important article in the Communications of the ACM under the title "Dataless Objects Considered Harmful" (ACM membership required to download or you can read it here). I feel this is significant for two reasons.

First, on a practical level, I've also noticed that recently graduated programmers are not well educated in the classical theories of Modular programming as described by Parnas among others. Too many programmers seem to think that just by writing classes and methods, and by the appropriate use of private and public attributes, the program will be automatically modular. In fact the opposite seems to be the case. By not having an independent guiding principle for organization, the classes and public attributes become expressions of the programmers’ whims, mere packing crates for the required functionality. The OO programming languages, most notably Java, but unfortunately also C# do not do much to alleviate the situation, by prohibiting the use of procedures outside of classes and not providing information-hiding boundaries other than the class, which hides information but it is also an implementation concept. Here we have again the old programming language conundrum: to get the benefits of a specific abstraction, say information hiding, you have to buy into a specific implementation at the same time. Of course the whole idea of abstraction should have been to leave room for different implementations, that is to factor complexity.

The other reason is that the article recalls the seminal letter to the editor from Dijkstra: “Go To statement considered harmful” which created a firestorm of controversy when it was published in 1968. I was maintaining an Algol compiler at the time for the CDC 6400 so it was not a big shock for me, but I recall that the Fortran users were quite upset. We now “know” that Dijkstra was advocating structured programming and that his objection had to do with the difficulty of proving correctness of programs with unstructured Go To statements. But re-reading the original text, I think that Dijkstra’s letter was quite obscure and I can now sympathize with the initial incomprehension of its readers. Yet the letter started a very important movement to improve Software Engineering.

In presentations on Intentional Software, I often ask the audience: Why should we think, in general, that “X is considered harmful” for any programming language feature X? At this time we have X= “Go To statement”, and X=”Dataless Objects” (for more examples see Hello world considered harmful or even Aspect-Oriented Programming Considered Harmful, and for a rather harsh critique of the question itself see here). I think the answer has to be situational in any case: it is not that an abstraction is harmful per se, it is more that certain uses of an abstraction are counterproductive.

I hinted at the solution in my other posts here and here. To decide whether something is harmful or useful, we have to refer to the problem being solved. If we do not know what the problem is, a tool is devoid of meaning (have you ever had that feeling when looking at strange tools in a cabinetmaker’s or bookbinder’s shop?) Hu also hints at this in his article:

“[...the undesirable result is that there will be] many intermediate variables that don’t correspond to separate entities of the application domain” (emphasis added)

So to generalize the “harmfulness” theory, we need to refer to the degrees of freedom in the problem statement, in the domain intention. A programming feature is harmful in proportion that it has more degrees of freedom than in the domain intention that it is used to solve. By degrees of freedom we mean the potential parametrizations (arguments, properties, attributes, or parameters) for the abstraction and the gamut of their values. This latter is determined by the parameter type: the range of possible parameter values can be small for enumerated types, or very large, for example the “parameter” is a statement list as in a loop. Harmfulness is related to excess degrees of freedoms: more parameters than necessary, or larger parameter types than necessary for the purposes of the problem intention.

The theory seems to work with the two key examples above. For example, a Go To that is used with a label parameter to implement the end of a loop has more degrees of freedom than it is necessary; it could go to any place in the scope when it needs to go to just to a single well defined place which is the test for loop completion. Similarly the dataless object has too many degrees of freedom when it is encoding a modular unit and its procedures. The object type and the object instance are all superfluous for the purpose.

It is worth restating what is wrong and what is right with extra degrees of freedom.

The wrongs are twofold: work and errors. For any parameter the programmer has to choose a value – that is work. If the parameter is “extra”, or if the parameter type accepts a greater infinity (powerset) of values relative to the problem, this work does not get easier; in fact, if anything, it gets harder. By lacking proper motivation, the naming of extra quantities (such as the arbitrary label at the top of the loop) can be particularly vexing as we discussed in the loop constructs in an earlier post. The second problem, the errors, comes from to straightforward communication theory. The larger the space of encoding, the larger the error rate. This is why voice recognition systems with limited vocabularies work much better than those with unlimited vocabularies. This is why the Palm Pilot’s Graffiti has lower error rates than other, more general, handwriting recognition systems, and keyboards, have lower error rates still. Similarly, the error rate of Go To statements that encode loops will be greater than the error rate of a structured statement, which is by the way, still not zero.

Here are a few things that can go wrong with a structured “while” statement. Consider the code:

    while (i<0);
        f(i++ );

The result is probably not what was intended due to the extra semicolon in the first line. What would be more intentional here? Suppose we could say:

f([i, 0))

meaning

“execute f(j) for all j in the interval starting with i, up to but not including 0 - in other words in a half closed half open interval; and yes, we do want to use the standard mathematical notation [a,b) for such an interval”

Using this abstraction there would be fewer degrees of freedom and there would be no possibility for the above error, and we would also eliminate the possibilities for other errors in this simple while loop like these:

    i<0 or i<=0?
    i++ or ++i?
    i written in the comparison and some other variable written by mistake in the increment.

Of course this interval construct may not represent the absolute minimum in the degrees of freedom, but to go further we would have to know more about the problem being solved. However, the example shows that even with very local knowledge we can make substantial reduction of work and of errors if we concentrate on the degrees of freedom.

Why do we still like degrees of freedom? Why were the Fortran programmers upset when the future of their GOTO’s was threatened? Strangely enough it had to do with the lack of choice.

What I mean by this is that if we have limited choice of tools, for whatever reason, we will rationally choose the most general one so that we can cover a greater set of problems. So the Swiss Army knife is the choice of mountain climbers. It would not be the choice for the master bookbinder, not because the multi-purpose tool would not work in bookbinding, but because its degrees of freedom would mostly just get in the way both by having to open the right blade each time and it could also cause “binding errors” when the general purpose blade slipped while used for burnishing, for example.

So the better question is how come we programmers have a limited choice of tools at the level of language features? After all we are not limited in creating procedure contents, names, comments, icons, error messages, and so on. Since we are more like master bookbinders than mountain climbers, we should be better equipped.

Footnote: Actually, even within these normal functions of programming languages we have some limitations: in comments I always wanted to include sketches and diagrams, but I cannot. Names are also quite limited: the 50 year old rule of “only the 26 upper case letters in names” is breaking down only at the glacial speed of roughly 1 extra character/year. In programming we can’t have more than one name for something (name or cite or point to one thing or person that has only one name) and things in programs with names that somehow become similar to other names around them can lose their identity, which is another rule that would be utterly impractical in real life. This all may sound like griping, but in fact as we are used to restrictions in the small things, we accept the restrictions in the large.

This is further illustrated in our earlier post about the long tail of programming languages. All languages at the top were general purpose languages while we found more domain specific languages further down. Today we live in the reality that you have to pick one language and you are stuck with the abstractions of that language. The ability to tune or extend a language to get closer to the domain we solve problems in is yet possible. And of course mixing languages leads to all kinds of complications because our tools do not work well across languages.

Just as we need a language and a run-time to create the procedures that we want, we could have a language and a run-time to create language features. Unfortunately languages for syntax directed compilation (such as Yacc) did not solve this problem – they described parsers, not language features, they, in effect, had “too many degrees of freedom” which made them very difficult to use. The main difficulty, of course, was the need for the design for the syntax itself – remember, what we set out to create was a language feature, not a syntax. The road toward creating solutions to the meta-problem is truly an arduous one. But until we increase the choice of language features corresponding to the greater variation in applications domains we face, more and more of the features we now have, will at one time or another have to be “considered harmful” as the degrees of freedoms of the features exceed the degrees of freedoms in the domains.

Hello out there

I'm a fairly new developer at Intentional Software, but an old one, at least in programmer-years. My career has seen twenty five years of Moore's law applying to hardware engineering, while Murphy's Law best describes our work in software engineering. Why? Perhaps because users expect more than we can reasonably deliver with fundamentally unchanged tools and techniques.

It's been a long journey. I spent my formative years hunting woolly mammoth and using text editors to scatter code blocks into functions living in text files. Specifications were easily-forgotten wall charts hanging on the cave wall near the coffee machine. What has changed? I still use text editors, but the coffee’s better, and strip steak tastes better then mammoth stew. But are Pascal, Lisp and Smalltalk distinctly inferior to Java and C#? I don’t think so. Have we found a better way to go from specification to code? IDE’s, better tools and paradigms may help with code, possibly just enough to trick us into taking on far too much complexity. I’m excited about Intentional because it’s not merely trying for incremental improvements to how we perform our jobs. It redefines the field in at least two ways.

All participants receive new roles.  These roles allow developers, architects and users to directly contribute unique knowledge and viewpoints to an end result. Distinct languages, notations and views support varied vocabularies and thought processes.

Non-developers don't merely toss requests over a wall, hoping for results to match their wishes. All participants are active co-creators of the final product. Yet despite the greater influence of non-developers, our importance as developers is not diminished. We may share more credit, but it will be credit for better results.

Cheers,

Steve

Notations and Programming Languages

The first thing that one notices about a programming language is its syntax. When we think of COBOL we see lots of capital letters and verbs like "PERFORM". Lisp is associated with lots of parentheses. I have my personal memories of Algol 60 with its wonderful typography with boldface delimiters such as begin and end way before there was boldface on computers! We often hear about graphical programming languages also. These languages all came with various claims about their applicability. For example, COBOL was designed for business applications and Lisp for artificial intelligence. How is the syntax of the language connected with its power or applicability? Intentional Software has some very specific views on this.

Let’s look at equivalent forms in different languages. For example, consider the conditional statements:

IF (A .LT. 10) ...
if A < 10 then ...
test a ls 10 ifso ...
if (A < 10) ...

It is clear that the syntactic differences are completely superficial, and it is difficult to see why people would have battled so hard for or against them. Indeed it is disappointing to consider that this list represents more than 40 years of programming language evolution from Fortran through C#.

By the way, the 3^rd line is written in the historically important but otherwise little known language BCPL from Bell Labs. It was followed by the language B which in turn was replaced by Kernighan and Richie’s C. The joke of the time was to guess whether the successor of C would be called “D” or “P”? Check out this overview of the family tree of programming languages.

Now, if we compare the Fortran IV statements:

    IF (A – 10) 2, 2, 1
1   ...
    GO TO 3
2    ...
3  CONTINUE

with Fortran 77:

IF (A .LT. 10)
   ...
ELSE
   ...

we see more than just a syntactic difference. The early so called “arithmetic if” statement awkwardly aped the way hardware expressed the comparison: whether the control should be transferred to label 1 when the difference (a-10) was negative, or to label 2 if the difference was zero or positive. In a later version of Fortran (as in all current languages) we see the structured construct with the comparison operator and with an ELSE clause, which expresses the same intention much more directly. In fact, if we were asked what the first segment “meant” we would probably say something very close to the second, assuming we could correctly follow all the details and paths.

The structured form is much shorter, yet it contains the same information. How is that possible? It is because the “arithmetic if” and “goto” statements have more degrees of freedom (in other words, more parameters) than we need; namely, the three label references after the IF and the one label reference in the GOTO. These could have easily represented a loop or maybe up to three different choices, whether on purpose or, perhaps, by mistake. The earlier form is longer because it has to represent the programmer’s intention in the larger parameter space. In contrast, the structured form has fewer parameters – its “degrees of freedom” property is more like the problem at hand, to wit, do something if a is less than 10 and otherwise do something else. Therefore the structured form is shorter. It cannot do a loop, nor can it do more than two things, which means that many opportunities for mistakes are eliminated. There are other forms for doing those things explicitly if that is intended.

We could say that the “arithmetic if” and the “goto” statement in FORTRAN IV are less intentional, and that the structured “if” and “else” in FORTRAN 77 are more intentional. We also note that intentionality has to do with how the degrees of freedom in the problem compare with the degrees of freedom in the notation. We know that we cannot express something with fewer degrees of freedom than what is in the problem itself. But they can be equal: that is the intentional optimum. As the degrees of freedom property in the notation becomes greater than in the problem, we can call the notation less intentional and more implementation-like. The difference can be very large in the case of assembly code, or even machine code. In fact the number of bits used to represent the assembly code for our “if” statement might even be sufficient also to represent a recognizable icon of President Lincoln (756 bits)! Clearly we would be using more bits than the problem dictates.

What is wrong with more degrees of freedom? Nothing if that is what the problem needs: for example, if we are trying to create an iconic directory of the Presidents. But if the problem is to choose between two possibilities (as in “if..then..else”), or indeed for any problem, if we are given more degrees of freedom than we need, we incur costs of navigating in the larger space when we seek our solution and we incur costs of bugs. The bug costs are due to the real possibility that we get lost in the large space. For a given problem, the more parameters needed to express the solution, the greater the chances that one of them will be incorrect.

On the other hand, we also need to recognize that even excess degrees of freedom can be useful in some cases. In the early days of computing, use of assembly code was normal practice. If we know very little about the solution and it is expensive to change the language of the solution, then we had better ensure that every possible solution will be accessible within the same language and thereby benefit from the degrees of freedom. But if we know quite a bit about the solution, then we can reduce risks of incurring costs by shifting to new expressions with fewer degrees of freedom where the structure of the solution can more closely approach the structure of the problem.

So just as “arithmetic if”s were replaced with “if..then..else”, the process of elimination of excess degrees of freedom has continued. For example, instead of the common loop pattern:

startloop:
    if (!a) goto endloop;
    ...
    if (x) goto endloop;
    ...
    goto startloop;
endloop:

we can currently write:

while (a) {
    ...
    if (x) break;
    ...
}

One problem with the former loop pattern was that the programmer was required to come up with reasonably unique, but still meaningful names for the labels. These are really contradictory requirements. For example “endloop” would have not worked very well in any real system because it would not be unique. Using “L123” would be unique but probably not as meaningful.

The “while” loop and “break” statement cured those contradictions and eliminated unnecessary degrees of freedom. But why should we stop improvements at the current “while”? We can ask next: “What are we doing with the while and its contents?” Chances are that there is some answer like: we are waiting for something, we are searching for something, we are enumerating over some set. In each case, we could imagine some construct that would do exactly what we wanted if we had the right degrees of freedom. For example we now see “foreach” in languages like Perl, C# and Java, where the freedom (and burden) to separately identify the loop limits while iterating over a collection has been removed. “Foreach” is more intentional than a traditional “for” loop. Although it adds complexity to a language by introducing some new syntax, it more directly gets to the intended behavior of iterating through a collection.

Advocates of object-oriented languages point out that optimal constructs are already within reach – just define a class and its methods the way you want them. But this works well only in cases where a class is an exact representation of an underlying intent. What about a “while” loop, which is not a class? Certainly a class-based enumerator could be built with some effort, but then the programmer would have to introduce a name for the method that represents the body and depending on the implementation other names would have to be invented as well. So building a class-based “while” loop enumerator out of some more primitive components would still be moving toward the past, raising the old issues again.

Instead, we should move further toward the problem. Once we have introduced the search primitive that the “while” implemented, we should continue asking questions: “What are we doing with this search?” and create a construct for the intention behind the search. To be able to continue creating new constructs, we have to look beyond classes or even aspects.

We could help this process of creating new constructs move along by making notation and semantics independent. We should be able to simply list the degrees of freedom – the parameters – that are required for a construct. The parameters themselves could be any other constructs with no a priori limitations: expressions, statement lists, declarations, or types. And notations will have to accommodate this flexibility.