Published in Software Development, Vol. 5 No. 6, June 1997.
Niklaus Wirth is one of the most influential thinkers in the software
world. A professor at ETH Institute in Zurich, Wirth designed
Pascal, Modula 2 and Oberon. In the early 1970s, he was one of
the people who proposed program development by stepwise refinment.
He's the author of many important books, including "Algorithms
+ Data Structures = Programs" (Prentice Hall, 1975) and "Systematic
Programming" (Prentice Hall, 1973)He was awarded the Turing
Prize in 1984, and has also received five honorary doctorates
and several other awards.
It was a pleasure to ask him a few questions regarding today's
state of software development, as well as that of the future.
As you'll see, Wirth has very strong opinions on the subject,
and he states them with absolute precision.
CP:
You are one of the most influential academics. Your work had a
great impact on both the study and the practice of software development.
However, in many cases, the university environment and the "real
world" are, indeed, very different. When I talk with a professor
and then with a programmer, I often notice that they think about
software in very different ways. A recent IEEE survey of what
lie ahead in software revealed that there is basically no intersection
between the opinions of academics and practitioners. As one of
the few whose work has been influential in both fields, what's
your opinion (or perhaps your secret)?
NW:
If there is a secret at all, then it is that of being both a programmer
and a professor. The division is rather unfortunate and the source
of many problems. Professors typically spend their time in meetings
about planning, policy, proposals, fund raising, consulting, interviewing,
travelling, and so forth, but spend relatively little time at
their drawing boards. As a result, they lose touch with the substance
of their rapidly developing subject. They lose the ability to
design; they lose sight of what is essential; and resign to teach
academically challenging puzzles. I have never designed a language
for its own sake. Instead, I've always designed a language because
I had a practical need that was not satisfied by languages that
where already available. For example, Modula and Oberon were by-products
of the designs of the workstations Lilith (1979) and Ceres (1986).
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.Yes, the drifting apart of
practice and academia is unfortunate.
CP:
You probably know about the "good enough software" concept
popularized by Yourdon. In many senses, it's just a rationalization
of what's happening in the software world: the first company hitting
the market with a feature-rich product is more likely to win the
battle than the careful, quality-seeking company. Do you think
there is anything developers and software organizations can do
about that? I guess many developers would be happy to be given
more time to develop better software, but at the same time they
are rushed in the name of corporate survival. "Educating
the users" seems more a wild dream than a possibility.
NW:
"Good enough software" is rarely good enough. It is
a sad manifestation of the spirit of modern times, in which an
individual's pride in his/her work has become rare. 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. Nothing but economic success and monetary reward
is acceptable. Hence our occupations have become mere jobs. 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.
CP:
As you know, there is a large debate about software engineering
as a profession. In fact, many software developers never had a
strong education, or any significant experience. Do you think
software engineers should be licensed, as other engineers? Should
something be changed in the curricula of software engineers/computer
scientist to make them more effective? What, in your opinion,
is the ideal education a software engineer should have?
NW:
Recently I read a final report of a research project funded by
the Swiss National Science Foundation. The project's naive goals
were identified as follows: First, how can easy programming be
achieved (in particular, for non-experts)? Second, how can a mechanism
be realized that allows hiding the difficult parts of parallel
programming?After more than 30 years of programming we ought to
know that the design of complex software is inherently difficult.
This despite of the fact that, for decades, the industry has been
advertising programmers' positions by claiming that programming
is easy. Later on, when doubts arose even to the advertisers,
they switched to promising a wide variety of tools to facilitate
the arduous tasks. Tools became the slogan; the right tools, paired
with clever tricks and serious managenment methods, would work
wonders. Then Edsger Dijkstra called Software Engineering "Programming
in spite of the fact that you can't".
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. A good designer must rely on experience,
on precise, logic thinking; and on pedantic exactness. No magic
will do. In the light of all this it is particularly sad that
in many informatics curricula, programming in the large is badly
neglected. Design has become a non-topic. 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.
CP:
Speaking of education, many peoples think that it's easier to
learn the object oriented paradigm if you don't have previous
experience with another paradigm. This seems like a big mistake
to me, because I feel that an experienced developer should have
a knowledge of many paradigms. In my opinion, early software engineering
works (like Parnas' papers) and programming classics like Systematic
Programming are as useful today as they were years ago. What's
your opinion?
NW:
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. It is maintained for commercial
reasons only. Object-oriented programming (OOP) solidly rests
on the principles and concepts of traditional procedural programming
(PP). OOP has not added a single novel concept, but it emphasizes
two concepts much more strongly that was done with procedural
programming. The fist such concept is that of the procedure bound
to a composite variable called object. (The binding of the procedure
is the justification for it being called a method). The means
for this binding is the procedure variable (or record field),
available in languages since the mid 1970s. The second concept
is that of constructing a new data type (called subclass) by extending
a given type (the superclass).
It is worthwhile to note that along with the OOP paradigm came
an entirely new terminology with the purpose of mystifying the
roots of OOP. Thus, whereas you used to be able to activate a
procedure by calling it, one now sends a message to the method.
A new type is no longer built by extending a given type, but by
defining a subclass which inherits its superclass. An interesting
phenomenon is that many people learned for the first time about
the important notions of data type, of encapsulation, and (perhaps)
of information hiding when introduced to OOP. This alone would
have made the introduction to OOP worthwhile, even if one didn't
actually make use of its essence later on.
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.
Static modularization is the first step towards OOP. It is much
easier to understand and master than full OOP, it's sufficient
in most cases for writing good software, and is sadly neglected
in most common languages (with the exception of Ada).
In a way, OOP falls short of its promises. 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. EP implies that the addition of a module is possible
without any change in the existing modules. They need not even
be recompiled. New modules not only add new procedures, but -
more importantly - also new (extended) data types. We have demonstrated
the practicality and economy of this approach with the design
of the Oberon System.
CP:
Recently I come across an advertisement for Borland Delphi (which
as you know is a sort of O.O. Pascal with extensions for event
handling) that said "Delphi 2.0 gives developers a language
almost as readable as BASIC...". Apparently it was a quote
from a review of the product. But it sounded so terribly wrong
to me. "Almost as readable" as a language without a
sound notion of data type? On the other hand, we cannot hide the
fact that to a large extent, basic (Visual Basic) has won on the
market, and is probably the first example of a commercial language
with a huge market of components. As the father of Pascal, what
is your opinion? Did basic really win? If so, why?
NW:
We must be careful with words like "readable", "user
friendly", etc. They are vague at best, and often refer to
taste and established habits. But what is conventional need not
necessarily also be convenient. In the context of programming
langauges, perhaps "readable" should be replaced by
"amenable to formal reasoning". For example, mathematical
formulas are hardly what we might praise as easily readable, but
they allow the formal derivation of properties that could not
be obtained from a vague, fuzzy, informal, user friendly circumscription.
The construct WHILE B DO S END has the remarkable property that
you may rely on B being false after the statement's execution,
independent of S. And if you find a property P that is left invariant
by S, you may assume that also P holds upon termination. It is
this kind of reasoning that helps in the reliable derivation of
programs, and that dramatically reduces the time wasted on testing
and debugging. Good languages not only rest on mathematical concepts
which make logical reasoning about programs possible, but also
on a small number of concepts and rules that can freely be combined.
If the definition of a language requires fat manuals of hundred
pages and more, and if the definition refers to a mechanical model
of execution (i.e. to a computer), this must be taken as a sure
symptom of inadequacy. But alas, in this respect, 1960'Algol was
far ahead of most of its successors, in particular of all those
that are so popular today.
CP:
Another very popular language is C++. I know you are not particularly
fond of it, and that in many cases, a safer language could be
better. However, sometimes I wonder if it wouldn't be wiser to
help programmers instead of battling them. For instance, in many
cases C++ programmers would be happy to use a safer version of
the language: not all of them are so concerned with 100% compatibility
with C. A version of C++ were pointers and arrays are clearly
separated, and were you get a warning when (e.g.) you assign a
float to a long, and so on, would help them to write better programs
and still not require to learn a completely new language. I understand
that it is more pleasing to design a pure language than trying
to make a fragile one safer, but then, if just a handful of peoples
use this pure language, are we really advancing the state of the
software development?
NW:
My duty as a teacher is to train, educate future programmers.
In trying to do this as well as possible, I present fundamental
notions as clearly and succinctly as possible. I certainly do
not let an inadequate notation hinder me in this task. 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). I do not see why anyone would call
this "battling programmers". One may indeed wonder why
nobody in the vast software industry has undertaken the task proposed
by you: Defining a safe subset of C++. I can figure out two reasons:
(1) The software world is eager for "more powerful"
languages, but not for restrictive subsets. And (2), such attempts
are doomed to fail just like attempts to strengthen the structure
of a house built on sand. There are things that you simply cannot
add as an afterthought.
CP:
Isn't the software development community focusing too much on
technical issues, forgetting that software development is mostly
a human activity? For instance, I think that one of the reasons
for the popularity of BASIC and C is that their relative lack
of constraints allows for some "local solutions" (euphemism
for patch :-) to be introduced late in the development cycle.
We all know that we should carefully design software before going
to code. But we also know very well that, in most cases, management
does not want to pay now for long term benefits. This is one of
the reasons some peoples are not so happy with OOP. Hence, software
is routinely patched when it's already in an advanced state of
development. A language that lets that happen without too much
concern will be more widely used than one which requires a large
investment in up-front design. But then we continue to bash programmers
for being "dirty" when in fact they are just playing
in the real world, not in an ideal world. Wouldn't be better to
think about programming languages with more consideration for
human issues?
NW:
Software development is technical activity conducted by human
beings. It is no secret that human beings suffer from imperfection,
limited reliability, and impatience - among other things. Add
to it that they have become demanding, which leads to the request
for rapid, high performance in return for the requested high salaries.
Work under constant time pressure, however, results in unsatisfactory,
faulty products. Generally, the hope is that corrections will
not only be easy, because software is immaterial, but that the
custormers will be willing to share the cost. We know of much
better ways to design software than is common practice, but they
are rarely followed. I know of a particular, very large software
producer that explicitly assumes that design takes 20% of developers'
time, and debugging takes 80% . Although internal advoctates of
an 80% design time vs. 20% debugging time have not only proven
that their ratio is realistic, but also that it would improve
the company's tarnished image. Why, then, is the 20% design time
approach preferred? Because with 20% design time your product
is on the market earlier than that of a competitor consuming 80%
design time. And surveys show that the customer at large considers
a shaky but early product as more attractive than a later product,
even if it is stable and mature. Who is to blame for this state
of affairs? The programmer turned hacker; the manager under time
pressure; the business man compelled to extol profit wherever
possible; or the customer believing in promised miracles?
CP:
It seems to me that most modern programming languages are feature-loaded
to the point that many programs require 20% of the language (or
less). But most of these features are about increased flexibility,
not about increased safety. For instance, the old rule "declare
before use" was a recognition that programmers make errors,
and enforcing that rule allowed the compilers to detect some errors.
Likewise, the "obsolete" clause in Eiffel is a recognition
that some portions of the code become obsolete, but without a
compile-time warning most programmers will continue to rely on
them. Who has the time to read comments and documentation when
the product must ship immediately? However, while I've seen red-hot
debates about the usefulness of a "finally" clause in
C++, I've seen a relatively small interest in how to protect the
programmers (as humans) from themselves. What's your opinion?
NW:
The wealth of features of many languages is indeed a problem rather
than a solution. A multitude of features is another consequence
of the programmers' belief that the value of a language is proportional
to the quantity of its features and facilities, bells and whistles.
However, we know that it is better if each basic concept is represented
by a single, designated language construct. Not only does this
reduce the effort of learning, but it reduces the volume of the
language's description and thereby the possibilities of inconsistency
and of misunderstanding. 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. This I still consider to have been genuine progress.
The relevant value of high-level programming languages depends
on the quality and suitability of the abstractions they offer.
An example is the abstraction called number, or that of a logical
(truth) value, replacing concrete bit strings. The value of such
an abstraction rests on its integrity. In the case of numbers,
only arithmetic operations must be applicable, independent of
the fact that also logical operations could be applied to the
bitstrings representing the numbers.
Another case is the notion of the array with a given number of
elements identified by ordinal numbers (indices). It must be guaranteed
that no element can be accessed with an invalid index, despite
the fact that the resulting address computation would point to
some existing storage cell - probably holding another variable.
The abstraction we're talking about here is the important concept
of data type, and we point out that its value rests on the fact
that a compiler will verify that the rules governing the types
are obeyed, that the compiler will guarantee the abstraction's
integrity. If a system fails to do this, if it allows a logical
operation to be performed on numbers, or if it fails to indicate
array access with invalid index - just to name two examples -
it is hardly worth being called a high-level language system.
However, most widely used systems are exactly of this nature,
and the offered abstraction can be violated freely with the added
"benefit" of innumerable software tools that help inspect
how the abstraction is in fact represented internally in order
to find out what went wrong.
It is particularly ironical that languages with fixed structural
patterns for statements and data types, and with constructs for
modularization and information hiding, are widely regarded as
restrictive, cumbersome, and creativity-hindering. Indeed, programming
with a structured, strongly typed language usually requires a
greater amount of careful deliberation, and this is considered
as detrimental (remember that programming is advertised as being
easy). The irony of the matter is that the time gained by not
having been required to comply with structural rules, is lost
many times over by finding errors later on - in the field, perhaps
by the dissatisfied customer. The weather forecast promises not
much change. The concepts and the languages enabling a beneficial
development of programming into a serious engineering profession
have been with us for many years, but they remained largely unused,
and the trend rather leads further away from them instead. It
looks like software will remain a hackers' El Dorado for some
time to come. Certainly, computers will not complain. I remember
a long discussion in an academic seminar in the mid 1970s, when
the word "software crisis" was in full swing and the
notion of correctness proofs of programs was put forward as a
possible remedy.
Professor C.A.R. [Tony] Hoare, the speaker at the seminar, had
eloquently presented the principles and the advantages of correctness
proofs replacing testing. After a long discussion about the pros
and cons Jim Morris [department head at Carnegie Mellon University
and developer of principles like inter-module protection and lazy
evaluation] got up and disarmingly asked: "But Tony, what
is your answer if we frankly confess that we dearly love debugging?
You want us to abandon our most cherished enjoyment?"
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. For the time being,
however, this is practicable only for some "niche products".
The niche will expand when a growing number of people will voice
their dissatisfaction with poor software.
Biography
Carlo Pescio holds a doctoral degree in Computer
Science and is a consultant and mentor for various European companies
and corporations, including the Directorate of the European Commission.
He specializes in object oriented technologies and is a member
of IEEE Computer Society, the ACM, and the New York Academy of
Sciences. He lives in Savona, Italy and can be contacted at pescio@eptacom.net.