July 2001

Promotion of Complex Semantics

Introduction

Using semantically simple languages to construct complex ideas is far from elegant. May academics are attracted to these minimalist languages because they can be analyzed formally. I do not dispute the value of formal analysis here, I dispute the use of simple languages to implement complex ideas.

If the useful concepts I propose can be constructed from the simple, then why is it so bad to do so? It is bad because the complexity of the final system is greater than in an environment with complex primitives. The extra complexity comes from the definitions of the complex primitives in simple terms, and from the interaction of their implementations with higher level constructs.

Some simple ideas are:

• Goto; in program control flow
• Everything is a function

Goto is Bad

The use of Goto in program flow is an excellent example to start with. Before structured programming, the goto performed necessary operations for if-else blocks and looping. The advent of structured programming, and high-level control structures, allowed programs to be clearer and therefore make programmer more effective. The extra complexity added to the domain language allowed for greater expressiveness in the form of improved clarity. Simply defining these control structures in terms of goto (like Dylan) does not preclude the use of goto, therefore clarity is not forced and is dangerously left as an option for the inexperienced.

Furthermore, the definition of the high level constructs, in terms of the simple, are inmutable; they can not change depending on the system that executes the code. For simple processors, ones without a pipeline, a loop is best described so a minimum number of instructions are executed. But for a complex processor, the code should be rearranged to take advantage of some pipelining assumptions made by the processor. In these cases, the complex primitives are saying less about the intended execution of the program when it does not matter, freeing the implementation to be optimized for the platform.

Pure Functional is Bad

Everything as a function is another simple idea that can lead to unintuitive implementation. The cleanliness of pure functional languages has appealed to the minimalist nature of the academic community. It was the simplicity of the idea that allowed it the bend under formal analysis. The enjoyment of pure functional languages is purely academic, and does not come from a productivity perspective. Note that pure functional languages have to bend backwards to implement state. They use monads to pass the state back to the calling function, and fill lambda space with redefined functions. This is not to say that functional languages have nothing to teach use. The academic community has spent much time revealing the benefits. Only recently have the detriments become clear. Pure functional programming is not the ultimate language paradigm; a language must be complex to be expressive.

C++ is a complex language medium allowing greater expressiveness. In the hands of a master, C++ can create extremely powerful programs in very few lines. Perl is another example of a complex language that is extremely expressive. But please note that much of Perl's expressiveness comes from the fact it was intended to be a domain specific language, outside of Perl's element C++ can be a better choice.

The Lisps are very expressive, but that expressiveness is NOT a consequence of the everything-is-a-function paradigm. Many of the Lisp's expressive advantages come from the inherent view of data as lists, and the ability to refer to functions as first order objects.

Drawbacks of Complex Semantics

The drawbacks of complex primitives can be demonstrated in the learning curve required for C++. The complexity of the language has hindered its acceptance with the programming community. Newer, sleeker languages, such as Java, have overtaken it. Java has removed much of the complexity from C++, but still maintained the core OO concepts. Rightly so, it was in Sun's best interest to make Java easy to assimilate. There are many complex ideas that Java does not have, like templates and operator overloading, that would have made it a more expressive language.

 July 2001, finished draft