I'll share my findings when they fall into some sort of shape.
Meanwhile, here's a quote I found nice (if slightly poetic). Since my interest is focused more on learning by programming than learning to program, I stroke a cord:
"The first idea is that making a big computer program is building a larger process out of smaller ones."
"This must be the secret of those magical experiences I had, first with those construction sets and, later, with languages like LOGO. There's something "universal" about the ways that big things don't depend so much on what's inside their little parts. What matters is more how the parts affect each other – and less about what they are, themselves. That's why it doesn't matter much if money's made of paper or of gold, or houses out of boards or bricks. Similarly, it probably won't matter much if aliens from outer space had golden bones instead of ones of stones, like ours. People are missing something important, who don't appreciate how simple things can grow into entire worlds. They find it hard to understand Science, because they find it hard to see how all the different things we know could be made of just a few kinds of atoms. They find it hard to understand Evolution because they find it hard to see how different things like birds and bees and bears could come from boring, lifeless chemicals -- by testing trillions of procedures. The trick, of course, is doing it by many steps, each using procedures which have been debugged already, in the same way, but on smaller scales."
Marvin Minsky, Introduction to LogoWorks, http://web.media.mit.edu/~minsky/papers/Logoworks.html
- Yishay
Michael Toomim wrote:
Yishay Mor wrote:
I am looking for references, both evangelizing modular design and questioning it.
Here are a few fairly obvious starting points:
This cognitive dimensions tutorial has a section on abstraction that talks about its costs and when it might not be appropriate (like in exploratory design):
http://www.cl.cam.ac.uk/users/afb21/CognitiveDimensions/CDtutorial.pdf
This attention investment paper makes some similar points, and discusses when programmers percieve abstraction to be worth the effort:
http://www.cl.cam.ac.uk/users/afb21/publications/PPIG99.html
The XP community uses "once and only once" as a battle cry: http://c2.com/cgi/wiki?OnceAndOnlyOnce
Fowler says that "Number one in the stink parade [of bad software smells] is duplicated code" in the book _Refactorings_, and talks about many ways to make code more modular. He also says, "3 strikes [of duplicating a piece of code] and refactor", implying that you don't want to modularize duplicated code too early.
Duplicated code isn't quite the antithesis to modularity (like it is to abstraction) but it is related. I think modularity also refers to having small units (look up "law of demeter" and see the attached .bib file), and having clean, well-defined interfaces (there's some reuse literature on what makes for a good "module") that are stable--- which I tend to think of as meaning "hard to break", "verbosely specified", or otherwise "viscous". The cognitive dimensions tutorial talks about some of the costs and benefits that come from notations with viscous module interface definitions, which is thus also a way of looking at the costs and benefits of modularity... I think.
This is a topic that's close to my heart. Could you let me know of your results? Have fun! :)
Michael
------------------------------------------------------------------------
% This is a set of selected references to the Law of Demeter.
@string{sigplan = "SIGPLAN Notices"} @string{oopsla = "Object-Oriented Programming Systems, Languages and Applications Conference, {\em in} Special Issue of SIGPLAN Notices"} @string{ieee-software = "IEEE Software"} @string{csm = "Conference on Software Maintenance"}
@INPROCEEDINGS{LHLR:law-paper, AUTHOR = "Karl J. Lieberherr and Ian Holland and Arthur J. Riel", TITLE = "Object-oriented programming: An objective sense of style", BOOKTITLE = oopsla, MONTH = "September", ADDRESS = "San Diego, CA", YEAR = "1988", VOL = 23, NUMBER = 11, PAGES = "323-334", NOTE = "A short version of this paper appears in {\em IEEE Computer Magazine}, June 1988, Open Channel section, pages 78-79." }
@ARTICLE{karl-ian:soft1, AUTHOR = "Karl J. Lieberherr and Ian Holland", TITLE = "Assuring Good Style for Object-Oriented Programs", JOURNAL = ieee-software, YEAR = "1989", MONTH = "September", PAGES = "38-48" }
@INPROCEEDINGS{ian-karl:preventive, AUTHOR = "Karl J. Lieberherr and Ian Holland", TITLE = "Tools for preventive software maintenance", BOOKTITLE = csm, YEAR = 1989, PUBLISHER = ieee, PAGES = "2-13", ADDRESS = "Miami, Florida, October 16-19" }
% Chapter 8 of the book (see below) % discusses the Law of Demeter and its relationship % to the small methods problem of OOP. It shows how the software % can be written at a higher level of abstraction to reduce the small % methods problem and to generate LoD conformant code for the traversals.
@BOOK{karl:demeter, AUTHOR = "Karl J. Lieberherr", TITLE = "Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns", PUBLISHER = "PWS Publishing Company, Boston", YEAR = "1996", NOTE = "ISBN 0-534-94602-X" }
@ARTICLE{sakkinen:law-88, AUTHOR = "Markku Sakkinen", TITLE = "Comments on the {Law of Demeter} and {C++}", JOURNAL = sigplan , YEAR = 1988, MONTH = "December", PAGES = "38-44", VOLUME = "23" , NUMBER = "12" }
@INPROCEEDINGS{minsky:law-96, AUTHOR = "Naftaly Minsky and Partha Pal", TITLE = "Imposing the Law of Demeter and Its Variations", BOOKTITLE = "TOOLS Conference" , YEAR = 1996, MONTH = "August", PAGES = "", ADDRESS = "Santa Barbara, CA" }
-- ********************************************************************** Yishay Mor http://ioewebserver.ioe.ac.uk/ioe/cms/get.asp?cid=4381&4381_0=7303 [EMAIL PROTECTED] Ph +44(0)20 7612 6963 F +44(0)20 7612 6964 AIM,Yahoo: yishaym; Jabber: [EMAIL PROTECTED]; ICQ: 179772099 If this helped you, please take the time to rate the value of this post: http://svcs.affero.net/rm.php?r=yishaym ********************************************************************** celebrating 100 years of excellence in education www.ioe.ac.uk/centenary
---------------------------------------------------------------------- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
