[FRIAM] What is an object?

[Nick Thompson]

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-bounces at redfish.com] On Behalf Of glen
Sent: Wednesday, July 18, 2018 4:30 PM
To: The Friday Morning Applied Complexity Coffee Group <friam at 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 <marcus at 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-bounces at redfish.com> on behalf of Nick Thompson 
><nickthompson at earthlink.net>
>Reply-To: The Friday Morning Applied Complexity Coffee Group 
><friam at redfish.com>
>Date: Wednesday, July 18, 2018 at 10:53 AM
>To: 'The Friday Morning Applied Complexity Coffee Group'
><friam at 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