Good Ideas, Through the Looking Glass, Niklaus Wirth

Abstract
An entire potpourri of ideas is listed from the past decades of Computer Science and Computer Technology. Widely acclaimed at their time, many have lost in splendor and brilliance under today’s critical scrutiny. We try to find reasons. Some of the ideas are almost forgotten. But we believe that they are worth recalling, not the least because one must try to learn from the past, be it for the sake of progress, intellectual stimulation, or fun.

Extrait sur les différents types de langages de programmation :

6. Programming paradigms
6.1. Functional programming
Functional languages had their origin in Lisp [2]. They have undergone a significant amount of development and change, and they have been used to implement small and large software systems. This author has always maintained a critical attitude towards such efforts. Why?
What is, or what characterizes a functional language? It has always appeared that it was their form, the fact that the entire program consists of function evaluations, nested, recursive, parametric, etc. Hence the term functional. However, the core of the idea is that functions inherently have no state. This implies that there are no variables and no assignments. The place of variables is taken by immutable function parameters, variables in the sense of mathematics. As a consequence, freshly computed values cannot be reassigned to the same variable, overwriting its old value. This is why repetion must be expressed with recursion. A data structure can at best be extended, but no change is possible in its old part. This yields an extremely high degree of storage recycling; a garbage collector is the necessary ingredient. An implementation without automatic garbage collection is unthinkable.
To postulate a state-less model of computation on top of a machinery whose most eminent characteristic is state, seems to be an odd idea, to say the least. The gap between model and machinery is wide, and therefore costly to bridge. No hardware support feature can wash this fact aside: It remains a bad idea for practice. This has in due time also been recognized by the protagonists of functional languages. They have introduced state (and variables) in various tricky ways. The purely functional character has thereby been compromised and sacrificed. The old terminology has become deceiving.
Looking back at the subject of functional programming, it appears that its truly relevant contribution was certainly not its lack of state, but rather its enforcement of clearly nested structures, and of the use of strictly local objects. This discipline can, of course, also be practiced using conventional, imperative languages, which have subscribed to the notions of nested structures, functions and recursion long ago. Of course, functional programming implies much more than avoiding goto statements. It also implies restriction to local variables, perhaps with the exception of very few global state variables. It probably also considers the nesting of procedures as undesirable. The B5000
26
computer apparently has been right, after all, in restricting access to strictly local and strictly global variables.
Are functional languages thus a category of their own merely due to terminology? Are their functions functions by form only, but not by substance? Or is the substance of the functional paradigm expressed by simply saying: “No side-effects”?
Many years ago, and with increasing frequency, it is claimed that functional languages are the best vehicle to introduce parallelism. It would be more to the point to say: To facilitate compilers to detect opportunities for parallelizing a program. After all, it is relatively easy to determine which parts of an expression may be evaluated concurrently. More important is that parameters of a called function may be evaluated concurrently, provided, of course, that side-effects are banned (which cannot occur in a truly functional language). As this may be true and perhaps of marginal benefit, this writer believes that a more effective way to let a system make good use of parallelism is provided by object-orientation, each object representing its own behaviour in the form of a “private” process.
6.2. Logic programming
Another instance of programming paradigm that has received wide attention is that of logic programming. Actually, there is only a single well-known language representing this paradigm: Prolog. Its principal idea is that the specification of actions, such as assignment to variables, is replaced by the specification of predicates on states. If one or several of a predicate’s parameters are left unspecified, the system searches for all possible argument values satisfying the predicate. This implies the existence of a search engine looking for solutions of logic statements. This mechanism is complicated, often time-consuming, and sometimes inherently unable to proceed without intervention. This, however, requires that the user must support the system by providing hints (cuts), and therefore must understand what is going on, must understand the process of logic inference, the very thing that he had been promised to be able to ignore.
One must suspect that an interesting intellectual exercise was sold to the public by raising great expectations. The community was in desperate need for ways to produce better, more reliable software, and was glad to hear of a possible panacea. But the promises never materialized. We sadly recall the exaggerated hopes that fueled the project of the Japanese Fifth Generation Computer, Prolog’s inference machines. Large amounts of resources were sunk into it. That was an unwise and now forgotten idea.
6.3. Object-oriented programming
In contrast to functional and logic programming, object-oriented programming (OOP) rests on the same priciples as conventional, procedural programming. Its character is imperative. A process is described as a sequence of transformations of a state. The novelty is the partitioning of a global state into individual objects, and the association of the state transformers (called methods) with the object itself. The objects are seen as the actors, causing other objects to alter their state by sending messages to them. The description of an object template is called a class definition.
This paradigm closely reflects the structure of systems “in the real world”, and it is therefore well suited to model complex systems with complex behaviour. Not
27
surprisingly, oop has its origins in the field of system simulation (Simula, Dahl and Nygaard, 1966). Its success in the field of software system design speaks for itself. Its career started with the language Smalltalk [5] and continued with Object-Pascal, C++, Eiffel, Oberon, Java, C#. The original Smalltalk implementation provided a convincing example of its suitability. It was the first to feature windows, menues, buttons and icons, perfect examples of (visible) objects in the sense outlined above. These examples were the carriers to success and wide acceptance. The direct modelling of actors diminished the importance of proving program correctness analytically, because the original specification is one of behaviour, rather than a static input-output relationship.
Nevertheless, the careful observer may wonder, where the core of the new paradigm would hide, what was the essential difference to the traditional view of programming. After all, the old cornerstones of procedural programming reappear, albeit embedded in a new terminology: Objects are records, classes are types, methods are procedures, and sending a method is equivalent to calling a procedure. True, records now consist of data fields and, in addition, methods; and true, the feature called inheritance allows the construction of heterogeneous data structures, useful also without object-orientation. Was this change of terminology expressing an essential paradigm shift, or was it a vehicle for gaining attention, a “sales trick”?


http://www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas_origFig.pdf