[FRIAM] What is an object?

Thu Jul 19 09:26:39 EDT 2018

Thanks, Dave, for this history.  I have had it from you in pieces over the years.  It's wonderful to have it all in a chunk for study. 

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 Prof David West
Sent: Thursday, July 19, 2018 4:02 AM
To: friam at redfish.com
Subject: Re: [FRIAM] What is an object?

May I dissent?

It is CRITICAL to understand WHY a language was advanced, what it was INTENDED to do. Absent this knowledge you will almost certainly fail to realize the potential the language offers for different ways to think about problems and articulate (code) solutions.

ACM/SIGPLAN's series on the History of Programming Languages provides an excellent opportunity to understand what the 'inventor' (C++ was pretty much all Stroustrup, COBOL and Ada were committees, Smalltalk was a core team, ...) of the language intended and then examine body of practice using that language — and see hundreds of lost opportunities.

C++, for example, was created to "impose structural discipline on C programmers, without, in any way, diminishing the speed and power of C to articulate what was going on in the computer, how the computer operated." All the programmers who tried to use it as an object-oriented programming language were pretty much doomed to failure because the language offered them nothing to support that paradigm (as I said before, an abstract data type is NOT an object!).

The IDEA of Smalltalk derived from the IDEA of Simula; the philosophy and ideas of Englebart, Bush, Sutherland; the metaphor of cellular biology, and undoubtedly more. Alan Kay coalesced those influences and led the team that implemented the team that actually created the language at Xerox PARC.

The PURPOSE of Smalltalk (and SIMULA) was a language that would support 'conversations' with the computer (ala the Dynabook idea) and to 'simulate' the familiar world in such a way that interactions with the simulation maintained the "illusion" of interacting with the real world (or subset of immediate interest) in an ordinary way.

The 'test' of whether or not this purpose was realized: can't children, with not programming knowledge or experience, carry on this kind of conversation — can SMALL humans (childred) TALK with the computer.

The team that implemented the idea: Alan Kay, Adele Goldberg, Seymour Papert, and Dan Ingalls. The only hardcore programmer among them was Ingalls.

The 'research version' of Smalltalk (and SIMULA) yielded such great results that decisions were made to share with the world by releasing a commercial product - a "real" programming language. Necessaril, compromises had to be made in terms of what was in the language (Smalltalk, like Self, did not have Classes) and what a buyer/user of that language would expect to find there (control constructs like loops, nested-ifs, conditional branching) even if those additions "should not be used."

Smalltalk-80 was released as a commercial product. This had two quite negative effects: 1) it severely constrained the enhancement of the language itself because of the need for 'stability' and and compatibility with a growing body of 'legacy code'; and 2) it opened the door to using the language instead of using it as intended. (Kay and Ingalls rewrote Smalltalk from the ground up, changed the architecture, replaced graphics with morphs, and released it again as Squeak.)

The initial propagation of the language, establishing the first user community, was, like many innovations, effected by 'word of mouth' and mentoring. Most of those in this early community shared an understanding of WHY Smalltalk as well as HOW-TO Smalltalk.

Results generated by this community of early adopters were extraordinary — anecdotal (14 year old girl in middle school with no programming knowledge or experience, creating a functional equivalent of GenericCAD in 70 hours) and metric-based (1000 lines of C++ versus 100 lines of Smalltalk; 6 weeks to develop a Smalltalk application versus 6 months (usually much more) to develop the same application in C++, dramatically reduced cyclomatic compexity, etc. etc.)

These kinds of successes created a huge demand for Smalltalk programmers. The demand was met by programmers learning the language apart from the culture in which it was developed and within which early adopters used it. 

The started the evolution of a practice-of-programming-in-Smalltalk, absent all understanding of WHY, or INTENT, or PURPOSE. This larger community began using Smalltalk the same way they would use any other language.

One example: If you look at the code base from the first years of Smalltalk, express looping statements (DO-WHILE, DO-UNTIL) would be extremely rare. In the later code base they are rife - just as they would be in any procedural language like Pascal or COBOL. Nested ifs and conditional branching would show the same rarity,early and profligate use later.

Lacking an understanding of WHY meant failing to understand effective HOW — e.g. the power of the object idea was in the potential for alternative designs for modularity (what an object was supposed to do instead of how it was supposed to do it or what "data" it used) and architecture (distribution of responsibilities/functionality among objects).

davew

On Wed, Jul 18, 2018, at 3:12 PM, Nick Thompson wrote:
> 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
> 
> 
> ============================================================
> 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