[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Subject Index][Author Index]

Re: TETRAPODS, PHYLOGENETIC TAXONOMY, AND CLEAR DEFINITIONS



On Mon, 27 Jul 1998, Thomas R. Holtz, Jr. wrote:

> At 07:10 AM 7/26/98 -0400, Johnathon Woolf wrote:

[snip]

> >To me, saying "X is a dinosaur even though X doesn't have all the diagnostic
> >features of a dinosaur" is as much a contradiction as saying "6 is a prime
> >number."  (A ^ ~A) --> B; in words, "from a contradiction, anything
> follows."  Your
> >systematics will never make any logical sense as long as you allow casual
> >violations of the laws of logic.

> Okay, I talked with my wife (who's also a software designer), and maybe what
> we came up with will help explain the difference:

> Engineers are creators.  Like artists, you are building fresh and anew
> something that didn't previously exist.  As such, within certain frameworks
> (e.g., computer language, architectural constraints, etc.), you have greater
> freedom to build things the way you see fit.

> Scientists are discoverers.  Like explorers, we are trying to find something
> that already exists.  (In the case of systematics, trying to recover the
> historical pattern of descent with modification).  We may use certain tools
> to analyse, label, and describe these patterns of nature, but we do not have
> the liberty of creating them out of whole cloth.

[snip]

As a decidedly amateur bio/palaeo enthusiast and a computer science
student, I'd like to stick my neck out for a moment. This is a good
analysis of part of the situation, and I think it is a valid answer in
many ways. However, I think there is a more direct analog in computer
science which demonstrates the point. Scientific nomenclature is designed
around establishing a coherent naming system which all scientific peers
may use in their work. It's not just about what one person does, it's
about the ability of people to work together with common meaning to the
labels we use.

In many software projects, the designers and programmers are required to
work together in groups, dividing up the work on large projects. There are
common names (class names, object names, ad infinitum) which have to be
shared by all the workers. If we are working with extensive legacy code
(analog: previous scientific publications) then the names agreed upon
stretch back into past work, and sometimes it is not possible to change
that work (all the time in science; it would be neither feasible nor
ethical to go back with white-out and correct all previous references). If
a programmer is working alone on a self-contained project, it's fine to go
about changing names willy-nilly; it's just a repeated "find and replace"
operation on the source code. But when you're working together with a
team, it's a different matter. You can't just decide that Joe's choice to
name a class is not rational enough and go back and change the name.
Everyone else's code that depends on Joe's class will stop working until
they too put the name change into effect. Any unchangeable legacy code
that depends on the name will simply be broken.

There _are_ various programming tricks (depending on the language) that we
can use to create synonyms for class names and so forth, so that the old
code will use the old name happily while we can use the new, better name,
but this is problematic to understanding as well. Take a second to ponder
the naming chaos that this creates. A legacy library uses X to refer to
the same thing that is renamed to Y in module A, which refers to the same
thing that is renamed Z in module B, which the main module calls something
else entirely. This is a good way to seriously retard the understanding of
anyone who later examines the code, or even any of your co-workers who
take a gander at your work.

One could also think of it as being sort of like the interface of a class
(public declarations or an abstract parent class for you C++ users). We
have data hiding exactly so that we can have classes whose NAMED INTERFACE
remains the same. Why?  Because clients depend on constant behavior from
the class. As soon as you change the interface, you make it necessary for
all clients to alter their behavior, and in many cases this is
unnecessary, undesirable, and unacceptable. Even if class Complex doesn't
REALLY store its components as double-precision floats anymore doesn't
give you the right to break clients by chopping out its methods to
retrieve double-precision floats of r and theta. And the same is true of
biological taxa.

-- 
[Charles W. Johnson <cwj2@eskimo.com> - http://www.eskimo.com/~cwj2]
|    Heathen@Undernet (there is a Heathen@Dalnet. I am not he.)    |
|<BriceW:#atheism> Is this where you gfo instaed of Church?!       |
[                 My opinions are mine alone. Duh.                 ]