20. Wherever there is modularity there is the potential for misunderstanding: Hiding information implies a need to check communication.
This is a really great point. Along the same vein: modularity has a cost too. A cost in terms of communication. The benefits of modularity should be weighed against this cost.
We're really good at talking about new patterns to increase modularity, in particular in the OOP tradition (always hide data, every data structure is its own little module with a public interface). We're very bad at talking about the costs associated with these.
"A Philosophy of Software Design" by John Ousterhout talks about the costs of introducing abstractions, with the implication that modules should be "narrow and deep".
The width is defined as the size of the interface (the cost) and the depth as the functionality that it buys you or maybe the complexity it hides (I'm recalling from memory, don't have the book at hand).
A file system that exposes the file interface (as in Unix) is given as a positive example. It has few functions and buys you, well, everything a file system offers.
Comments
The most productive thing I'll do all day:
```sh curl -s -L http://www.cs.yale.edu/homes/perlis-alan/quotes.html | tr "\n" " " | grep -o -e "[0-9]\+\.[^\<]*" | sed -e "s/^[0-9]\+\. //" | sort -R | head -n1 | cowsay ```
At my former job I had a Perlis bot that posted a random epigram every morning before standup in our slack.
It became a somewhat loved thing to have.
This is a really great point. Along the same vein: modularity has a cost too. A cost in terms of communication. The benefits of modularity should be weighed against this cost.
We're really good at talking about new patterns to increase modularity, in particular in the OOP tradition (always hide data, every data structure is its own little module with a public interface). We're very bad at talking about the costs associated with these.
"A Philosophy of Software Design" by John Ousterhout talks about the costs of introducing abstractions, with the implication that modules should be "narrow and deep".
The width is defined as the size of the interface (the cost) and the depth as the functionality that it buys you or maybe the complexity it hides (I'm recalling from memory, don't have the book at hand).
A file system that exposes the file interface (as in Unix) is given as a positive example. It has few functions and buys you, well, everything a file system offers.
Another collection of wisdom, this time from David Farber. https://www2.cs.arizona.edu/icon/oddsends/farber.htm
These days, Dave is in Japan. Co-Director, Cyber Civilization Research Center and Distinguished Professor, Keio University Tokyo Japan ------------------------------------------ ip: ip Permalink: https://ip.topicbox.com/groups/ip/T5d02d25c6d0cdd1c-Mccf10bb... Delivery options: https://ip.topicbox.com/groups/ip/subscription