Hope this helps https://xkcd.com/2021/
On Wed, Jul 18, 2018 at 9:53 AM Nick Thompson <nickthomp...@earthlink.net> wrote: > 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/ > > > > *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/ > > > > ============================================================ > > 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
