How do we tell truths that might hurt?

Sometimes we discover unpleasant truths. Whenever we do so, we are in
difficulties: suppressing them is scientifically dishonest, so we must
tell them, but telling them, however, will fire back on us. If the
truths are sufficiently impalatable, our audience is psychically
incapable of accepting them and we will be written off as totally
unrealistic, hopelessly idealistic, dangerously revolutionary, foolishly
gullible or what have you. (Besides that, telling such truths is a sure
way of making oneself unpopular in many circles, and, as such, it is an
act that, in general, is not without personal risks. Vide Galileo
Galilei.....)

Computing Science seems to suffer severely from this conflict. On the
whole, it remains silent and tries to escape this conflict by shifting
its attention. (For instance: with respect to COBOL you can really do
only one of two things: fight the disease or pretend that it does not
exist. Most Computer Science Departments have opted for the latter easy
way out.) But, Brethern, I ask you: is this honest? Is not our prolonged
silence fretting away Computing Science's intellectual integrity? Are we
decent by remaining silent? If not, how do we speak up?

To give you some idea of the scope of the problem I have listed a number
of such truths. (Nearly all computing scientists I know well will agree
without hesitation to nearly all of them. Yet we allow the world to
behave as if we did not know them....)

Programming is one of the most difficult branches of applied
mathematics; the poorer mathematicians had better remain pure
mathematicians.

The easiest machine applications are the technical/scientific
computations.

The tools we use have a profound (and devious!) influence on our
thinking habits, and, therefore, on our thinking abilities.

FORTRAN --"the infantile disorder"--, by now nearly 20 years old, is
hopelessly inadequate for whatever computer application you have in mind
today: it is now too clumsy, too risky, and too expensive to use.

PL/I --"the fatal disease"-- belongs more to the problem set than to the
solution set.

It is practically impossible to teach good programming to students that
have had a prior exposure to BASIC: as potential programmers they are
mentally mutilated beyond hope of regeneration.

The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence.

APL is a mistake, carried through to perfection. It is the language of
the future for the programming techniques of the past: it creates a new
generation of coding bums.

The problems of business administration in general and data base
management in particular are much too difficult for people that think in
IBMerese, compounded with sloppy English.

About the use of language: it is impossible to sharpen a pencil with a
blunt axe. It is equally vain to try to do it with ten blunt axes
instead.

Besides a mathematical inclination, an exceptionally good mastery of
one's native tongue is the most vital asset of a competent programmer.

Many companies that have made themselves dependent on IBM-equipment (and
in doing so have sold their soul to the devil) will collapse under the
sheer weight of the unmastered complexity of their data processing
systems.

Simplicity is prerequisite for reliability. [Handwritten annotation]

We can found no scientific discipline, nor a hearty profession on the
technical mistakes of the Department of Defense and, mainly, one
computer manufacturer.

The use of anthropomorphic terminology when dealing with computing
systems is a symptom of professional immaturity.

By claiming that they can contribute to software engineering, the soft
scientists make themselves even more ridiculous. (Not less dangerous,
alas!) In spite of its name, software engineering requires (cruelly)
hard science for its support.

In the good old days physicists repeated each other's experiments, just
to be sure. Today they stick to FORTRAN, so that they can share each
other's programs, bugs included.