Program Composition and Transformation in Unix

A few years ago, I got the feeling that language design could benefit from looking towards Unix and the lessons of the Unix culture.
A definite source of inspiration for this was Eric S. Raymond's The Art of Unix Programming, which among other things analyze what the greatest strengths and most significant design decisions (or rather, design style elements) of Unix are.

One of the qualities I'd most like to carry over from Unix to programming languages has to do with modularity - the ease with which one can combine small components into great things; components which in themselves are simple and easily understood.

Programming Languages and Local Reasoning

Through time, there have been two interesting trends in programming languages: towards better guarantees and later binding.

With "guarantees", I mean facts and invariants which the language rules permit us to conclude from the code. Such as the following - you may or may not recognize them (and the language features which give rise to them):

• "The value in this variable is of this type."
• "The value in this variable can only come from one of these expressions."
• "The value of this object field can not be changed once the object has been constructed."
• "This variable can only be accessed from one thread."
• "This method can not be redefined in subclasses."
• "This process will always be notified when this other process disappears."
• "If this code point is reached, then this other code point will eventually be reached."

The two trends, better guarantees and later binding, correspond to two desirable properties of software: the ability to reason about the behaviour of software, and flexibility.