Mixing
Did Dijkstra intend for code modularization, when he wrote about separation of concerns?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
First, I read an excerpt Edsger W. Dijkstra's 1974 paper "On the role of scientific thought":
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 "focusing 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.
I see modern separation of concerns talk about modularizing your code. However, reading the quote above, I understand this as focusing your mind onto one particular task at a time, while not focusing on other aspects. This does not mean to me necessarily that code needs to be separated into modular chunks.
That is, say there is a code in front of you that in one file has the concepts of view, repository, controller, event handling, factory, etc. all in one file.
For a brief example, here's some code that has data access, and view (output):
$sql = "SELECT * FROM resource.productspec WHERE id = " . db_input($id);
$row = db_fetch_array(db_query($sql));
<option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? ' selected="selected"' : '' ?>>Version <?=$row['ver']?></option>
Using modern OO I could place data access in its own file, view code into its own file template, and wire those up to communicate via controller, and have a factory to create and wire up various dependencies.
My question on separation of concerns is like so: reading Dijkstra's quote, I got an idea that perhaps he did not necessarily mean for separation of concerns to be "modular separation of code (into files or their own functions/methods/etc)", and that he meant more so to focus one's mind upon an aspect of the program, without burdening yourself focusing on other important yet not-currently-to-be-considered aspects, regardless of whether they are physically separated in code, or not.
Why then are we burdening ourselves with physical modular code separation and design patterns? Will it be not enough to just focus oneself onto an aspect, regardless of how your code is structured?
I am not talking about writing up the most horrible spaghetti code and then only considering an aspect of it, that would likely be a burden.
But in the end, what I am going towards, is, why perform the physical code separation, why split the code up into separated files or chunks (methods), when it is not necessary for mentally focusing yourself on an aspect?
Should separation of concerns remain a mental exercise, rather than physical?
In other words, should there be a disconnect between the mental (focus on) and the physical (code on paper) aspects of programming?
source-code separation-of-concerns modularization dijkstra
asked 3 hours ago
Dennis
3,65032344
add a comment |Â
up vote
4
down vote
favorite
First, I read an excerpt Edsger W. Dijkstra's 1974 paper "On the role of scientific thought":
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 "focusing 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.
I see modern separation of concerns talk about modularizing your code. However, reading the quote above, I understand this as focusing your mind onto one particular task at a time, while not focusing on other aspects. This does not mean to me necessarily that code needs to be separated into modular chunks.
That is, say there is a code in front of you that in one file has the concepts of view, repository, controller, event handling, factory, etc. all in one file.
For a brief example, here's some code that has data access, and view (output):
$sql = "SELECT * FROM resource.productspec WHERE id = " . db_input($id);
$row = db_fetch_array(db_query($sql));
<option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? ' selected="selected"' : '' ?>>Version <?=$row['ver']?></option>
Using modern OO I could place data access in its own file, view code into its own file template, and wire those up to communicate via controller, and have a factory to create and wire up various dependencies.
My question on separation of concerns is like so: reading Dijkstra's quote, I got an idea that perhaps he did not necessarily mean for separation of concerns to be "modular separation of code (into files or their own functions/methods/etc)", and that he meant more so to focus one's mind upon an aspect of the program, without burdening yourself focusing on other important yet not-currently-to-be-considered aspects, regardless of whether they are physically separated in code, or not.
Why then are we burdening ourselves with physical modular code separation and design patterns? Will it be not enough to just focus oneself onto an aspect, regardless of how your code is structured?
I am not talking about writing up the most horrible spaghetti code and then only considering an aspect of it, that would likely be a burden.
But in the end, what I am going towards, is, why perform the physical code separation, why split the code up into separated files or chunks (methods), when it is not necessary for mentally focusing yourself on an aspect?
Should separation of concerns remain a mental exercise, rather than physical?
In other words, should there be a disconnect between the mental (focus on) and the physical (code on paper) aspects of programming?
source-code separation-of-concerns modularization dijkstra
asked 3 hours ago
Dennis
3,65032344
2
I'm pretty sure that by 1974, he just saw modular programming as an obvious given, and that's why he didn't explicitly discuss it in that paper. Parnas' paper about how to modularize was in 1972, and by that time whether to modularize was already no longer a question. In fact, what you describe isn't even modular programming, it is structured programming, which Dijkstra himself strongly argued in favor of already in 1968 in his classic "Go To Considered Harmful" paper.
– Jörg W Mittag
3 hours ago
alright so perhaps I can understand 'separation of concerns' more as a mental focus exercise, and modularization as a way to encapsulate an aspect of code on paper. However I now see separation of concerns and modularization more as separate concepts.
– Dennis
3 hours ago
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
First, I read an excerpt Edsger W. Dijkstra's 1974 paper "On the role of scientific thought":
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 "focusing 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.
I see modern separation of concerns talk about modularizing your code. However, reading the quote above, I understand this as focusing your mind onto one particular task at a time, while not focusing on other aspects. This does not mean to me necessarily that code needs to be separated into modular chunks.
That is, say there is a code in front of you that in one file has the concepts of view, repository, controller, event handling, factory, etc. all in one file.
For a brief example, here's some code that has data access, and view (output):
$sql = "SELECT * FROM resource.productspec WHERE id = " . db_input($id);
$row = db_fetch_array(db_query($sql));
<option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? ' selected="selected"' : '' ?>>Version <?=$row['ver']?></option>
Using modern OO I could place data access in its own file, view code into its own file template, and wire those up to communicate via controller, and have a factory to create and wire up various dependencies.
My question on separation of concerns is like so: reading Dijkstra's quote, I got an idea that perhaps he did not necessarily mean for separation of concerns to be "modular separation of code (into files or their own functions/methods/etc)", and that he meant more so to focus one's mind upon an aspect of the program, without burdening yourself focusing on other important yet not-currently-to-be-considered aspects, regardless of whether they are physically separated in code, or not.
Why then are we burdening ourselves with physical modular code separation and design patterns? Will it be not enough to just focus oneself onto an aspect, regardless of how your code is structured?
I am not talking about writing up the most horrible spaghetti code and then only considering an aspect of it, that would likely be a burden.
But in the end, what I am going towards, is, why perform the physical code separation, why split the code up into separated files or chunks (methods), when it is not necessary for mentally focusing yourself on an aspect?
Should separation of concerns remain a mental exercise, rather than physical?
In other words, should there be a disconnect between the mental (focus on) and the physical (code on paper) aspects of programming?
source-code separation-of-concerns modularization dijkstra
asked 3 hours ago
Dennis
3,65032344
First, I read an excerpt Edsger W. Dijkstra's 1974 paper "On the role of scientific thought":
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 "focusing 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.
I see modern separation of concerns talk about modularizing your code. However, reading the quote above, I understand this as focusing your mind onto one particular task at a time, while not focusing on other aspects. This does not mean to me necessarily that code needs to be separated into modular chunks.
That is, say there is a code in front of you that in one file has the concepts of view, repository, controller, event handling, factory, etc. all in one file.
For a brief example, here's some code that has data access, and view (output):
$sql = "SELECT * FROM resource.productspec WHERE id = " . db_input($id);
$row = db_fetch_array(db_query($sql));
<option value="<?=$row['id']?>"<?= $row['ver'] == $row['ver'] ? ' selected="selected"' : '' ?>>Version <?=$row['ver']?></option>
Using modern OO I could place data access in its own file, view code into its own file template, and wire those up to communicate via controller, and have a factory to create and wire up various dependencies.
My question on separation of concerns is like so: reading Dijkstra's quote, I got an idea that perhaps he did not necessarily mean for separation of concerns to be "modular separation of code (into files or their own functions/methods/etc)", and that he meant more so to focus one's mind upon an aspect of the program, without burdening yourself focusing on other important yet not-currently-to-be-considered aspects, regardless of whether they are physically separated in code, or not.
Why then are we burdening ourselves with physical modular code separation and design patterns? Will it be not enough to just focus oneself onto an aspect, regardless of how your code is structured?
I am not talking about writing up the most horrible spaghetti code and then only considering an aspect of it, that would likely be a burden.
But in the end, what I am going towards, is, why perform the physical code separation, why split the code up into separated files or chunks (methods), when it is not necessary for mentally focusing yourself on an aspect?
Should separation of concerns remain a mental exercise, rather than physical?
In other words, should there be a disconnect between the mental (focus on) and the physical (code on paper) aspects of programming?
source-code separation-of-concerns modularization dijkstra
source-code separation-of-concerns modularization dijkstra
asked 3 hours ago
Dennis
3,65032344
asked 3 hours ago
Dennis
3,65032344
asked 3 hours ago
Dennis
3,65032344
asked 3 hours ago
Dennis
3,65032344
asked 3 hours ago
Dennis
3,65032344
3,65032344
2
I'm pretty sure that by 1974, he just saw modular programming as an obvious given, and that's why he didn't explicitly discuss it in that paper. Parnas' paper about how to modularize was in 1972, and by that time whether to modularize was already no longer a question. In fact, what you describe isn't even modular programming, it is structured programming, which Dijkstra himself strongly argued in favor of already in 1968 in his classic "Go To Considered Harmful" paper.
– Jörg W Mittag
3 hours ago
alright so perhaps I can understand 'separation of concerns' more as a mental focus exercise, and modularization as a way to encapsulate an aspect of code on paper. However I now see separation of concerns and modularization more as separate concepts.
– Dennis
3 hours ago
add a comment |Â
2
I'm pretty sure that by 1974, he just saw modular programming as an obvious given, and that's why he didn't explicitly discuss it in that paper. Parnas' paper about how to modularize was in 1972, and by that time whether to modularize was already no longer a question. In fact, what you describe isn't even modular programming, it is structured programming, which Dijkstra himself strongly argued in favor of already in 1968 in his classic "Go To Considered Harmful" paper.
– Jörg W Mittag
3 hours ago
alright so perhaps I can understand 'separation of concerns' more as a mental focus exercise, and modularization as a way to encapsulate an aspect of code on paper. However I now see separation of concerns and modularization more as separate concepts.
– Dennis
3 hours ago
2
2
I'm pretty sure that by 1974, he just saw modular programming as an obvious given, and that's why he didn't explicitly discuss it in that paper. Parnas' paper about how to modularize was in 1972, and by that time whether to modularize was already no longer a question. In fact, what you describe isn't even modular programming, it is structured programming, which Dijkstra himself strongly argued in favor of already in 1968 in his classic "Go To Considered Harmful" paper.
– Jörg W Mittag
3 hours ago
I'm pretty sure that by 1974, he just saw modular programming as an obvious given, and that's why he didn't explicitly discuss it in that paper. Parnas' paper about how to modularize was in 1972, and by that time whether to modularize was already no longer a question. In fact, what you describe isn't even modular programming, it is structured programming, which Dijkstra himself strongly argued in favor of already in 1968 in his classic "Go To Considered Harmful" paper.
– Jörg W Mittag
3 hours ago
alright so perhaps I can understand 'separation of concerns' more as a mental focus exercise, and modularization as a way to encapsulate an aspect of code on paper. However I now see separation of concerns and modularization more as separate concepts.
– Dennis
3 hours ago
alright so perhaps I can understand 'separation of concerns' more as a mental focus exercise, and modularization as a way to encapsulate an aspect of code on paper. However I now see separation of concerns and modularization more as separate concepts.
– Dennis
3 hours ago
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
5
down vote
I would suggest that, whilst the paper is of historic interest, what Dijkstra meant by the term "separation of concerns" over 40 years ago is not particularly relevant today. Nowadays it is used extensively in reference to modulization.
There is a wealth of evidence that modulization is hugely beneficial and that those benefits far outweigh the "burdens" it places upon us. Whatever Dijkstra meant back then, doesn't change the fact that small chunks of code, each focused on just one thing, leads to code that is easier to write, read, understand, maintain and test.
answered 2 hours ago
David Arno
24.5k64682
3
I think it should be noted that much of modern thought on Separation of Concerns came from early papers that eventually spawned Aspect Oriented Programming from IBM. I think the initial papers (late 90s-early 2000s) are the biggest influence there. It's been a while and the web sites have all changed. Not sure if I can even find them again.
– Berin Loritsch
1 hour ago
add a comment |Â
up vote
3
down vote
Separation of concerns is an abstract way of thinking that consist in considering separately things that do not have to be related.
Modularisation (separating unrelated group of functions into modules), encapsulation (hiding internal details of the modules), and abstraction (separating the general from the specific, and the idea from its implementation) are all means to implement this way of thinking in the domain of software design.
answered 1 hour ago
Christophe
21.4k21956
add a comment |Â
up vote
2
down vote
I can give you a personal example of separation of concerns that I think is comparable to Dijkstra's concepts. When I analyze a particular subject matter in software I construct three views.
- First I consider the data. The data represents the logical predicates of the problem. Classes are constructed to abstract entities in the real world, with their attributes being the parameters of the abstraction. Associations between classes represent functional mappings between the class instances. There is no code involved in the thinking at this point and no notion of any processing. Just a static view of the logic involved in the subject matter.
- Second I consider the dynamics. Any class that has a non-trivial lifecycle is modeled as a finite state machine. This involves considerations of sequencing execution and synchronization. Again, no code just working out how things interact and sequence.
- Third I consider the processing. Here, the actual algorithmic work that must be done upon state transitions or in other synchronous operations.
In the end, one obtains a three faceted view of the subject matter which can then be formulated as code in whatever groupings are convenient for the code itself and its maintenance. The three facets are not just a mental exercise. I produce written descriptions of all facets. Why? Because if the subject matter is large enough, I cannot hold even one complete facet in short term memory. If the subject matter is small, almost any approach will work because you can hold it all in your head.
The idea of separation of concerns is to overcome the limitations of short term memory of humans. We simply can't carry everything in our heads at once, although computer programmers tend to be more capable than most other folks at the number of items they can manipulate in their short term memory. To be effective, separating concerns must systematically exclude one or more aspects of a problem in order to focus on some other particular aspect. Of course, excluding one aspect does not make it disappear from consideration. There must be a means to combine all aspects to achieve a solution. Experience shows that often the end result of separating and recombining yields a more understandable solution that a single giant leap where many things can get jumbled together. This is particularly the case when the size of the problem is larger.
answered 1 hour ago
andy mango
201113
1
Honestly, you should write "Dijkstra's idea of separation of concerns" at the beginning of the last paragraph, not "The idea ...", to make the distinction clear.
– Doc Brown
40 mins ago
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
I would suggest that, whilst the paper is of historic interest, what Dijkstra meant by the term "separation of concerns" over 40 years ago is not particularly relevant today. Nowadays it is used extensively in reference to modulization.
There is a wealth of evidence that modulization is hugely beneficial and that those benefits far outweigh the "burdens" it places upon us. Whatever Dijkstra meant back then, doesn't change the fact that small chunks of code, each focused on just one thing, leads to code that is easier to write, read, understand, maintain and test.
answered 2 hours ago
David Arno
24.5k64682
3
I think it should be noted that much of modern thought on Separation of Concerns came from early papers that eventually spawned Aspect Oriented Programming from IBM. I think the initial papers (late 90s-early 2000s) are the biggest influence there. It's been a while and the web sites have all changed. Not sure if I can even find them again.
– Berin Loritsch
1 hour ago
add a comment |Â
up vote
5
down vote
I would suggest that, whilst the paper is of historic interest, what Dijkstra meant by the term "separation of concerns" over 40 years ago is not particularly relevant today. Nowadays it is used extensively in reference to modulization.
There is a wealth of evidence that modulization is hugely beneficial and that those benefits far outweigh the "burdens" it places upon us. Whatever Dijkstra meant back then, doesn't change the fact that small chunks of code, each focused on just one thing, leads to code that is easier to write, read, understand, maintain and test.
answered 2 hours ago
David Arno
24.5k64682
3
I think it should be noted that much of modern thought on Separation of Concerns came from early papers that eventually spawned Aspect Oriented Programming from IBM. I think the initial papers (late 90s-early 2000s) are the biggest influence there. It's been a while and the web sites have all changed. Not sure if I can even find them again.
– Berin Loritsch
1 hour ago
add a comment |Â
up vote
5
down vote
up vote
5
down vote
I would suggest that, whilst the paper is of historic interest, what Dijkstra meant by the term "separation of concerns" over 40 years ago is not particularly relevant today. Nowadays it is used extensively in reference to modulization.
There is a wealth of evidence that modulization is hugely beneficial and that those benefits far outweigh the "burdens" it places upon us. Whatever Dijkstra meant back then, doesn't change the fact that small chunks of code, each focused on just one thing, leads to code that is easier to write, read, understand, maintain and test.
answered 2 hours ago
David Arno
24.5k64682
I would suggest that, whilst the paper is of historic interest, what Dijkstra meant by the term "separation of concerns" over 40 years ago is not particularly relevant today. Nowadays it is used extensively in reference to modulization.
There is a wealth of evidence that modulization is hugely beneficial and that those benefits far outweigh the "burdens" it places upon us. Whatever Dijkstra meant back then, doesn't change the fact that small chunks of code, each focused on just one thing, leads to code that is easier to write, read, understand, maintain and test.
answered 2 hours ago
David Arno
24.5k64682
answered 2 hours ago
David Arno
24.5k64682
answered 2 hours ago
David Arno
24.5k64682
answered 2 hours ago
David Arno
24.5k64682
24.5k64682
3
I think it should be noted that much of modern thought on Separation of Concerns came from early papers that eventually spawned Aspect Oriented Programming from IBM. I think the initial papers (late 90s-early 2000s) are the biggest influence there. It's been a while and the web sites have all changed. Not sure if I can even find them again.
– Berin Loritsch
1 hour ago
add a comment |Â
3
I think it should be noted that much of modern thought on Separation of Concerns came from early papers that eventually spawned Aspect Oriented Programming from IBM. I think the initial papers (late 90s-early 2000s) are the biggest influence there. It's been a while and the web sites have all changed. Not sure if I can even find them again.
– Berin Loritsch
1 hour ago
3
3
I think it should be noted that much of modern thought on Separation of Concerns came from early papers that eventually spawned Aspect Oriented Programming from IBM. I think the initial papers (late 90s-early 2000s) are the biggest influence there. It's been a while and the web sites have all changed. Not sure if I can even find them again.
– Berin Loritsch
1 hour ago
I think it should be noted that much of modern thought on Separation of Concerns came from early papers that eventually spawned Aspect Oriented Programming from IBM. I think the initial papers (late 90s-early 2000s) are the biggest influence there. It's been a while and the web sites have all changed. Not sure if I can even find them again.
– Berin Loritsch
1 hour ago
add a comment |Â
up vote
3
down vote
Separation of concerns is an abstract way of thinking that consist in considering separately things that do not have to be related.
Modularisation (separating unrelated group of functions into modules), encapsulation (hiding internal details of the modules), and abstraction (separating the general from the specific, and the idea from its implementation) are all means to implement this way of thinking in the domain of software design.
answered 1 hour ago
Christophe
21.4k21956
add a comment |Â
up vote
3
down vote
Separation of concerns is an abstract way of thinking that consist in considering separately things that do not have to be related.
Modularisation (separating unrelated group of functions into modules), encapsulation (hiding internal details of the modules), and abstraction (separating the general from the specific, and the idea from its implementation) are all means to implement this way of thinking in the domain of software design.
answered 1 hour ago
Christophe
21.4k21956
add a comment |Â
up vote
3
down vote
up vote
3
down vote
Separation of concerns is an abstract way of thinking that consist in considering separately things that do not have to be related.
Modularisation (separating unrelated group of functions into modules), encapsulation (hiding internal details of the modules), and abstraction (separating the general from the specific, and the idea from its implementation) are all means to implement this way of thinking in the domain of software design.
answered 1 hour ago
Christophe
21.4k21956
Separation of concerns is an abstract way of thinking that consist in considering separately things that do not have to be related.
Modularisation (separating unrelated group of functions into modules), encapsulation (hiding internal details of the modules), and abstraction (separating the general from the specific, and the idea from its implementation) are all means to implement this way of thinking in the domain of software design.
answered 1 hour ago
Christophe
21.4k21956
edited 1 hour ago
answered 1 hour ago
Christophe
21.4k21956
answered 1 hour ago
Christophe
21.4k21956
answered 1 hour ago
Christophe
21.4k21956
21.4k21956
add a comment |Â
add a comment |Â
up vote
2
down vote
I can give you a personal example of separation of concerns that I think is comparable to Dijkstra's concepts. When I analyze a particular subject matter in software I construct three views.
- First I consider the data. The data represents the logical predicates of the problem. Classes are constructed to abstract entities in the real world, with their attributes being the parameters of the abstraction. Associations between classes represent functional mappings between the class instances. There is no code involved in the thinking at this point and no notion of any processing. Just a static view of the logic involved in the subject matter.
- Second I consider the dynamics. Any class that has a non-trivial lifecycle is modeled as a finite state machine. This involves considerations of sequencing execution and synchronization. Again, no code just working out how things interact and sequence.
- Third I consider the processing. Here, the actual algorithmic work that must be done upon state transitions or in other synchronous operations.
In the end, one obtains a three faceted view of the subject matter which can then be formulated as code in whatever groupings are convenient for the code itself and its maintenance. The three facets are not just a mental exercise. I produce written descriptions of all facets. Why? Because if the subject matter is large enough, I cannot hold even one complete facet in short term memory. If the subject matter is small, almost any approach will work because you can hold it all in your head.
The idea of separation of concerns is to overcome the limitations of short term memory of humans. We simply can't carry everything in our heads at once, although computer programmers tend to be more capable than most other folks at the number of items they can manipulate in their short term memory. To be effective, separating concerns must systematically exclude one or more aspects of a problem in order to focus on some other particular aspect. Of course, excluding one aspect does not make it disappear from consideration. There must be a means to combine all aspects to achieve a solution. Experience shows that often the end result of separating and recombining yields a more understandable solution that a single giant leap where many things can get jumbled together. This is particularly the case when the size of the problem is larger.
answered 1 hour ago
andy mango
201113
1
Honestly, you should write "Dijkstra's idea of separation of concerns" at the beginning of the last paragraph, not "The idea ...", to make the distinction clear.
– Doc Brown
40 mins ago
add a comment |Â
up vote
2
down vote
I can give you a personal example of separation of concerns that I think is comparable to Dijkstra's concepts. When I analyze a particular subject matter in software I construct three views.
- First I consider the data. The data represents the logical predicates of the problem. Classes are constructed to abstract entities in the real world, with their attributes being the parameters of the abstraction. Associations between classes represent functional mappings between the class instances. There is no code involved in the thinking at this point and no notion of any processing. Just a static view of the logic involved in the subject matter.
- Second I consider the dynamics. Any class that has a non-trivial lifecycle is modeled as a finite state machine. This involves considerations of sequencing execution and synchronization. Again, no code just working out how things interact and sequence.
- Third I consider the processing. Here, the actual algorithmic work that must be done upon state transitions or in other synchronous operations.
In the end, one obtains a three faceted view of the subject matter which can then be formulated as code in whatever groupings are convenient for the code itself and its maintenance. The three facets are not just a mental exercise. I produce written descriptions of all facets. Why? Because if the subject matter is large enough, I cannot hold even one complete facet in short term memory. If the subject matter is small, almost any approach will work because you can hold it all in your head.
The idea of separation of concerns is to overcome the limitations of short term memory of humans. We simply can't carry everything in our heads at once, although computer programmers tend to be more capable than most other folks at the number of items they can manipulate in their short term memory. To be effective, separating concerns must systematically exclude one or more aspects of a problem in order to focus on some other particular aspect. Of course, excluding one aspect does not make it disappear from consideration. There must be a means to combine all aspects to achieve a solution. Experience shows that often the end result of separating and recombining yields a more understandable solution that a single giant leap where many things can get jumbled together. This is particularly the case when the size of the problem is larger.
answered 1 hour ago
andy mango
201113
1
Honestly, you should write "Dijkstra's idea of separation of concerns" at the beginning of the last paragraph, not "The idea ...", to make the distinction clear.
– Doc Brown
40 mins ago
add a comment |Â
up vote
2
down vote
up vote
2
down vote
I can give you a personal example of separation of concerns that I think is comparable to Dijkstra's concepts. When I analyze a particular subject matter in software I construct three views.
- First I consider the data. The data represents the logical predicates of the problem. Classes are constructed to abstract entities in the real world, with their attributes being the parameters of the abstraction. Associations between classes represent functional mappings between the class instances. There is no code involved in the thinking at this point and no notion of any processing. Just a static view of the logic involved in the subject matter.
- Second I consider the dynamics. Any class that has a non-trivial lifecycle is modeled as a finite state machine. This involves considerations of sequencing execution and synchronization. Again, no code just working out how things interact and sequence.
- Third I consider the processing. Here, the actual algorithmic work that must be done upon state transitions or in other synchronous operations.
In the end, one obtains a three faceted view of the subject matter which can then be formulated as code in whatever groupings are convenient for the code itself and its maintenance. The three facets are not just a mental exercise. I produce written descriptions of all facets. Why? Because if the subject matter is large enough, I cannot hold even one complete facet in short term memory. If the subject matter is small, almost any approach will work because you can hold it all in your head.
The idea of separation of concerns is to overcome the limitations of short term memory of humans. We simply can't carry everything in our heads at once, although computer programmers tend to be more capable than most other folks at the number of items they can manipulate in their short term memory. To be effective, separating concerns must systematically exclude one or more aspects of a problem in order to focus on some other particular aspect. Of course, excluding one aspect does not make it disappear from consideration. There must be a means to combine all aspects to achieve a solution. Experience shows that often the end result of separating and recombining yields a more understandable solution that a single giant leap where many things can get jumbled together. This is particularly the case when the size of the problem is larger.
answered 1 hour ago
andy mango
201113
I can give you a personal example of separation of concerns that I think is comparable to Dijkstra's concepts. When I analyze a particular subject matter in software I construct three views.
- First I consider the data. The data represents the logical predicates of the problem. Classes are constructed to abstract entities in the real world, with their attributes being the parameters of the abstraction. Associations between classes represent functional mappings between the class instances. There is no code involved in the thinking at this point and no notion of any processing. Just a static view of the logic involved in the subject matter.
- Second I consider the dynamics. Any class that has a non-trivial lifecycle is modeled as a finite state machine. This involves considerations of sequencing execution and synchronization. Again, no code just working out how things interact and sequence.
- Third I consider the processing. Here, the actual algorithmic work that must be done upon state transitions or in other synchronous operations.
In the end, one obtains a three faceted view of the subject matter which can then be formulated as code in whatever groupings are convenient for the code itself and its maintenance. The three facets are not just a mental exercise. I produce written descriptions of all facets. Why? Because if the subject matter is large enough, I cannot hold even one complete facet in short term memory. If the subject matter is small, almost any approach will work because you can hold it all in your head.
The idea of separation of concerns is to overcome the limitations of short term memory of humans. We simply can't carry everything in our heads at once, although computer programmers tend to be more capable than most other folks at the number of items they can manipulate in their short term memory. To be effective, separating concerns must systematically exclude one or more aspects of a problem in order to focus on some other particular aspect. Of course, excluding one aspect does not make it disappear from consideration. There must be a means to combine all aspects to achieve a solution. Experience shows that often the end result of separating and recombining yields a more understandable solution that a single giant leap where many things can get jumbled together. This is particularly the case when the size of the problem is larger.
answered 1 hour ago
andy mango
201113
answered 1 hour ago
andy mango
201113
answered 1 hour ago
andy mango
201113
answered 1 hour ago
andy mango
201113
201113
1
Honestly, you should write "Dijkstra's idea of separation of concerns" at the beginning of the last paragraph, not "The idea ...", to make the distinction clear.
– Doc Brown
40 mins ago
add a comment |Â
1
Honestly, you should write "Dijkstra's idea of separation of concerns" at the beginning of the last paragraph, not "The idea ...", to make the distinction clear.
– Doc Brown
40 mins ago
1
1
Honestly, you should write "Dijkstra's idea of separation of concerns" at the beginning of the last paragraph, not "The idea ...", to make the distinction clear.
– Doc Brown
40 mins ago
Honestly, you should write "Dijkstra's idea of separation of concerns" at the beginning of the last paragraph, not "The idea ...", to make the distinction clear.
– Doc Brown
40 mins ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f378615%2fdid-dijkstra-intend-for-code-modularization-when-he-wrote-about-separation-of-c%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
I'm pretty sure that by 1974, he just saw modular programming as an obvious given, and that's why he didn't explicitly discuss it in that paper. Parnas' paper about how to modularize was in 1972, and by that time whether to modularize was already no longer a question. In fact, what you describe isn't even modular programming, it is structured programming, which Dijkstra himself strongly argued in favor of already in 1968 in his classic "Go To Considered Harmful" paper.
– Jörg W Mittag
3 hours ago
alright so perhaps I can understand 'separation of concerns' more as a mental focus exercise, and modularization as a way to encapsulate an aspect of code on paper. However I now see separation of concerns and modularization more as separate concepts.
– Dennis
3 hours ago