Re: [asa] Evangelicals, Evolution, and Academics Introduction now available

Greg
> First, I'm speaking as a human-social scientist (more precisely, as a
> sociologist of science), not as a computer programmer. However, I
> assume, and please object to my assumption if it is incorrect, that
> human beings (in an active, intentional sense) are the ones who
> program computers. My sister was a programmer, so I can pretty much
> rest easy that you'll agree.
The pedantic answer is that most computers are programed most of the
time by programs not programmers. Few programmers actually directly
create the bits that are executed by the processor. Sure I can and
have done it but it is very painful. Typically the programmer writes
code which is translated by a compiler for the processor to execute.
If high levels of optimization are involved then the code actually
executed is very hard to relate to the users source.

That aside, programmers write most of source language that is translated
into something that a computer can execute however program generators
and what are often called wizards often create all or part of the source
language. For example the IBM family of Java interpreters are not
actually hand coded but are produced by what is called an application
generator. But in turn the application generator is hand coded in
something like C, C++ or Smalltalk.

>
> The descriptive vs. prescriptive approach is a red herring. Why avoid
> teleology? You write: "the term sometimes used is '/*business
> requirements have evolved'*/." Tell me please, what difference in
> meaning would saying 'business requirements have changed' imply?
> Getting better, progress? To me, to say 'evolving' is just to use
> sexy/popular jargon without any added meaning. Ask yourself this
> question: what particular type of change is evolution? If it is just
> any and every change (which is what I'm arguing against), then you're
> veering into the realm of TE/TE; only God doesn't change.
>
> Why do I say this? Because a difference in computer programming and
> biological science is that you can't imply such things as choice, free
> will, agency, intention, purpose, meaning and even teleology for the
> vast majority of biological objects (but please, no one open up an
> 'other animals' branch in this thread, cuz I'm not going there now -
> I'm a human-social thinker, not an ethologist - you can dialogue
> with Dawkins or E.O. Wilson about it if you want).
>
>
> Perhaps this will help explain my position - a proposition that I
> wrote almost four years ago, which I posted at ASA list a year or so
> ago: "Human-made things do not 'evolve' into existence (being or
> having become)." This is because human-making is a non-evolutionary
> action, i.e. it is purposeful, meaningful, goal-oriented, intentional,
> willful, etc. with a few exceptions (e.g. the idea of 'unanticipated
> consequences' [Robert Merton, 1936] is one example within the
> evolutionary sociological tradition). Please don't put such things as
> 'fitness landscapes' and 'environmental pressures' in contrast with
> intentional human action - they are in a sphere they don't properly
> belong!
>
Changes in business process can occur because people are lazy, sloppy,
malicious etc and these I would not refer to as evolutionary. The key
in my thinking, when I would call change in business process
evolutionary is when one has an existing working, however poorly,
process and then one makes small changes to that process to adapt to
changing business requirements. Of course over the long term one can
look at the life cycle of processes and the introduction of replacement
totally new processes as evolutionary change but this is more in the
same sense as stellar evolution is used.

In the real world 'unanticipated consequences' occur all the time and
require some kind of fix.

Let me try one last time to explain why I would describe the
evolutionary programming methodology/process that I think works from
other methodologies.

A.The big bang process
In this view you have a specification in hand and then turn one or more
programmers loose to write the code over a period measured in months to
years. At the end of that time, for the first time ever an attempt is
made to execute the code produced by the programmers. Except for very
small programs I have never seen this approach work or even tried,
although I have seen it strongly recommended.

B.The periodic integration (maybe punctuated equilibrium???) process
Like A above except:
i.The programmers are expected to create test environments and perform
what are called unit tests on their code as they go along, thus when
time comes to integrate the code produced by the programming teams,
there is at least some hope of the pieces working.
ii.Every few months attempts are made to bring all the disparate pieces
of code together and make them function. During this time the
programmers stop writing code and spend most of their time debugging.
This process has more or less been made to work, although at times the
results are less than optimal.

C.The evolutionary process as I described, hopefully for the last time,
in my earlier note.
The key here is
i.As early as possible get a program running that is capable of
performing even a minuscule portion of the intended function.
ii.Thereafter make relatively small changes that are integrated into the
running program very frequently ie hourly, daily or at most weekly.
In this process the program design/algorithm is actually changed as one
sees what works and what doesn't. Sometimes the programmer realizes
that the algorithm chosen was totally inappropriate and completely
scraps code recently written. The point is that the feedback as to what
works and what does not, occurs very rapidly. Think of this like a
selection process. Programmers don't really know how to design a
program until they have written the program or something very similar in
the past. Yes that is an overstatement but it contains a large grain of
truth.

I would not characterize process A as evolutionary even though the code
written by the programmers changes and grows day by day. Process B is
more evolutionary and in fact is always used with very large groups of
programmers or when replacing major components of a whole program. Each
individual team/group may follow process C but their overall
contributions to the final result are only integrated periodically,
months or years apart. It is the relatively immediate feedback,
learning, selection of what works and what does not that I would prefer
to characterize as evolutionary.

And yes I agree with you that change is often described as evolutionary
simply to provide a veneer of scientific respectability. It seems to me
that where we *//*
<http://www.google.ca/search?hl=en&client=firefox-a&channel=s&rls=org.mozilla:en-US:official&hs=eui&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=principally&spell=1>
principally differ is that you are reluctant to accept the domain or
context specific meaning of words. Maybe a better description of what I
am getting at is an Iterative, Incremental, Exploratory Process rather
than an Evolutionary Process, but at least in the programming culture I
come from, that is the terminology used and I am not about to tilt at
windmills. Maybe you have a better adjective that describes what I am
getting at, but all I have as alternatives are phrases and that very
quickly gets tiresome. You seem to contend that an evolutionary process
must contain some element of random mutations and must not contain "such
things as choice, free will, agency, intention, purpose, meaning and
even teleology" and that is another place where we differ.

> This is a really hard conversation to have (especailly by e-chat)
> because we are speaking from different academic traditions. I would
> ask Dave Wallace if he thinks natural sciences and human-social
> sciences operate with exactly the same methodological principles. It
> appears to me that he thinks this to be the case. A bit of W. Dilthey
> (even just wiki) would serve a good dose!!
The simple answer is that I do not know. I would hope that the basic
scientific methodology wrt falsifiability is followed, but not
necessarily in a rigid, literal way. I understand that paradigms and
theories will remain in force even in the presence of conflicts and
contrary data, sometimes we have to use the best tools we have.

Having written programming methodology for teams which I was responsible
for, I know that no two teams ever follow the "exact" same methodology
even when working in the same discipline and supposedly reading the same
document.

Apologies for the long boring post but it may be necessary to
communicate across very disparate disciplines.

To unsubscribe, send a message to majordomo@calvin.edu with
"unsubscribe asa" (no quotes) as the body of the message.
Received on Tue May 20 06:47:30 2008