A good designer must rely on experience, on precise, logic thinking; and on pedantic exactness. No magic will do.
After more than 30 years of programming we ought to know that the design of complex software is inherently difficult.
As a matter of fact, the adaptability of a program to changes in its objectives (often called maintainability) and to challges in its environment in terms of the degree to which it is neatly structured.
As a result, software engineering has become the El Dorado for hackers. The more chaotic a program looks, the smaller the danger that someone will take the trouble of inspecting and debunking it.
But active programming consists of the design of new programs, rather than contemplation of old programs.
But quality of work can be expected only through personal satisfaction, dedication and enjoyment. In our profession, precision and perfection are not a dispensible luxury, but a simple necessity.
Clearly, programming courses should teach methods of design and construction, and the selected examples should be such that a gradual development can be nicely demonstrated.
During the process of stepwise refinement, a notation which is natural to the problem in hand should be used as long as possible.
Experience shows that the success of a programming course critically depends on the choice of these examples.
I have never designed a language for its own sake.
I know of a particular, very large software producer that explicitly assumes that design takes 20% of developers' time, and debugging takes 80%.
If students have grasped the important ideas and have gained a certain versatility and familiarity with the subject, they find no difficulty in adapting to other languages if required (although they typically complain about the new inconveniences).
In the practical world of computing, it is rather uncommon that a program, once it performs correctly and satisfactorily, remains unchanged forever.
Indeed, the woes of Software Engineering are not due to lack of tools, or proper management, but largely due to lack of sufficient technical competence.
It is evidently necessary to generate and test candidates for solutions in some systematic manner.
Keeping a language as simple and as regular as possible has always been a guideline in my work; the description of Pascal took some 50 pages, that of Modula 40, and Oberon's a mere 16 pages.
Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy.
My being a teacher had a decisive influence on making language and systems as simple as possible so that in my teaching, I could concentrate on the essential issues of programming rather than on details of language and notation.
My duty as a teacher is to train, educate future programmers.
Nevertheless, I consider OOP as an aspect of programming in the large; that is, as an aspect that logically follows programming in the small and requires sound knowledge of procedural programming.
Our ultimate goal is extensible programming (EP). By this, we mean the construction of hierarchies of modules, each module adding new functionality to the system.
Program construction consists of a sequence of refinement steps.
Programming is usually taught by examples.
Software development is technical activity conducted by human beings.
The creative activity of programming - to be distinguished from coding - is usually taught by examples serving to exhibit certain techniques.
The degree of modularity obtained in this way will determine the ease or difficulty with which a program can be adapted to changes or extensions of the purpose or changes in the environment (language, computer) in which it is executed.
The idea that one might derive satisfaction from his or her successful work, because that work is ingenious, beautiful, or just pleasing, has become ridiculed.
The possible solutions to a given problem emerge as the leaves of a tree, each node representing a point of deliberation and decision.
The wealth of features of many languages is indeed a problem rather than a solution.
Usually its users discover sooner or later that their program does not deliver all the desired results, or worse, that the results requested were not the ones really needed.
Yet, I am convinced that there is a need for high quality software, and the time will come when it will be recognized that it is worth investing effort in its development and in using a careful, structured approach based on safe, structured languages.
You can share a link to this page with your friend!