Comments on: The Evolution Away from Modularity http://www.tdaxp.com/archive/2006/06/16/the-evolution-away-from-modularity.html High-minded, fanatically malthusian perspectives Thu, 29 Jul 2010 14:26:42 +0000 hourly 1 http://wordpress.org/?v=3.0 By: GL http://www.tdaxp.com/archive/2006/06/16/the-evolution-away-from-modularity.html/comment-page-1#comment-268241 GL Tue, 21 Apr 2009 19:20:12 +0000 http://www.tdaxp.com/archive/2006/06/16/the-evolution-away-from-modularity.html#comment-268241 No offense but Bullers "not enough genes" argument relies on a "one gene = one trait" view that is just plain wrong. See Barrett & Kurzban (2006), page 640. Also it's Wason selection task, not Watson ;) (named after Peter Wason). Other than that, great post. No offense but Bullers “not enough genes” argument relies on a “one gene = one trait” view that is just plain wrong. See Barrett & Kurzban (2006), page 640.

Also it’s Wason selection task, not Watson ;) (named after Peter Wason).

Other than that, great post.

]]> By: mark safranski http://www.tdaxp.com/archive/2006/06/16/the-evolution-away-from-modularity.html/comment-page-1#comment-8310 mark safranski Wed, 30 Nov -0001 00:00:00 +0000 http://www.tdaxp.com/archive/2006/06/16/the-evolution-away-from-modularity.html#comment-8310 <p>Great expansion and counterpoint. Not sure if modularity is always antagonistic to holistic conceptions because modules can and should act in synergy, at least at certain times but at other times, it probably is.<br /> <br /> Have to link to this....</p> Great expansion and counterpoint. Not sure if modularity is always antagonistic to holistic conceptions because modules can and should act in synergy, at least at certain times but at other times, it probably is.

Have to link to this….

]]> By: Dan tdaxp http://www.tdaxp.com/archive/2006/06/16/the-evolution-away-from-modularity.html/comment-page-1#comment-8311 Dan tdaxp Wed, 30 Nov -0001 00:00:00 +0000 http://www.tdaxp.com/archive/2006/06/16/the-evolution-away-from-modularity.html#comment-8311 <p>Mark,<br /> <br /> Good point about the synergy. I was delighted by how this chapter tied into recent blog conversations [1], but what is actually meant by modularity is not clear to me.<br /> <br /> In the above notes I mentioned how Buller and Hardcastle's data-and-process division wasn't clean, because in programming an array is data that looks like a process. You can do the same thing with the authors' insistence that modules have access to direct information. For example, what to make of<br /> <br /> a PERL script that (depending on command line arguments)<br /> involves a MACRO language that (depending on flags)<br /> compiles C++ code that (depending on debugging code)<br /> builds an ASP presentation layer that (depending on browser settings)<br /> invokes an SQL command that (depending on the database's configuration file)<br /> is converted into DATABASE ACCESS LOGIC (depending on current performance load)<br /> that is outputed as HTML that (depending on a user's current time)<br /> involves an SOAP request that (depending on Internet traffic)<br /> is returned in XML (which in turn depends on another computer's settings -- a whole new black box there) that<br /> is processed by JAVASCRIPT and shows a user either his waiting emails or the nightly TV schedule<br /> <br /> Here you have a cascade of modules, some clearly "deeper in" that other, all of which takes some input and much of which relies on real-time or near-real-time settings. Would this be not massively modular in Buller's and Hardscaste's eyes because some require information from an internal clock, some from settings that were recently set, others from settings that were set further back, some from social interactions? <br /> <br /> If anything, this chapter (and your comment) helps clarify that definitions are important. Oddly the authors have attacked others for definitions so vague as to be meaningless. But in a chapter on "modularity," they seem to do the same thing.<br /> <br /> [1] <a href="http://www.tdaxp.com/archive/2006/06/14/dashboard-confessional.html" target="_blank" rel="nofollow">http://www.tdaxp.com/archive/2006/06/14/dashboard-confessional.html</a></p> Mark,

Good point about the synergy. I was delighted by how this chapter tied into recent blog conversations [1], but what is actually meant by modularity is not clear to me.

In the above notes I mentioned how Buller and Hardcastle’s data-and-process division wasn’t clean, because in programming an array is data that looks like a process. You can do the same thing with the authors’ insistence that modules have access to direct information. For example, what to make of

a PERL script that (depending on command line arguments)
involves a MACRO language that (depending on flags)
compiles C++ code that (depending on debugging code)
builds an ASP presentation layer that (depending on browser settings)
invokes an SQL command that (depending on the database’s configuration file)
is converted into DATABASE ACCESS LOGIC (depending on current performance load)
that is outputed as HTML that (depending on a user’s current time)
involves an SOAP request that (depending on Internet traffic)
is returned in XML (which in turn depends on another computer’s settings — a whole new black box there) that
is processed by JAVASCRIPT and shows a user either his waiting emails or the nightly TV schedule

Here you have a cascade of modules, some clearly “deeper in” that other, all of which takes some input and much of which relies on real-time or near-real-time settings. Would this be not massively modular in Buller’s and Hardscaste’s eyes because some require information from an internal clock, some from settings that were recently set, others from settings that were set further back, some from social interactions?

If anything, this chapter (and your comment) helps clarify that definitions are important. Oddly the authors have attacked others for definitions so vague as to be meaningless. But in a chapter on “modularity,” they seem to do the same thing.

[1] http://www.tdaxp.com/archive/2006/06/14/dashboard-confessional.html

]]>