[FRIAM] What is an object?

[Tom Johnson]

Beautifully stated, Dave. Thanks.
TJ

On Wed, Jul 18, 2018, 12:00 AM Prof David West <profwest at fastmail.fm> wrote:

> Hi Nick,
>
> An object is a specific way to define and design a module and a module is
> a tool for segmenting, modularizing, the source code (what the programmer
> actually writes, not what the machine executes) for a program. To parse
> this assertion - and then to explain how and why object modularization is
> different - a quick aside to discuss a program is in order.
>
> I use 'program' to mean the source code - the lines of COBOL, java, C++,
> or Smalltalk that the programmer writes.
>
> I am sure you have seen BASIC programs. The source code consists of a
> list, each entry on that list having a sequence number and a BASIC
> statement. The computer will execute that program one line at a time in
> sequence: the statement on line 1 then line 2 ... Some of the statements,
> say the one on line 20 wont tell the computer to do something, instead they
> tell the computer to GOTO some other line number and resume executing
> instructions. Several different types of control structures are available.
> It takes little imagination to realize the larger the program the greater
> the difficulty in understanding what the computer might be doing at any
> specific time - especially if you also, simultaneously, need to track the
> values of numerous variables to see which branches are active.
>
> Hence the desire for modularization - packaging blocks of code lines into
> identifiable units - to simplify the process of reading a program and the
> mental modeling of what the program would be doing at any phase of
> execution.
>
> Now add Dikstra's famous definition, "a program is algorithms plus data
> structures."
>
> The first criteria for defining a module involved grouping lines of code
> that were related by prodecure, (essentially all lines participating in the
> same algorithm) - hence procedural programming with four kinds of modules:
> control, afferent, transform, and efferent.
>
> For various reasons, procedural modularization was unsatisfactory and,
> noticing that data structures were more stable over longer periods of time,
> data oriented modularization became the norm. You defined an entity as a
> data structure with members called attributes and aggregated all the
> procedures that operated on that specific data into a module.
>
> A DOS utility is probably written in C or Assembler, neither of which
> afford much opportunity for modularization, and is small enough that it
> does not need to be broken up.
>
> A tool in Matlab is likely a large program and if you could see the source
> code you would see modularization, probably more procedural in nature than
> data oriented.
>
> Note that both approaches to defining modules are focused on the program
> itself and how it can be broken up and the pieces related to each other.
> The same thing is true of "functional programming," i. e. the focus of
> design is inward towards the computer.
>
> Then came 'objects'.
>
> First critical difference: an object is not a way to modularize the
> program, it is a means for modularizing the World, the problem space.
>
> Second critical difference: one object is differentiated from another
> solely on the basis of behavior - what it does, what contribution it makes
> to the overall system, what services it provides to other objects.
>
> These two characteristics of objects are why Harman borrows the term for
> his Object-Oriented Ontology.
>
> The term Object-oriented programming was coined by Alan Kay and the
> metaphor he used to communicate the idea behind the term was was a
> biological cell consisting of an encapsulation boundary, inside of which
> was all the complexity that allowed the cell to do what it did, and outside
> of which was a protocol that allowed other cells to communicate with and
> request services from the cell.
>
> Unfortunately, very, very, few in the programming community "got the memo"
> and understood what an object was supposed to be, or how it could be
> implemented in a programming language. So, it is extremely rare to find any
> code, even in Smalltalk, but definitely in Java or C++ that even remotely
> resembles the object idea. Alan Kay maintains, to this day, that the object
> revolution has yet to happen.
>
> BTW all modules, and all executing programs for that matter, are intended
> to be "black boxes" - you have no idea, and do not care, what is inside of
> the box, only what outputs the box will provide you in exchange for what
> inputs.
>
> Long winded, and I hope not remedial, answer.
>
> davew
>
>
>
> On Tue, Jul 17, 2018, at 8:06 PM, Nick Thompson wrote:
>
> Dave, and anybody else who wants to play.
>
>
>
> I have always been puzzled by the question of how one distinguishes an
> object in object programming from a utility in DOS or a tool in Matlab.  Or
> any mathematical function, for that matter.  You give it what it needs, and
> it gives you what it’s supposed to, and you don’t give a damn how it works.
>
>
>
> Please don’t yell at me.
>
>
>
> Nick
>
>
>
> Nicholas S. Thompson
>
> Emeritus Professor of Psychology and Biology
>
> Clark University
>
> http://home.earthlink.net/~nickthompson/naturaldesigns/
>
>
> ============================================================
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://redfish.com/pipermail/friam_redfish.com/attachments/20180718/f3d48839/attachment.html>