What is an object?
Locked
 
|
Eric,
The tomato plants are seven feet tall. The end justifies the means. Nick Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University http://home.earthlink.net/~nickthompson/naturaldesigns/ -----Original Message----- From: Friam [mailto:[hidden email]] On Behalf Of Eric Smith Sent: Wednesday, July 18, 2018 12:17 PM To: The Friday Morning Applied Complexity Coffee Group <[hidden email]> Subject: Re: [FRIAM] What is an object? Nick, how could you! (about to get myself in trouble again for thinking I remember something that is probably wrong) > 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. I thought Troy Built tillers all came with Tecumseh engines, those big, slow, torquey things that I never saw on anything else. Briggs and Stratton were for lawnmowers. That almost seems as bad as (I am told) the generational shift when International Harvester began putting _truck engines_ in their tractors, a kind of betrayal that gets my farmer colleagues all red and hyperventilated. They say that was the end of the brand. I know that does not contribute to this thread. Eric ============================================================ 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 |
|
|
In reply to this post by Marcus G. Daniels
Marcus, Am I correct that this is what “oop” is designed to avoid? “This” being what you describe below? Nick Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University From: Friam [mailto:[hidden email]] On Behalf Of Marcus Daniels Nick writes: “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.” In the real world of software, there are many frozen accidents. The genesis of an initial building block leads to another being designed in a certain way, which brings with another set of idiosyncrasies, and so on. After decades of this people start to believe that things must – in principle and in practice -- be a certain way. Software layering can be an obstacle to innovation once basic assumptions are called into question; it is easy to get stuck in local fitness maxima and a particular foundation. Marcus From: Friam <[hidden email]> on behalf of Nick Thompson <[hidden email]> 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. ============================================================ 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 |
|
|
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 <[hidden email]> on behalf of Nick Thompson <[hidden email]> Marcus, Am I correct that this is what “oop” is designed to avoid?
“This” being what you describe below?
Nick Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University From: Friam [mailto:[hidden email]] On Behalf Of
Marcus Daniels Nick writes: “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.” In the real world of software, there are many frozen accidents. The genesis of an initial building block leads to another being designed in a certain way, which brings with another set of idiosyncrasies, and so on. After decades of
this people start to believe that things must – in principle and in practice -- be a certain way. Software layering can be an obstacle to innovation once basic assumptions are called into question; it is easy to get stuck in local fitness maxima and a particular
foundation. Marcus From: Friam <[hidden email]> on behalf of Nick Thompson <[hidden email]> 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. ============================================================ 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 |
|
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 <[hidden email]> 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 <[hidden email]> on behalf of Nick Thompson ><[hidden email]> >Reply-To: The Friday Morning Applied Complexity Coffee Group ><[hidden email]> >Date: Wednesday, July 18, 2018 at 10:53 AM >To: 'The Friday Morning Applied Complexity Coffee Group' ><[hidden email]> >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
uǝʃƃ ⊥ glen
|
|
|
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:[hidden email]] On Behalf Of glen Sent: Wednesday, July 18, 2018 4:30 PM To: The Friday Morning Applied Complexity Coffee Group <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> on behalf of Nick Thompson ><[hidden email]> >Reply-To: The Friday Morning Applied Complexity Coffee Group ><[hidden email]> >Date: Wednesday, July 18, 2018 at 10:53 AM >To: 'The Friday Morning Applied Complexity Coffee Group' ><[hidden email]> >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 |
|
|
Sorry, my reference to the "why trap" refers to teleology and the (apparent) success of science after it began focusing on "what" not "why". As a pragmatist, I ass/u/me/d you'd understand that. Mea culpa.
It's *literally* irrelevant what OOP was designed to do. What matters is what it does/is. On 07/18/2018 02:12 PM, Nick Thompson wrote: > 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. -- ☣ uǝlƃ ============================================================ 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
uǝʃƃ ⊥ glen
|
|
|
Nick -
Another answer to your question, and those raised by the other responses to yours is to another question... rather than literally about what OO Programmers/Designers mean by "Object", but what features are most useful to someone who *doesn't* write software or design systems. It is worth noting that OO programming/design was not coined to create a better way of thinking about problems or designing systems necessarily, but rather to make up for the weaknesses in existing programming languages which made it awkward to think about problems (and systems designed to resolve them), compared to existing natural language understandings of the problem. In that sense *you* already thing in *Objects* not dissimilar to the way OO programming was crafted to allow programmers to formally specify them and their interactions. To start with, an *Object* is, in everyday vernacular a "thing", a physical (or maybe not, but often very physical) thing you can see, touch, maybe even hear and smell... and for the purposes of this description, *interact with*. Your kitchen toaster, your cat, the chair you are sitting in, your house, are all pretty good examples of "an Object". Key elements in OO thinking include Modularity, Composability, Encapsulation, Abstraction and Inheritance. Modularity is fairly obvious perhaps... you interact (usually) with your *toaster*, *cat*, *chair*, *house*, not the molecules (or usually even subcomponents) that they consist of (in some sense). Modularity and Composability is useful when you "set up a kitchen" with a collection of cooking utensils, kitchen appliances, eating utensils, etc... and even moreso if you have one of those multi-function devices that can be a blender, a slicer, a dicer, a ricer, julienner, a breadmaker, etc. Encapsulation is important because you want to deal with a toaster via it's declared (and apt/obvious/simple) interfaces such as the power cord you plug into a (modular) wall outlet, the slots in the top where bread goes in and toast comes out, the dial which sets the "brownness" and maybe the lever that you push down to initiate "toasting" and maybe the bell that goes off when the toast is ready. You don't want to care about the myriad details of wiring that leads to heating elements and the springs and ratchets and levers and thermocouple that leads to your toast lowering, cooking and popping up again... Abstraction and Inheritance are a little more "abstract" but not unfamiliar. Your toaster is an *instance* of the (mechanical design) class "toaster"... the former being something you can pick up, touch, plug into the wall, put bread in and take toast out of... the latter you can maybe see diagrams of on paper and discuss in abstract ways, but can never actually touch or more importantly, use. A toaster (your kind) is an instance of a subclass of a more abstract class called a "Kitchen Appliance" and maybe a bit of "An Electronic Gadget"... and probably even of a more abstract class like "Oster" or "Black and Decker". There is no archetypical "Kitchen Appliance" nor "Electronic Gadget" nor even "Oster" (though I think there is a multi-function kitchen appliance-gadget called an Osterizer that is a modular mashup of several abstract types of kitchen gadget" Your toaster, your cat, your chair, your house, are all *instances* of *classes* which *inherit* properties from *superclasses*... A toaster is an electromechanical device, a kitchen appliance, an electronic gadget (esp. if it has a digital interface, etc.). A Cat is a Felidae, a Domestic Animal, a House Pet, a Friend, etc. and *inherits* properties from *all* of those abstract classes. A chair is Furniture with Household or Office style/utility/??? features, and is conventionally *composed of* a Seat, 4 Legs, a Back. Three legged stools, kneeling chairs, sitting balls, all break some or all of the above... What you said about your Troybuilt and the B&S engine replacing the Tecumseh (trusting Eric here) describes interfaces, abstraction and modularity... the fact that the B&S engine *could* be strapped up to the rest of the Tiller is a testimony to relatively well conceived *interfaces* (or a very clever mechanic)... The fact that "an engine is an engine is an engine" is the Abstraction, though Eric's point that the Tecumseh design was notoriously torque-y and a *tiller* application would seem to demand/utilize more torque than a lawnmowing application... you either didn't stress it past it's operating modes (all those times the tiller bogs down and the engine stalls?) or the design had a good torque-converter in it to make up for the less torque=y engine. What you said about the tomato plants being "seven feet tall" I take to be (mostly) hyperbole for illustrative purposes... I'm guessing they are more like 4-5' tall, and I suspect you can attribute much of that tall growth to the Miracle Grow you applied liberally along the way... though if your soil is particularly difficult, a good deep *till* might have made some of that difference. I think it would be interesting to see how different OO designers decomposed the system of systems involved in your achieving a meta-goal like 7' tall tomato plants (but are they bearing, and is the fruit equally beautiful, delicious and nutritious?) Carry on, - Steve ============================================================ 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 |
|
|
In reply to this post by Nick Thompson
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:[hidden email]] On Behalf Of glen > Sent: Wednesday, July 18, 2018 4:30 PM > To: The Friday Morning Applied Complexity Coffee Group <[hidden email]> > 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 <[hidden email]> 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 <[hidden email]> on behalf of Nick Thompson > ><[hidden email]> > >Reply-To: The Friday Morning Applied Complexity Coffee Group > ><[hidden email]> > >Date: Wednesday, July 18, 2018 at 10:53 AM > >To: 'The Friday Morning Applied Complexity Coffee Group' > ><[hidden email]> > >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 |
|
|
"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."
For example, I don't see analogs of cytokines, hormones, or neurotransmitters in Smalltalk or any computing systems today. The closest that comes to mind are functional reactive programming systems, e.g. game platforms tied to a physics engine. The idea that top-down intent matters is preposterous if the motivation is biology, a massively-parallel bottom-up phenomena that involves physical stuff. Marcus ============================================================ 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 |
|
|
Of course it's reasonable for you to dissent! But over and above the most important example Marcus raises of biology (because *everything* is biology 8^), even your historical account is a litany of WHAT, not WHY.
Sure it may seem like you're examining the why of these artifacts. But you're not. Why questions are always metaphysical. What you're actually doing in your list and analysis of past events is inferring the WHY from the WHAT. And your inferences, no matter how good you are at inferring, will always just be your best guess at WHY. Like with the Great Man Theory, the actual causes of any phenomena in a complex and complicated system like Xerox Parc (embedded in culture, society, psychology, physiology, biology, chemistry, etc.) are multifarious and occult. No oversimplified *narrative* like yours will fully circumscribe those causes. To think otherwise is to fool oneself into false belief ... a kind of faith-based world view. On July 19, 2018 3:01:57 AM PDT, Marcus Daniels <[hidden email]> wrote: >"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." > >For example, I don't see analogs of cytokines, hormones, or >neurotransmitters in Smalltalk or any computing systems today. The >closest that comes to mind are functional reactive programming systems, >e.g. game platforms tied to a physics engine. >The idea that top-down intent matters is preposterous if the motivation >is biology, a massively-parallel bottom-up phenomena that involves >physical stuff. -- 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
uǝʃƃ ⊥ glen
|
|
|
In reply to this post by Prof David West
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:[hidden email]] On Behalf Of Prof David West Sent: Thursday, July 19, 2018 4:02 AM To: [hidden email] 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:[hidden email]] On Behalf Of glen > Sent: Wednesday, July 18, 2018 4:30 PM > To: The Friday Morning Applied Complexity Coffee Group > <[hidden email]> > 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 <[hidden email]> 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 <[hidden email]> on behalf of Nick Thompson > ><[hidden email]> > >Reply-To: The Friday Morning Applied Complexity Coffee Group > ><[hidden email]> > >Date: Wednesday, July 18, 2018 at 10:53 AM > >To: 'The Friday Morning Applied Complexity Coffee Group' > ><[hidden email]> > >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 ============================================================ 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 |
|
|
In reply to this post by gepr
"Like with the Great Man Theory, the actual causes of any phenomena in a complex and complicated system like Xerox Parc (embedded in culture, society, psychology, physiology, biology, chemistry, etc.) are multifarious and occult."
Assuming there even was a Great Idea to go with a Great Man. For starters..
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 http://www.stlport.org/resources/StepanovUSA.html http://wiki.c2.com/?ArgumentsAgainstOop From: Friam <[hidden email]> on behalf of glen <[hidden email]>
Sent: Thursday, July 19, 2018 7:22:17 AM To: The Friday Morning Applied Complexity Coffee Group Subject: Re: [FRIAM] What is an object? Of course it's reasonable for you to dissent! But over and above the most important example Marcus raises of biology (because *everything* is biology 8^), even your historical account is a litany of WHAT, not WHY.
Sure it may seem like you're examining the why of these artifacts. But you're not. Why questions are always metaphysical. What you're actually doing in your list and analysis of past events is inferring the WHY from the WHAT. And your inferences, no matter how good you are at inferring, will always just be your best guess at WHY. Like with the Great Man Theory, the actual causes of any phenomena in a complex and complicated system like Xerox Parc (embedded in culture, society, psychology, physiology, biology, chemistry, etc.) are multifarious and occult. No oversimplified *narrative* like yours will fully circumscribe those causes. To think otherwise is to fool oneself into false belief ... a kind of faith-based world view. On July 19, 2018 3:01:57 AM PDT, Marcus Daniels <[hidden email]> wrote: >"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." > >For example, I don't see analogs of cytokines, hormones, or >neurotransmitters in Smalltalk or any computing systems today. The >closest that comes to mind are functional reactive programming systems, >e.g. game platforms tied to a physics engine. >The idea that top-down intent matters is preposterous if the motivation >is biology, a massively-parallel bottom-up phenomena that involves >physical stuff. -- 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 |
|
|
Well, it goes without saying, doesn’t it, that it’s your current IDEAS of biology that influence your programming, not biology itself, right? And your biologiized ideas of programming then influence your notion of the cell. We never really know clouds themselves. So to speak. N Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University From: Friam [mailto:[hidden email]] On Behalf Of Marcus Daniels "Like with the Great Man Theory, the actual causes of any phenomena in a complex and complicated system like Xerox Parc (embedded in culture, society, psychology, physiology, biology, chemistry, etc.) are multifarious and occult." Assuming there even was a Great Idea to go with a Great Man. For starters.. https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 http://www.stlport.org/resources/StepanovUSA.html http://wiki.c2.com/?ArgumentsAgainstOop From: Friam <[hidden email]> on behalf of glen <[hidden email]> Of course it's reasonable for you to dissent! But over and above the most important example Marcus raises of biology (because *everything* is biology 8^), even your historical account is a litany of WHAT, not WHY. ============================================================ 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 |
|
|
Nick, If I were programming in
Cello, then actual constraints of biology would influence me. If I were programming an agent simulation for a system biology modeling project, what I understood about biology would go into that. But not all kinds of programming would be influenced by biology. Programming language features for typing or genericity are precise mathematical instruments that are best
to understand on their own, without any vague or grandiose metaphors. Also, I would discriminate between programming and computation. There are many kinds of computation that would be interesting to consider separate from programming. (Although
`programming’ to me already has a broader meaning than it does for some.) Marcus From: Friam <[hidden email]> on behalf of Nick Thompson <[hidden email]> Well, it goes without saying, doesn’t it, that it’s your current IDEAS of biology that influence your programming, not biology itself, right? And your biologiized
ideas of programming then influence your notion of the cell. We never really know clouds themselves. So to speak.
N Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University From: Friam [mailto:[hidden email]]
On Behalf Of Marcus Daniels "Like with the Great Man Theory, the actual causes of any phenomena in a complex and complicated system like Xerox
Parc (embedded in culture, society, psychology, physiology, biology, chemistry, etc.) are multifarious and occult." Assuming there even was a Great Idea to go with a Great Man. For starters.. https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 http://www.stlport.org/resources/StepanovUSA.html http://wiki.c2.com/?ArgumentsAgainstOop From: Friam <[hidden email]>
on behalf of glen <[hidden email]> Of course it's reasonable for you to dissent! But over and above the most important example Marcus raises of biology (because *everything* is biology 8^), even your historical account is a litany of WHAT,
not WHY. ============================================================ 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 |
|
|
In reply to this post by Nick Thompson
There's also a deeper objection to this than Marcus makes, that of "data driven" modeling. I fight this battle all the time at biological modeling conferences. Most modelers *do* develop models based on ideas ... or, more technically, abstract hypotheses about abstract things (e.g. lipophilicity). Their "best practices" suggest they can do that and then, later on, fill in those parameters/variables with numbers derived from actual measurements of experiments. So, their conceptual models are then *enlightened* or guided by the real biology. But the model's gist is still something very much like an "idea".
Data driven modeling takes a different approach. It _attempts_ to derive models *directly* from the biology (as directly as possible, anyway), rather than going through us (obviously fallible) human abstraction machines. Machine learning is an attempt at this. Teh *-omics are attempts at this. Etc. And while it's (currently) true that such modeling efforts remain, in general, less efficient and effective at building useful models, they are making some progress. E.g. https://www.news-medical.net/news/20180712/Study-suggests-database-analysis-better-predicts-toxicity-of-chemicals-than-animal-testing.aspx So, no, it does NOT go without saying that one's ideas influence the programming. It's true pretty much everywhere, but it does "go without saying". Add to that my dead horse: that all ideas are actually biology, anyway, and it would be more accurate to say that a programmer's biology influences their programming. And that's obviously true to any programmer who's put off going to the bathroom for just ONE MORE edit-compile-test iteration. On 07/19/2018 07:32 AM, Nick Thompson wrote: > Well, it goes without saying, doesn’t it, that it’s your current IDEAS of biology that influence your programming, not biology itself, right? And your biologiized ideas of programming then influence your notion of the cell. We never really know clouds themselves. So to speak. -- ☣ uǝlƃ ============================================================ 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
uǝʃƃ ⊥ glen
|
|
|
Ha! I made a Trump by leaving out the word "not". That should be "..., but it does not 'go without saying'."
On 07/19/2018 08:42 AM, uǝlƃ ☣ wrote: > So, no, it does NOT go without saying that one's ideas influence the programming. It's true pretty much everywhere, but it does "go without saying". -- ☣ uǝlƃ ============================================================ 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
uǝʃƃ ⊥ glen
|
|
|
In reply to this post by gepr
Glen writes:
< Data driven modeling takes a different approach. It _attempts_ to derive models *directly* from the biology (as directly as possible, anyway), rather than going through us (obviously fallible) human abstraction machines. Machine learning is an attempt at this. Teh *-omics are attempts at this. Etc. And while it's (currently) true that such modeling efforts remain, in general, less efficient and effective at building useful models, they are making some progress. E.g. https://www.news-medical.net/news/20180712/Study-suggests-database-analysis-better-predicts-toxicity-of-chemicals-than-animal-testing.aspx > This reminds me of how some say that dogs don't have shame or dogs don't love you, etc. that the head-hanging is just an empty learned behavior to get along with humans. Who says humans are any different? Marcus ============================================================ 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 |
|
|
Yep. That's a fantastic example of metaphysical predisposition interfering with one's ability to reason well. When I was a kid, my mom and I would argue a lot about whether animals had souls. She claimed they absolutely did not. Being young, I had no real idea what a soul was. But I would argue that her justification for her belief was all from her religion (Catholicism). *Practically*, her belief was exhibited when my beagle (Snoopy, of course) was killed by a car. She tossed his body in the regular garbage and he was crushed and hauled away. To this day, she has no idea why that was so horrible.
On 07/19/2018 09:15 AM, Marcus Daniels wrote: > < Data driven modeling takes a different approach. It _attempts_ to derive models *directly* from the biology (as directly as possible, anyway), rather than going through us (obviously fallible) human abstraction machines. Machine learning is an attempt at this. Teh *-omics are attempts at this. Etc. And while it's (currently) true that such modeling efforts remain, in general, less efficient and effective at building useful models, they are making some progress. E.g. https://www.news-medical.net/news/20180712/Study-suggests-database-analysis-better-predicts-toxicity-of-chemicals-than-animal-testing.aspx > > > This reminds me of how some say that dogs don't have shame or dogs don't love you, etc. that the head-hanging is just an empty learned behavior to get along with humans. > Who says humans are any different? -- ☣ uǝlƃ ============================================================ 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
uǝʃƃ ⊥ glen
|
|
|
In reply to this post by Marcus G. Daniels
Marcus, But it’s models all the way down, right? Furthermore, even for a dualist, your “biology” is the lens through which you see the world. So, the idea that there is a world out there against which we can measure our representations of It is just silly, right? All we have is representations of representations. That is what OOO seems to challenge, but I am hoping to save that conversation for when we can read Harmon together. Right now I am just trying to get a grip on what you mean by coop. N Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University From: Friam [mailto:[hidden email]] On Behalf Of Marcus Daniels Nick, If I were programming in Cello, then actual constraints of biology would influence me. If I were programming an agent simulation for a system biology modeling project, what I understood about biology would go into that. But not all kinds of programming would be influenced by biology. Programming language features for typing or genericity are precise mathematical instruments that are best to understand on their own, without any vague or grandiose metaphors. Also, I would discriminate between programming and computation. There are many kinds of computation that would be interesting to consider separate from programming. (Although `programming’ to me already has a broader meaning than it does for some.) Marcus From: Friam <[hidden email]> on behalf of Nick Thompson <[hidden email]> Well, it goes without saying, doesn’t it, that it’s your current IDEAS of biology that influence your programming, not biology itself, right? And your biologiized ideas of programming then influence your notion of the cell. We never really know clouds themselves. So to speak. N Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University From: Friam [[hidden email]] On Behalf Of Marcus Daniels "Like with the Great Man Theory, the actual causes of any phenomena in a complex and complicated system like Xerox Parc (embedded in culture, society, psychology, physiology, biology, chemistry, etc.) are multifarious and occult." Assuming there even was a Great Idea to go with a Great Man. For starters.. https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 http://www.stlport.org/resources/StepanovUSA.html http://wiki.c2.com/?ArgumentsAgainstOop From: Friam <[hidden email]> on behalf of glen <[hidden email]> Of course it's reasonable for you to dissent! But over and above the most important example Marcus raises of biology (because *everything* is biology 8^), even your historical account is a litany of WHAT, not WHY. ============================================================ 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 |
|
|
I accept there are some default lenses, but of course one develops more specific and different lenses to see the world too. I’m arguing that the default lens is not helpful
as well as not anywhere close to correct. It is not an efficient way to reason about the detailed mechanisms of a computer program. From: Friam <[hidden email]> on behalf of Nick Thompson <[hidden email]> Marcus,
But it’s models all the way down, right?
Furthermore, even for a dualist, your “biology” is the lens through which you see the world. So, the idea that there is a world out there against which we can
measure our representations of It is just silly, right? All we have is representations of representations.
That is what OOO seems to challenge, but I am hoping to save that conversation for when we can read Harmon together. Right now I am just trying to get a grip
on what you mean by coop. N Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University From: Friam [mailto:[hidden email]]
On Behalf Of Marcus Daniels Nick, If I were programming in
Cello, then actual constraints of biology would influence me. If I were programming an agent simulation for a system biology modeling project, what I understood about biology would go into that. But not all kinds of programming would be influenced by biology. Programming language features for typing or genericity are precise mathematical instruments that are best
to understand on their own, without any vague or grandiose metaphors. Also, I would discriminate between programming and computation. There are many kinds of computation that would be interesting to consider separate from programming. (Although
`programming’ to me already has a broader meaning than it does for some.) Marcus From: Friam <[hidden email]> on behalf of Nick Thompson <[hidden email]> Well, it goes without saying, doesn’t it, that it’s your current IDEAS of biology that influence your programming, not biology itself, right? And your biologiized
ideas of programming then influence your notion of the cell. We never really know clouds themselves. So to speak.
N Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University From: Friam [[hidden email]]
On Behalf Of Marcus Daniels "Like with the Great Man Theory, the actual causes of any phenomena in a complex and complicated system like Xerox
Parc (embedded in culture, society, psychology, physiology, biology, chemistry, etc.) are multifarious and occult." Assuming there even was a Great Idea to go with a Great Man. For starters.. https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53 http://www.stlport.org/resources/StepanovUSA.html http://wiki.c2.com/?ArgumentsAgainstOop From: Friam <[hidden email]>
on behalf of glen <[hidden email]> Of course it's reasonable for you to dissent! But over and above the most important example Marcus raises of biology (because *everything* is biology 8^), even your historical account is a litany of WHAT,
not WHY. ============================================================ 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 |
| Free forum by Nabble | Edit this page |