You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we program, we have a problem at hand that we need to solve. For instance when we want to extract the names from data, there are aspects we don't discern as necessary. For example, the possible formats of names, that the regular expression we wrote doesn't capture all possible names.
These are aspects that we discern as relevant through debugging. Possibly debugging while coding. These aspects are probably necessary to point out in the literate source, for future readers. If it wasn't obvious for the programmer at their first attempt, it's probably necessary to point it out for readers as well.
These aspects that we capture like this might not be all the critical aspects though. What's critical for one programmer might not be critical for another.
What the reader is learning about might vary. But in most cases it's not about the programming language or programming in general, the reader is learning about the problem at hand, or the problem in combination with the particular programming language or libraries used.
We should have a chapter about variation theory and how that should influence how we write the (literate) code.
This should also motivate why computer engineers should learn variation theory or at least some extent of teaching and writing.
The text was updated successfully, but these errors were encountered: