Beautifully stated, Dave. Thanks. TJ On Wed, Jul 18, 2018, 12:00 AM Prof David West <profw...@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 >
============================================================ 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
