For example, if all you have is an interface to a sort routine, and that sort happens to be a bubble sort -- an O(n^2) cost – you might avoid sorting if you had a lot of items to track, if only because you observed the sort routine took a long time. Or if your processor only could do scalar math, you might not see the practical benefit in using vector or matrix notation in a program. These are the types of interfaces a vendor would provide a customer, and their properties can greatly influence how/if the customer approaches a problem. Often it is not possible to look under the hood to see how they work.
The point is that out of laziness or selfishness, artifacts are formed in ways that may not be well-suited to what would be optimal for a given problem, and that inertia that changes how new components are built using them. A simple organizational approach like OOP can’t guide all kinds of technical decisions. At best, it can compartmentalize and factor the compexlity, which unfortunately can mean sweeping deep algorithmic issues under the rug. From: Friam <friam-boun...@redfish.com> on behalf of Nick Thompson <nickthomp...@earthlink.net> Reply-To: The Friday Morning Applied Complexity Coffee Group <friam@redfish.com> Date: Wednesday, July 18, 2018 at 10:53 AM To: 'The Friday Morning Applied Complexity Coffee Group' <friam@redfish.com> Subject: Re: [FRIAM] What is an object? Marcus, Am I correct that this is what “oop” is designed to avoid? “This” being what you describe below? Nick Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University http://home.earthlink.net/~nickthompson/naturaldesigns/ From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of Marcus Daniels Sent: Wednesday, July 18, 2018 12:18 PM To: The Friday Morning Applied Complexity Coffee Group <friam@redfish.com> Subject: Re: [FRIAM] What is an object? Nick writes: “And like any modular system (DNA comes to mind), modularity is a great spur to creativity, leaving programmers free to work on better modules knowing that as long as the version of the “object“ they design (which, say, can work in a greater variety of heat conditions or uses less power, etc.) is the “same” box, then their work is a contribution to the whole.” In the real world of software, there are many frozen accidents. The genesis of an initial building block leads to another being designed in a certain way, which brings with another set of idiosyncrasies, and so on. After decades of this people start to believe that things must – in principle and in practice -- be a certain way. Software layering can be an obstacle to innovation once basic assumptions are called into question; it is easy to get stuck in local fitness maxima and a particular foundation. Marcus From: Friam <friam-boun...@redfish.com<mailto:friam-boun...@redfish.com>> on behalf of Nick Thompson <nickthomp...@earthlink.net<mailto:nickthomp...@earthlink.net>> Reply-To: The Friday Morning Applied Complexity Coffee Group <friam@redfish.com<mailto:friam@redfish.com>> Date: Wednesday, July 18, 2018 at 9:53 AM To: 'The Friday Morning Applied Complexity Coffee Group' <friam@redfish.com<mailto:friam@redfish.com>> Subject: Re: [FRIAM] What is an object? And like any modular system (DNA comes to mind), modularity is a great spur to creativity, leaving programmers free to work on better modules knowing that as long as the version of the “object“ they design (which, say, can work in a greater variety of heat conditions or uses less power, etc.) is the “same” box, then their work is a contribution to the whole.
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove
