Seen but not heard

Both input and output of UNIX programs tend to be very terse. This can be disconcerting, especially to the beginner. The editor, for example, has essentially only one diagnostic, namely “?”, which means “you have done something wrong.” Once one knows the editor, the error or difficulty is usually obvious, and the terseness is appreciated after a period of acclimation, but certainly people can be confused at first. However, even if some fuller diagnostics might be appreciated on occasion, there is much noise that we are happy to be rid of. The command interpreter does not remark loudly that each program finished normally, or announce how much space or time it took; the former fact is whispered by an unobtrusive prompt, and anyone who wishes to know the latter may ask explicitly.

Likewise, commands seldom prompt for missing arguments; instead, if the argument is not optional, they give at most a one-line summary of their usage and terminate. We know of some systems that seem so proud of their ability to interact that they force interaction on the user whether it is wanted or not. Prompting for missing arguments is an issue of taste that can be discussed in calm tones; insistence on asking questions may cause raised voices.

UNIX Time-Sharing System: A Retrospective — D. M. Ritchie; Bell System Technical Journal, July-August 1978, vol. 57, no. 6, part 2, p1958.

Many Java projects generate a remarkable amount of logging output, apparently on the principle that a noisy program is a working program. I prefer programs that quietly do their job, until something genuinely interesting happens or attention is required.

Comment from Eugene

Many Java projects generate a remarkable amount of logging output, apparently on the principle that a noisy program is a working program.

According to my personal experience and observations, the goal is different: to have as much information as possible when something goes wrong.

I agree that producing a lot of noise is ugly. A better mechanism in my opinion would be to attach the "contextual comments" to the blocks and to put these comments into the stack traces.

In the code it could look like this:

for (Iterator it = myItemsToProcess.iterator(); it.hasNext();)
{
Item item = (Item) it.next();
context "processing item " + item.id() {
...
// if an exception is thrown from the code here,
// it carries "processing item ABC012" in its
// stack trace
}
}

--
Eugene D.