<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">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.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Friam <friam-bounces@redfish.com> on behalf of Nick Thompson <nickthompson@earthlink.net><br>
<b>Reply-To: </b>The Friday Morning Applied Complexity Coffee Group <friam@redfish.com><br>
<b>Date: </b>Wednesday, July 18, 2018 at 10:53 AM<br>
<b>To: </b>'The Friday Morning Applied Complexity Coffee Group' <friam@redfish.com><br>
<b>Subject: </b>Re: [FRIAM] What is an object?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D">Marcus, </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Am I correct that this is what “oop” is designed to avoid?
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">“This” being what you describe below?
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Nick </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="color:#1F497D">Nicholas S. Thompson</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Emeritus Professor of Psychology and Biology</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Clark University</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><a href="http://home.earthlink.net/~nickthompson/naturaldesigns/">http://home.earthlink.net/~nickthompson/naturaldesigns/</a></span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Friam [mailto:friam-bounces@redfish.com] <b>On Behalf Of
</b>Marcus Daniels<br>
<b>Sent:</b> Wednesday, July 18, 2018 12:18 PM<br>
<b>To:</b> The Friday Morning Applied Complexity Coffee Group <friam@redfish.com><br>
<b>Subject:</b> Re: [FRIAM] What is an object?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Nick writes:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">“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.”</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Marcus<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Friam <<a href="mailto:friam-bounces@redfish.com">friam-bounces@redfish.com</a>> on behalf of Nick Thompson <<a href="mailto:nickthompson@earthlink.net">nickthompson@earthlink.net</a>><br>
<b>Reply-To: </b>The Friday Morning Applied Complexity Coffee Group <<a href="mailto:friam@redfish.com">friam@redfish.com</a>><br>
<b>Date: </b>Wednesday, July 18, 2018 at 9:53 AM<br>
<b>To: </b>'The Friday Morning Applied Complexity Coffee Group' <<a href="mailto:friam@redfish.com">friam@redfish.com</a>><br>
<b>Subject: </b>Re: [FRIAM] What is an object?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D">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.</span><o:p></o:p></p>
</div>
</body>
</html>