David, and all,
I am overwhelmed (of course) by the diversity and complexity of the answers. I had expected at most a few answers, highly similar to one another, of the form, “Nick you idiot….,” followed at most by a couple of sentences. It seems that I am missing some context that would make the answers seem both more similar and straightforward. Allow me to illustrate my confusion with a story, bearing in mind that my confusion has absolutely no value except in so far as it might provide an occasion for Wizards of Your Dark Art to come to a consensus amongst yourselves about how to explain this stuff to us (as Owen so unforgettably puts it) citizens. When I was teaching at Swarthmore in the Sixties there was a Shop Guy who could design and build ANYTHING. I asked him to build two model “rats” to illustrate [what later became known as] Supervenience to bio students. The “rats” were just plywood cutouts of rats, exactly the same on the surface with, two lights for eyes and three switches. The job of the student was to use the behavior of the rats (how the lights related to the switches) to figure out the design of the two rats. Only when they had committed themselves to a “model” of the rats “insides” were they allowed to look inside and see how they were actually put together. They all concluded that the rats were the same, but of course my rat-maker had used different components and circuitry to arrive at the same behavior. (I think one was straight logic and the other involved stepping switches, but don’t hold me to that. ) The rats were thus doubly modular; they were made of modules, but, more important to me at the time, they were modules themselves for the purposes of demonstrating “rat” behavior. OK. So the rats’ behavior supervened upon their circuitry. In other words, there’s more than one way to skin a … rat. If I wanted to demonstrate “rat behavior”, it made no difference to me which of his two rats I took off the shelf. This was intended to demonstrate to the student that brain models lived in the behavior of organisms and that just because somebody said something about neurons and synapses didn’t necessarily mean they knew anything about how the brain actually accomplished behavior. But that issue is for another day. Here’s another story. Years ago my 1970’s era Troy Bilt tiller began to fail and I took it to a Guy. The Guy said, yes I can rebuild your engine, pretty much like new. It will cost you around $400. OR, he said, I can bolt a new Briggs and Stratton engine on there for 150 dollars. So, of course, I went for the new engine. When I got my tiller back, it worked beautifully, but it looked weird. The engine was a funny shape, the color was all wrong, but it had all the connectors it needed, it responded to all the levers, and it did the job. Evidently, tiller functioning supervenes upon engine construction. Now this is how I was starting to think about “objects” in programming. They were, in effect, black boxes, with stress laid on the intersubstitutability of different fulfillments of the box. And like any modular system (DNA comes to mind), modularity is a great spur to creativity, leaving programmers free to work on better modules knowing that as long as the version of the “object“ they design (which, say, can work in a greater variety of heat conditions or uses less power, etc.) is the “same” box, then their work is a contribution to the whole. This is how I understood DOS utililties and Matlab tools. I guess, in short, I was thinking of objects as functionally defined. This how I created and used macros in Word. Some of your responses seemed to confirm my intuition; others seemed to be totally different. But there seemed to be a consensus among you, leaving me to believe that I still don’t understand the context in which the term, “object”, is used that carves it out from the rest of the world for you Wizards. Thanks for your intricate and patient replies. Nick Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University <http://home.earthlink.net/~nickthompson/naturaldesigns/> http://home.earthlink.net/~nickthompson/naturaldesigns/ From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of Prof David West Sent: Wednesday, July 18, 2018 2:01 AM To: friam@redfish.com Subject: Re: [FRIAM] What is an object? 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/> 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> http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM-COMIC <http://friam-comic.blogspot.com/> 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
