🚀 go-pugleaf

In article <BGLENDEN.90Nov21143012@mandrill.cv.nrao.edu> bglenden@mandrill.cv.nrao.edu (Brian Glendenning) writes:
>In article <PCG.90Nov8163939@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>   This discussion reminds me of Dijkstra's famous address in 1968 to some
>   (the IFIP?)  conference, on the software crisis, that went like this:
>
>     We have a software crisis, and we are told that we must advance the
>     state of the art so as to solve it. We are only given a few constraints
>     to satisfy:
>
>	     no changes to the hardware platforms
>	     no changes to the languages
>	     no changes to the operating systems 
>	     no changes to the education of programmers
>	     no changes to the software tools
>	     no changes to organizational practices
>	     ...
>
>     Well, this is RIDICULOUS!
>
>Does anyone have the correct reference for this (or even the actual
>text?) Thanks!
>
>Brian
>--
>       Brian Glendenning - National Radio Astronomy Observatory
>bglenden@nrao.edu          bglenden@nrao.bitnet          (804) 296-0286

The actual text:

Dijkstra: I would like to comment on the distinction that has been made
between practical and theoretical people. I must stress that I feel this
distinction to be obsolete, worn out, inadequate and fruitless. It is just no
good, if you want to do anything reasonable, to think that you can work
with such simple notions. Its inadequacy, amongst other things, is shown by 
the fact that I absolutely refuse to regard myself as either impractical or
not theoretical.
  David expressed the idea that "We can make case studies in industry, and
then you can study the results. You can do these analysis." A probable effect
of the distinction is that if such a study is made, the aoutput of it can be
reagrded as theory and therefore ignored. What is actually happening, I am
afraid, is that we all tell each other and ourselves that software engineering
techniques should be improved consideraly, because there is a crisis. But
there are a few boundary conditions which apparently have to be satisfied. I
will list them for you:
1 We may not change our thinking habits.
2 We may not change our programming tools.
3 We may not change our hardware.
4 We may not change our tasks.
5 We may not change the organizational set-up in which the work has to be done.
Now under these five immutable boundary conditions, we have to try to 
improve matters. This is utterly ridiculous. Thank you. (Applause)

This was copied from page 13 of the:

Report on a conference sponsored by the NATO SCIENCE COMMITTEE
Rome, Italy, 27th to 31th October 1969: SOFTWARE ENGINEERING TECHNIQUES

Copy of the contents of its page 2:

The present report is available from:
Scientidic Affairs Division
NATO
Brussels 39
Belgium

Publishers: NATO Science Committee

Printed in England at The Kynoch Press, Birmingham

IMHO, more than 20 years later, these boudaries have shown to be not
absolutely immutable: although we know that they cannot be changed
under our direct control, we see that they are changing (yes, not too
fast).
1 thinking habits:
  at least some of us are (becoming) aware that programming influences our
  thinking habits: especially programmers (like philosophers) tend to be
  utterly curious to know the exact semantics of what is said/written.
  Evidently this does not simplify their communications with other people,
  but it seems to become one of their characteristic thinking habits
  because they have to model such semantics in the results of their
  activities.
2 programming tools:
  at least some fundamental changes can be observed:
  - support for more formal approaches (VDM / Z  and Eiffel)
  - functional programming with it lazy-evaluation (Prolog)
3 hardware:
  here again:
  - parallel processing and neural networks
  - integration of vidio (text, pictures and other data) with audio (sound)
4 tasks:
  hopefully most of us have learnt that two types of complexity should be
  distinguished:
  - the intrinsic complex tasks: those that we don't know how to divide into
    tasks which are less complex (e.g. travelling salesman)
  - the extrinsic complex tasks: those that can be broken down into less
    complex tasks.
  Fortunately, nearly all of us are working on the second type. It is just
  a shame that we do not always exploit this.
5 organizational set-up:
  yes, here too we can observe some weak signals that boundaries are changing:
  not longer centralization is prefered always above distribution (USSR,
  Philips).

-- 
###  Jaap A. Meeuse         ###  Internet:  meeuse@idca.tds.philips.nl   ###
###  Philips IS, Dept OFS   ###  UUCP    :  ..!mcsun!philapd!meeuse      ###