Dear Terry
I think you need to offer an account of "causal" which is probably much more the term at issue than "motivation".
I'm not at all sure the computer people are taking "liberties" - they are more following the processes of reasoning.
The status of the reflect-object and the reify-object are equally important which is also the case with "motivation" as object whether it be reflect-object or reify-object.
Process logic offers an account of time/space/identity. The various ways in which identity shifts within systems indicates the conventions of the system much more than the time/space aspects. I'd like to see your account of these three abstracts in terms of their status within your account of causality.
PS - Your reply suggests that sometimes people engage in sloppy thinking. Nobody is really that sloppy in their thinking - they are often unable to give an account of how their thinking works, but how they think, on inspection, is one of the possible ways of thinking.
all the best
keith
>>> Terence Love <[log in to unmask]> 24/02/2006 1:49 pm >>>
Hi Keith,
I feel you are confusing and conflating two very different sorts of word
explanations.
On one hand are the careful definitions necessary to make reasoning in
speech as unambiguous and as representative as possible in order to use
reasoning as a tool for forecasting in a way that the use of the tool can be
checked for correctness by others.
On the other hand, the document you refer to is a glossary of rough
explanations of terms to help a beginner in the use of what is relatively
loose jargon. This glossary defines reflect and reify in a relatively
ambiguous manner. In reality, the words are loosely-defined 'designer speak'
- deliberately ambiguous verbal hand waving in this case to refer to
aspects of programming. As I understand it, 'reify' is used in this context
to refer to giving more status to part of a process than would otherwise be
expected by giving that bit of process a title to itself( assign it to a
variable) as a placeholder. 'Reflect' in contrast means to return some
information to the main program path after doing a bit of work on the side.
This is loose designer talk, taking liberties with 'English' in much the
same way that an engineering designer might contrast a 'serious bit of
structure' with a 'flimsy bracket'.
This doesn't help either way with the concrete-abstract issue because
computer software writing commonly blurs this issue by using the language of
human interaction to give agency to program elements.
How people design is a very complex phenomena that it is necessary to
address in many dimensions, from many perspectives and using insights and
theories from many domains. All of these discourses must necessarily
integrate well.
I find that minimising confusion is really helpful to enable careful
verifiable reasoning about these issues. Using abstract entities in causal
explanations as if these entities are real simply muddies the discourse and
provides the basis for an easy drift into fallacious and sophist reasoning.
Thoughts?
Terry
-----Original Message-----
From: Keith Russell [mailto:[log in to unmask]]
Sent: Friday, 24 February 2006 10:10 AM
To: [log in to unmask]
Subject: motives and the myths of reification
Dear Terence
I'm not sure it helps to make such distinctions as if the world were nuts
and bolts and all the rest mere un-things.
I have quoted a computer science distinction below that might help redeem
abstract-concretes/concrete-abstracts from linguistics 101.
I would hate to think that computer logic was allowed such subtle
distinctions while philosophers have to do battle with the brute tools of
"is this a dagger I see before my eyes?"
all the best
keith
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
reflect (v) ? the opposite of reify; to call a continuation.
reify (v) to make something (specifically, a continuation or partial
continuation) assignable to variable. What call-with-current-continuation
does.
http://community.schemewiki.org/?glossary
|