- Oct 2020
"Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained —on the contrary!— by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focussing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.
Dijkstra posits that a characteristic of what he calls "intelligent thinking" is the tendency to practice a "separation of concerns". By this he means thinking about concepts separate of one another for the sake of their own consistency, rather than simultaneously, which doesn't help in ordering your thinking.
- May 2020
The task of "making a thing satisfying our needs" as a single responsibility is split into two parts "stating the properties of a thing, by virtue of which it would satisfy our needs" and "making a thing guaranteed to have the stated properties". Business data processing systems are sufficiently complicated to require such a separation of concerns and the suggestion that in that part of the computing world "scientific thought is a non-applicable luxury" puts the cart before the horse: the mess they are in has been caused by too much unscientific thought.
Dijkstra suggested that instead of concerning ourselves with a software system that meets the user's needs, we should first separate our concerns.
We should first concern ourselves with the user's needs and draw up careful specifications – properties to which the system should adhere should it satisfy the user's needs.
With those specifications in hand we can concern ourselves with making a system guaranteed to have stated properties.
The problem with this thinking, which the software industry would later discover, is that a user's needs cannot be accurately or completely determined before building the system. We learn more about what is needed by the process of building.
This is an instance of the [[Separation of concerns]] not working.
This is also why the industry has settled on a technique to build iteratively (Agile), always leaving the option open to change course.
Some time ago I visited the computing center of a large research laboratory where they were expecting new computing equipment of such a radically different architecture, that my colleagues had concluded that a new programming language was needed for it if the potential concurrency were to be exploited to any appreciable degree. But they got their language design never started because they felt that their product should be so much like FORTRAN that the casual user would hardly notice the difference "for otherwise our users won't accept it". They circumvented the problem of explaining to their user community how the new equipment could be used at best advantage by failing to discover what they should explain. It was a rather depressing visit.... The proper technique is clearly to postpone the concerns for general acceptance until you have reached a result of such a quality that it deserves acceptance. It is the significance of your message that should justify the care that you give to its presentation, it may be its "unusualness" that makes extra care necessary.
When you've developed an idea, you will typically want to communicate that idea so that it can be understood and used more generally. Dijkstra calls this reaching "general acceptance".
To do so, you must communicate the idea in a way so that it can be properly understood and used. For certain ideas this becomes a challenging problem in and of itself.
Many forgo this challenge, and instead of figuring out what new language they need to invent to most accurately communicate the idea, they use legacy language and end up communicating their idea less effectively, in pursuit of general acceptance.
Dijkstra says that the proper way of dealing with this dilemma is to separate your concerns. You separate your concern of the solution from the concern of communicating the solution.
When you've reached a solution that is of such high quality that it deserves communicating – and only then – do you concern yourself with its presentation.