Glen, I am not sure what the "why-trap" is. If you think me sometimes cagey, it's usually because I am trying to not to say more than I know, and when I am talking to computer folks about programming, I know so little that it probably sounds like I am talking with my hands over my mouth. I do think it's important for "civilians" to understand programmers' world better than we do, and that requires developing some sort of mediating language that does justice to civilians and experts alike.
Nick Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University http://home.earthlink.net/~nickthompson/naturaldesigns/ -----Original Message----- From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of glen Sent: Wednesday, July 18, 2018 4:30 PM To: The Friday Morning Applied Complexity Coffee Group <friam@redfish.com> Subject: Re: [FRIAM] What is an object? Nick, Marcus does a good job of avoiding your "why" trap. But he doesn't (usually) telegraph his (purposeful) rhetorical jitsu. 8^) I would posit that OOP isn't really *designed* so much as it is evolved. Sure, there are people afflicted with the Great Man Theory, thinking that OOP sprung from the head of <favorite person> fully formed. But the reality is probably more mungy than that. On July 18, 2018 10:23:17 AM PDT, Marcus Daniels <mar...@snoutfarm.com> wrote: >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 -- glen ============================================================ 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 ============================================================ 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
