XP, metaphor and architectural style
Giovanni Asproni
Recently I've come across two books about software architecture
"Software Architecture: perspectives on an emerging discipline" by Mary
Shaw and David Garland and "Software Architecture in practice" by Len
Bass et. al.
These books define an 'architectural style' basically as a set of
"components", a set of "connectors" and some rules and constraints on
how to connect "components" by means of "connectors". So for example
there are the Object Oriented style, the client-server style, the pipes
and filters style, the layered style....
Of course there are many more and each of them with many variations.
It happens that a system, usually, is made of different 'architectural
styles', depending on the perspective from which the system is analyzed,
i.e., a client-server system can be composed of "layered" components and
connectors, can be programmed using an OO language...
So I have this question: is the "metaphor" used in XP is another name
for the "more evocative" (I can't find a better term) 'architectural
style' that describes a system, that is the view that better describes
how the system will satisfy the user requirements?
If the answer to the previous question is yes, does the refactoring
process keep this 'architectural style' fixed during all the
development, or also this is subject to some form of refactoring?
Giovanni
Tokomar
> So I have this question: is the "metaphor" used in XP is another name
> for the "more evocative" (I can't find a better term) 'architectural
> style' that describes a system, that is the view that better describes
> how the system will satisfy the user requirements?
>
> If the answer to the previous question is yes, does the refactoring
> process keep this 'architectural style' fixed during all the
> development, or also this is subject to some form of refactoring?
Understand I have only read the XP "literature" (such as it is).
But the "System Metaphor" is supposed to be something so isolated from the
actual architecture that you could replace the latter with another one and
not touch the former. The SM provides an origin for the jargon a team uses,
and for the identifiers in the source code.
The vaunted Chrysler Comprehensive Compensation project used the
metaphor of bins, parts and a conveyor belt, so that even the ghost of
Henry Ford would have been able to discuss the system with its engineers.
But the architectural details to support these novelties could have changed
while the names remained the same (and they probably did).
Those seeking a role for the "architect", and for the "system metaphor",
would do well to understand these are orthogonal concepts.
--
Tokomar
David Van Camp
news:3CCEB294...@ebi.ac.uk...
> So I have this question: is the "metaphor" used in XP is another name
> for the "more evocative" (I can't find a better term) 'architectural
> style' that describes a system, that is the view that better describes
> how the system will satisfy the user requirements?
In a word: no.
Metaphors may be drawn from any commonly understood concept. An architecture
might or might not be a candidate metaphor for a project, depending on the
project and the general knowledge of people involved.
By metaphor XP means a consistent convention used for identifier naming & as
a guide to help problem solving. It can influence key architectural
decisions, but *usually* the architecture is not the metaphor. XP does not
define the concept very well, but, basically they are trying to do for
software design what UI designers have been doing with graphical screen
elements (e.g. Window, Document, Desktop -- and note that GUIs are mixing
metaphors, which is very tricky to do well!) You might find the information
on metaphor enlightening in my article on the Principles of UI design, which
you can find here: http://davidvancamp.com/articles.html The general
principle is the same.
My feeling is that, when you can find a fairly obvious, easily
understandable and closely map-able metaphor, use it. However, the metaphor
must map well to the problem and be understood by *everyone*. Otherwise it
is better not to use a metaphor. Bad metaphors are worse than no metaphors.
--
David Van Camp.com :: Software Development Consulting
Patterns, Reuse, Software Process Improvement
http://www.davidvancamp.com
Visit the OO Pattern Digest :: http://patterndigest.com
A catalog of condensed patterns, books and related resources
Universe
> Giovanni Asproni wrote:
>
>> So I have this question: is the "metaphor" used in XP is another name
>> for the "more evocative" (I can't find a better term) 'architectural
>> style' that describes a system, that is the view that better describes
>> how the system will satisfy the user requirements?
>>
>> If the answer to the previous question is yes, does the refactoring
>> process keep this 'architectural style' fixed during all the
>> development, or also this is subject to some form of refactoring?
> Understand I have only read the XP "literature" (such as it is).
> But the "System Metaphor" is supposed to be something so isolated from the
> actual architecture that you could replace the latter with another one and
> not touch the former. The SM provides an origin for the jargon a team uses,
> and for the identifiers in the source code.
> The vaunted Chrysler Comprehensive Compensation project used the
> metaphor of bins, parts and a conveyor belt, so that even the ghost of
> Henry Ford would have been able to discuss the system with its engineers.
!!??
The aborted Chrysler XP project was a human resources payroll application,
NOT an automobile/parts production control/monitoring system.
> But the architectural details to support these novelties could have changed
> while the names remained the same (and they probably did).
> Those seeking a role for the "architect", and for the "system metaphor",
> would do well to understand these are orthogonal concepts.
The 1) use case Domain class/objects, based upon project scope domain
vocabulary, concepts, and semantics, along with the 2) use case Interface
class/objects, and 3) use case Controller class/objects are a major high
level aspect and leg of system architecture.
If this architectural reification is not present regarding the XP System
Metphor, which it doesn't seem to be then, you couldn't be more correct
that one should separate the XP SM from the mainstream OO use case, high
level architectural class/object model I just described.
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2001 my comments ~ newsgroups+bitnet OK
Ron Jeffries
>So I have this question: is the "metaphor" used in XP is another name
>for the "more evocative" (I can't find a better term) 'architectural
>style' that describes a system, that is the view that better describes
>how the system will satisfy the user requirements?
Metaphor is definitely not well-described in XP. Maybe someday we'll figure out
what we meant.
At its simplest, Metaphor refers to a consistent "system of names" (See Ward
Cunningham's patter of that name) that are used for the objects in the system.
With a good set of consistent names throughout the system, programmers can
quickly "guess" where to look in the code to find what they need.
With some systems we have been able to come up with mataphors that are more than
just consistent: they are vivid and evocative descriptions of how the system
works. See my reply to Tokamar below for more commentary on C3's assembly line
metaphor.
Metaphors can be very simple, and are probably best when they are simple. We
might describe our system as "like the postal service -- the mailman comes
around and picks up and delivers mail", or "like an ant colony -- all the ants
go out and pick up interesting food and bring it back to the colony", or "like a
uni-line at the bank -- the next available server takes care of the next task".
I'm sure Beck had something in mind when he wrote about metaphor, and I've seen
it work. At this point in the books, we haven't said much useful. Maybe someday
...
>If the answer to the previous question is yes, does the refactoring
>process keep this 'architectural style' fixed during all the
>development, or also this is subject to some form of refactoring?
Refactoring can change anything in the implementation, so I would suppose it can
change "architectural style" if you want it to. I haven't read the books you
refer to, however, so I'm only basing that on the fact that refactoring can
change whatever you want it to.
Does that help?
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Ron Jeffries
>Giovanni Asproni wrote:
>
>> So I have this question: is the "metaphor" used in XP is another name
>> for the "more evocative" (I can't find a better term) 'architectural
>> style' that describes a system, that is the view that better describes
>> how the system will satisfy the user requirements?
>>
>> If the answer to the previous question is yes, does the refactoring
>> process keep this 'architectural style' fixed during all the
>> development, or also this is subject to some form of refactoring?
>
>Understand I have only read the XP "literature" (such as it is).
>
>But the "System Metaphor" is supposed to be something so isolated from the
>actual architecture that you could replace the latter with another one and
>not touch the former. The SM provides an origin for the jargon a team uses,
>and for the identifiers in the source code.
The metaphor does provide a common source for the naming in the system. However,
I suspect that it also impacts things that should be considered architectural.
>
>The vaunted Chrysler Comprehensive Compensation project used the
>metaphor of bins, parts and a conveyor belt, so that even the ghost of
>Henry Ford would have been able to discuss the system with its engineers.
>But the architectural details to support these novelties could have changed
>while the names remained the same (and they probably did).
Well, only sort of. The metaphor only makes sense if the parts go in bins and
the bins associate with stations and the stations are in an assembly line. So
the structure of any system built on that metaphor will likely have the bins be
some kind of container, the stations "having" some bins, and so on. Thus the
metaphor pins down a kind of "top level" architecture.
How those ideas are implemented is of course open.
>
>Those seeking a role for the "architect", and for the "system metaphor",
>would do well to understand these are orthogonal concepts.
I'm not quite sure what you're saying here, so I apologize if I am getting it
wrong. Since the metaphor is a description and the architect is a person,
they're definitely quite separate. I'm guessing you mean that there is lots more
to architecture than just the metaphor, and with that I agree. XP doesn't say
what architecture is, and based on a long discussion that's going on on the xp
mailing list, few people agree anyway.
In general, some decisions that might be called architectural seem always to be
made "up front". Others come along as the system grows. Since XP is a ver
incremental approach to software, much of architecture (whatever that is)
probably emerges along the way.
Regards,
Giovanni Asproni
and "Architectural Style" so I'll try to clarify it.
In the first mail I talked about "Architectural Style", not about
"Architecture". They are different things.
An "Architectural Style" is nothing but a Pattern from which many concrete
architectures can be derived. So it gives also a vocabulary that can be used to
develop an "Architecture".
Here is an example.
When I talk about a client-server application in general terms I'm talking
about the "Architectural Style" of that application.
When I talk about a CORBA client-server application whit some more detailed
information on the data-flow I'm talking about the "Architecture" of the
application.
So I asked my first question because it seems to me that the "Architectural
Style" of an application is something fixed during the development even using
XP practices, and also can have an influence in the choice of the metaphor. But
since it is just a "feeling" I wanted to have other opinions about it.
Giovanni
Giovanni Asproni
"Architectural Style" just before reading your reply.
I've read also your reply to Tokomar, in particular your phrase:
"Well, only sort of. The metaphor only makes sense if the parts go in bins and
the bins associate with stations and the stations are in an assembly line. So
the structure of any system built on that metaphor will likely have the bins be
some kind of container, the stations "having" some bins, and so on. Thus the
metaphor pins down a kind of "top level" architecture."
makes me feel that "Architectural Style" and metaphor have quite a strong relation.
Giovanni
Tokomar
> Well, only sort of. The metaphor only makes sense if the parts go in bins
> and the bins associate with stations and the stations are in an assembly
> line. So the structure of any system built on that metaphor will likely
> have the bins be some kind of container, the stations "having" some bins,
> and so on. Thus the metaphor pins down a kind of "top level" architecture.
>
> How those ideas are implemented is of course open.
Consider a fairly junior team instructed today they must hunt the metaphor
for their new system. If you tell them the above, out of context, they
might think you said, "You must architect your system right now based on
the aphorism you carry home for it."
Don't tell them that, if architecture and metaphor are to be orthogonal.
--
Tokomar
Shayne Wissler
A metaphor is very loose comparison, usually used when describing something
totally new in terms of something commonly known. Ron Jeffries pointed this
out: you could think of part of a system as "delivering the mail." This has
nothing to do with the system in particular. Think about how you would
describe a complex software system to your mother (assuming she's not a
programmer). You have to put it into her terms. Is she going to understand
the system? No, of course not. She'll get a woozy approximation that will be
useless in terms of her being able practically deal with the system, but on
the other hand, she'll have some kind of idea of what you do.
[OT: Metaphors are properly and sparingly used as communication tools, but I
think it's a bad idea to have it central to a methodology.]
A style is a particular mode of expression. We need one in order to decide
how to select the optional units of the architecture. Where there are
technical options (things that could be done N ways, with no particular way
being better or worse than the others), we need a means of picking. A style
tells us what to pick when faced with alternatives. It makes the system more
comprehensible, by limiting the number of variations. (Well, you could have
a pragmatic style, which is really the antithesis of style).
Shayne Wissler
"Giovanni Asproni" <as...@ebi.ac.uk> wrote in message
news:3CCFC937...@ebi.ac.uk...
Phlip
> [OT: Metaphors are properly and sparingly used as communication tools, but
I
> think it's a bad idea to have it central to a methodology.]
Hi Shayne.
The intent is to provide a common source for all the jargon & identifiers on
a project. Otherwise the jargon will diverge due to diversity. This is as
healthy a Best Practice as having a style guide.
--
Phlip
Michael Feathers
"Giovanni Asproni" <as...@ebi.ac.uk> wrote
> Maybe my first mail was not clear about the distinction about
"Architecture"
> and "Architectural Style" so I'll try to clarify it.
>
> In the first mail I talked about "Architectural Style", not about
> "Architecture". They are different things.
>
> An "Architectural Style" is nothing but a Pattern from which many concrete
> architectures can be derived. So it gives also a vocabulary that can be
used to
> develop an "Architecture".
It seems like it might be good to look back and how Shaw & Garlan use the
term "architectural style":
Here is their working list. Systems can have a few coordinating
architectural styles:
Dataflow Systems
Batch Sequential
Pipes and Filters
Call-and-return systems
Main program and subroutines
OO systems
Hierarchical Layers
Independent Components
Communicating processes
Event systems
Virtual Machines
Interpreters
Rule-based systems
Data-centered systems (repositories)
Databases
Hypertext systems
Blackboards
Michael Feathers
www.objectmentor.com
Michael Feathers
with
> "Architectural Style" just before reading your reply.
>
> I've read also your reply to Tokomar, in particular your phrase:
>
> "Well, only sort of. The metaphor only makes sense if the parts go in bins
and
> the bins associate with stations and the stations are in an assembly line.
So
> the structure of any system built on that metaphor will likely have the
bins be
> some kind of container, the stations "having" some bins, and so on. Thus
the
> metaphor pins down a kind of "top level" architecture."
>
> makes me feel that "Architectural Style" and metaphor have quite a strong
relation.
They don't map exactly but they are ideas at the same level.
Michael Feathers
www.objectmentor.com
Ron Jeffries
I don't think I said they were orthogonal.
Universe
> Metaphor and style are two totally different things.
> A metaphor is very loose comparison, usually used when describing something
> totally new in terms of something commonly known. Ron Jeffries pointed this
> out: you could think of part of a system as "delivering the mail." This has
> nothing to do with the system in particular.
a) how would any analogy/metaphor be at all fruitful if it "has nothing to
do with the system in particular"?!
Why even make such an analogy/metaphor?
> Think about how you would
> describe a complex software system to your mother (assuming she's not a
> programmer). You have to put it into her terms.
But I want to put it in terms that though low level and very abstract
would in fact help her to get the description.
> Is she going to understand
> the system? No, of course not.
Why bother then?
> She'll get a woozy approximation that will be
> useless in terms of her being able practically deal with the system, but on
> the other hand, she'll have some kind of idea of what you do.
Not understanding and having an approximation, even woozy, can be 2 very
different things. An approximation may in fact convey a description that
is essentially correct for whatever aspect of the system is being
described.
> [OT: Metaphors are properly and sparingly used as communication tools, but I
> think it's a bad idea to have it central to a methodology.]
I don't see a problem if in fact rather then having "nothing" to do with
the system, the metaphor *does* indeed have something to with constructing
and or understanding the system.
> A style is a particular mode of expression.
"A style"? If Wissler is referring to a metaphor and or analogy and it
*does* have something to do with constructing and or understanding a
system, then it's more than simply a "mode of expression". It is
referencing an objectively real thing, or things. It's not like we may
use *any* "mode of expression" and still be making a system specific
fruitful statement.
> We need one in order to decide
> how to select the optional units of the architecture.
"Select"? This is a backward move in now using an analogy/metaphor to
"select" as distinct from describing - to build, or understand - a system.
And certainly, any truly analogy/metaphor that does help description and
understanding the system in question, may very well be applied to
optional *AND* required architectural units/aspects/parts/relationships,
etc.
> Where there are
> technical options (things that could be done N ways, with no particular way
> being better or worse than the others)
FALSE. Because something is optional, that in NO WAY IMPLIES, "no
particular way being better or worse than others." This is
pragmatism/empiricism, expressed by Wissler who often makes both 1)
empiricist AND 2) dogmatic remarks.
I.e. 1) empiricism/pragmatism: over reliance on practice versus theory,
especially of a limited circle and 2) dogmatism: over reliance on theory
versus practice, especially of a limited circle. Both fail to apply the
scientific maxim: "theory leads, practice validates".
And in fact those who generally adhere to one or anther of the 2 poles of
falsehood frequently say things that jibe more with the other pole. It's
the nature of the subjectivism and overall, inherent error endemic to, and
uniting both poles of falsehood.
So for example, xp/om/sd mag/alliance types - RCM, Jeffries, Zeigler,
Ambler, Cockburn, Feathers, Phlip, etc. - whom are mainly
pragmatists/empiricists often make dogmatic comments. Check it out over
time.
> Where there are
> technical options (things that could be done N ways, with no particular way
> being better or worse than the others), we need a means of picking. A style
> tells us what to pick when faced with alternatives. It makes the system more
> comprehensible, by limiting the number of variations. (Well, you could have
> a pragmatic style, which is really the antithesis of style).
As a matter of fact, Wissler overall makes about an equal number of both
dogmatic and empirio-pragmatic statements.
Here Wissler *combines* empiricism/pragmatism with dogmatism. Pragmatic
do whatever works: his claim that all options are equal because they are
options - which we know stinks. Then dogmatism: the best way to chose is
not by contextual facts, but rather theoretically by what he asserts is
comprehensible, for whom one can only guess are the largest number of
software engineers.
Elliott
--
Science: Theory leads - Practice validates
Universe
Unfortunately it is important to note that xp use of both terms -
architecture; metaphor - in a major way errantly differs from what the
plurality of software engineers understand by "architecture".
And that concept of system architecture is a schema of system stuctural
units and relationships that address all major scope specified use case,
performance, construction, robustness, configuration, maintenance, and if
applicable scalableness, and enhancement issues.
Local architecture is the same locally - per subsystem, module, class,
package, etc.
Elliott
Universe
> On Tue, 30 Apr 2002 16:04:52 +0100, Giovanni Asproni <as...@ebi.ac.uk> wrote:
>>So I have this question: is the "metaphor" used in XP is another name
>>for the "more evocative" (I can't find a better term) 'architectural
>>style' that describes a system, that is the view that better describes
>>how the system will satisfy the user requirements?
> Metaphor is definitely not well-described in XP. Maybe someday we'll figure out
> what we meant.
> At its simplest, Metaphor refers to a consistent "system of names" (See Ward
> Cunningham's patter of that name) that are used for the objects in the system.
> With a good set of consistent names throughout the system, programmers can
> quickly "guess" where to look in the code to find what they need.
Readers please note that a "consistent 'system of names' in no way means
that an overall, structural system design blueprint addressing all key
aspects of the system has been formulated, much less mandated in code and
local design. Jeffries is not claiming that xp 'system of names' means
this, but let's be clear on it.
> With some systems we have been able to come up with mataphors that are more than
> just consistent: they are vivid and evocative descriptions of how the system
> works. See my reply to Tokamar below for more commentary on C3's assembly line
> metaphor.
A tad dishonest, is it not (n'est ce pas)?
One would not know by the reference that the aborted xp chrysler project
intended to build a payroll system.
> Metaphors can be very simple, and are probably best when they are simple. We
> might describe our system as "like the postal service -- the mailman comes
> around and picks up and delivers mail", or "like an ant colony -- all the ants
> go out and pick up interesting food and bring it back to the colony", or "like a
> uni-line at the bank -- the next available server takes care of the next task".
> I'm sure Beck had something in mind when he wrote about metaphor, and I've seen
> it work. At this point in the books, we haven't said much useful. Maybe someday
> ...
Opposed to the above, this is commendable candor.
>>If the answer to the previous question is yes, does the refactoring
>>process keep this 'architectural style' fixed during all the
>>development, or also this is subject to some form of refactoring?
> Refactoring can change anything in the implementation, so I would suppose it can
> change "architectural style" if you want it to.
And above all not forgetting that xp system metaphor <> commonly
understood system architecture, contrary both to the query as well as the
lack of candor in Jeffries' answer.
> I haven't read the books you
> refer to, however, so I'm only basing that on the fact that refactoring can
> change whatever you want it to.
VERY important to the whole point, and definition of refactoring,
EXCEPT that the fact that use case fulfillment must remain - not how, but
what is fulfilled.
This distinguishes refactoring from the broad purview allowed 'edit' in
the ubiquitous and widely used expression: "the edit-debug-compile
cycle".
Universe
> On Wed, 01 May 2002 15:40:44 GMT, Tokomar <n...@spam.com> wrote:
>>> Well, only sort of. The metaphor only makes sense if the parts go in bins
>>> and the bins associate with stations and the stations are in an assembly
>>> line. So the structure of any system built on that metaphor will likely
>>> have the bins be some kind of container, the stations "having" some bins,
>>> and so on. Thus the metaphor pins down a kind of "top level" architecture.
>>>
>>> How those ideas are implemented is of course open.
>>
>>Consider a fairly junior team instructed today they must hunt the metaphor
>>for their new system. If you tell them the above, out of context, they
>>might think you said, "You must architect your system right now based on
>>the aphorism you carry home for it."
>>
>>Don't tell them that, if architecture and metaphor are to be orthogonal.
> I don't think I said they were orthogonal.
You said the most understood connation for xp system metaphor was 'a
system of names' and nowhere in that same article did you say it
definitely referred to, or included, system architectural
blueprints/model(s): I.e a system or local structural design plan
determined in its essentials before the bulk or heart of project coding
and overall implementation. This architectural plan "solves"
("solutes") at least all key use case & technical aspects, and
subordinates to itself all coding and other system implementation.
xp adherents since xp arose 2-3 years ago have to say the least*
"vigorously" opposed both:
i) pre bulk/heart of coding/implementation overall system design
formulation
ii) subordination of all coding and other system implementation to
point 'i)' architecture - though iteratively modified or even
superceded in one or more iterations with another overall
architectural plan
* [some even criminally cr(h)acking one of my boxes to make the point]
Elliott
--
"The Cheney bone connected to the Enron bone" ~ Oliphant
-or-
The Cheney boon connected to the Enron boom!
Down with Monopoly Piro-terrorism!
David Van Camp
> Maybe my first mail was not clear about the distinction about
"Architecture"
> and "Architectural Style" so I'll try to clarify it.
No, your question seemed quite clear to me. And, I am familiar with your
references. They are not metaphores, generally. Read my article. I explains
what a metaphor is.
David Van Camp
-- end of transmision --
David Van Camp
"Phlip" <phli...@my-deja.com> wrote in message
news:InUz8.785$QJ.461...@newssvr14.news.prodigy.com...
Only if the metaphor maps well to the problem domain. I've seen too many
times where inexperienced designers tried to map a bad metaphor that seemed
good. It takes a *lot* of practice and experience and understanding to make
this work.
I've worked with UI design for years & commercial art before that. Both
often use metaphor, but it is a very sharp double edged sword. It can
perform miracles of enlightenment or it can stifle creative problem solving.
And, worse, it can actually to both at the same time without the negative
effects being obvious!
David Van Camp
> I've sent a reply to David Van Camp that tries to clarify what I meant
with
> "Architectural Style" just before reading your reply.
>
> I've read also your reply to Tokomar, in particular your phrase:
>
> "Well, only sort of. The metaphor only makes sense if the parts go in bins
and
> the bins associate with stations and the stations are in an assembly line.
So
> the structure of any system built on that metaphor will likely have the
bins be
> some kind of container, the stations "having" some bins, and so on. Thus
the
> metaphor pins down a kind of "top level" architecture."
>
> makes me feel that "Architectural Style" and metaphor have quite a strong
relation.
>
system -- that is both its power and its danger. A metaphor is a concept
that is readily understood by most people that is used to hide the
complexities of a lesser-understood concept. It can enlighten, but it can
also mislead.
Metaphors are not easy things to nail down. When we look at the Windows and
Desktops and various other GUI features on our computers, we a looking at
metaphors. They worked -- the persistence of these concepts proves their
success. But, how many other metaphorical concepts have been tried that
failed because, although easy to understand, they simply didn't provide the
right degree of mapping to the problem?
Have you seen any of the many "interfaces of the future" that went nowhere?
How about those applications that took the desktop metaphor to the
extreme -- a picture of a desktop with a picture of a file cabinet and, etc,
etc. Where are they today? Gone -- they tried to make to literal the
implementation of the metaphor. The let the metaphor drive the architecture.
Wrong direction!
Be careful with metaphors. They can be wonderful, project saving tools. Or
they can be monsters hiding in the closet while you sleep.
Good night (shall I turn the nightlight on for you?)
:-)
Phlip
>> The intent is to provide a common source for all the jargon & identifiers
> on
>> a project. Otherwise the jargon will diverge due to diversity. This is as
>> healthy a Best Practice as having a style guide.
>
> Only if the metaphor maps well to the problem domain. I've seen too many
> times where inexperienced designers tried to map a bad metaphor that
> seemed good. It takes a *lot* of practice and experience and understanding
> to make this work.
I like, "A tyrannosaur stalking and eating an apatosaur." The fact these
critters lived eons apart from each other is irrelevant.
--
Phlip
Shayne Wissler
"Phlip" <phli...@my-deja.com> wrote in message
news:InUz8.785$QJ.461...@newssvr14.news.prodigy.com...
Hi Philip.
I wouldn't call it a "best practice." It's too inconsequential.
There's nothing necessarily wrong with using a metaphor for selecting
jargon. On the other hand, too many people stop with the woozy "well, it's
kinda like this", "know what I mean", "you gotta sorta do something like
this"--being woozy is fine up front, but somewhere along the line things
have to become sharp and clear. Metaphors often get in the way. Or: they
make it easier to pretend like you know what you're talking about, even
though you have no clue.
Shayne Wissler
Phlip
> I wouldn't call it a "best practice." It's too inconsequential.
One consequence is no more classes called "Manager", "Task" or "System".
> There's nothing necessarily wrong with using a metaphor for selecting
> jargon. On the other hand, too many people stop with the woozy "well, it's
> kinda like this", "know what I mean", "you gotta sorta do something like
> this"--being woozy is fine up front, but somewhere along the line things
> have to become sharp and clear. Metaphors often get in the way. Or: they
> make it easier to pretend like you know what you're talking about, even
> though you have no clue.
That's why I like, "A tyrannosaur stalking and eating an apatosaur." It's
so completely woozy and unclear that nobody could ever mistake it for an
attempt to describe a program.
--
Phlip
Shayne Wissler
"Phlip" <phli...@yahoo.com> wrote in message
news:aarfs8$7...@dispatch.concentric.net...
> Shayne Wissler wrote:
>
> > I wouldn't call it a "best practice." It's too inconsequential.
>
> One consequence is no more classes called "Manager", "Task" or "System".
Trite architectures call for trite terminology. No use in being all dressed
up when you have no place to go.
What are some common words we'd find in your own software, that typify your
use of metaphor?
Shayne Wissler
Phlip
> What are some common words we'd find in your own software, that typify
> your use of metaphor?
In Flea, the metaphor is an Egg full of Chromosomes that grows into a
life form.
povray.setMaterial( 1,
'texture { Copper_Metal scale 300 }' )
egg = startOvum (18, 45, 100)
ax = egg.newRootAxiom ('A')
b = egg.newAxiom ('B')
ax.longer(6).right.color(1).gosub(b)
b.tube.shorter(0.8).left.link(b)
render egg
That draws a shiny copper spiral:
http://flea.sourceforge.net/link_example.png
But I called the Chromosomes "Axioms" for legacy reasons. I may change
that. Axioms contain "turtle graphics", which is a common metaphor too.
At my day gig the metaphor is a secret.
--
Phlip
Giovanni Asproni
of its usage and I agree with what you wrote in your mail.
My problem is not to decide if to use a metaphor or not to develop my programs,
I just want to understand if the XP usage of the metaphor is something related
or not with an architectural style.
I had a look at the www.xprogramming.com site and found this definition of
metaphor:
"Extreme Programming teams develop a common vision of how the program works,
which we call the "metaphor". At its best, the metaphor is a
simple evocative description of how the program works, such as "this program
works like a hive of bees, going out for pollen and bringing it back to the
hive" as a description for an agent-based information retrieval system.
Sometimes a sufficiently poetic metaphor does not arise. In any case, with or
without vivid imagery, XP teams use a common system of names to be
sure that everyone understands how the system works and where to look to find
the functionality you're looking for, or to find the right place to put the
functionality you're about to add."
From that definition it seems to me that in XP the metaphor has quite a strong
influence in the architecture of the system. This is the reason why I feel that
the XP metaphor has a strong relation with the definition of architectural
style.
Giovanni.
P.S. Up to now I've been careful enough to avoid monsters in the closet or
everywhere else, so I can usually sleep quite well :)
Ron Jeffries
>My problem is not to decide if to use a metaphor or not to develop my programs,
>I just want to understand if the XP usage of the metaphor is something related
>or not with an architectural style.
If my reply under this topic wasn't helpful, please ask some more questions and
I'll try to do better.
Brian Denny
> A chosen metaphor will undoubtedly influence the architecture of the
> system -- that is both its power and its danger. A metaphor is a concept
[snip]
> Metaphors are not easy things to nail down. When we look at the Windows
and
[snip]
> right degree of mapping to the problem?
as a student of cognitive science, i'd like to relate this topic to the
topic of Metaphor in cognitive linguistics.
I highly suggest to *anyone* doing any sort of modeling that you read
"Metaphors We Live By" (Lakoff and Johnson) if you haven't already.
Briefly, what L&J call metaphor or "conceptual metaphor" is understood to be
a mapping from source domain to target domain. This mapping can usually be
seen in various linguistic examples.
For example: "I'm on top of the situation." This is an example of
conceptual metaphor because (1) I am not literally "on top" of anything, and
(2) I can find other, different, linguistic examples which imply the same
mapping, such as "I'm voting for the underdog...". In both examples there
is an implicit mapping from the domain of physical position to the domain of
control. L&J uses names like "control is up" (target IS source) to refer
to these metaphors.
The interesting thing about these metaphors is that it is not just a few
special linguistic usages that are mapped. The *inferential structure* of
the target domain is, to varying degrees, mapped on to the target domain.
So if I tell you that "we're at a crossroads in our relationship", you might
infer that we are in danger of having to "go our separate ways".
The more inferential structure you can map, the better the metaphor "fits".
Conceptual metaphor is one of the primary ways that we (humans) understand
complex domains. It seems like this could be true for software, too.
But why should we make up new metaphors for our software? Why not use the
existing language/structure/metaphors of the domain we are trying to model?
I don't entirely know, and i'm far from an OO expert. But my hunch is this:
at a certain level, using the existing metaphors of the user domain makes
sense. But then at some other level, the requirements of the computer may
not map in an obvious way onto the structure of the user domain. "Creating
a metaphor" in these circumstances is, in my view, the same mental process
as we use to find coherent ways of talking about any truly novel ideas that
we come up with.
(digression #1: ever have a bunch of vague thoughts, but you can't figure
out how to talk about them coherently, and then one day you come up with an
idea/model/metaphor that makes it all make sense?... digression #2: this
process happens in science too... quantum physics is so counterintuitive
because we haven't found a *single* metaphor that maps well to our empirical
observations, so we have "wavicles", which is the result of having two
not-quite-adequate mappings which together do the job.)
But coming up with new metaphors is *hard*. *Really* hard. ("wavicle" as
case in point!) Especially if they're going to map really well. And if
they don't map well, they will lead you to make inferences which don't hold
up to reality. I think that this is why metaphor is the hardest part of XP
to understand (and even hard to apply).
My hunch about the original poster's question is that metaphor influences
your design, at whatever level/grain-size you are talking about. The
metaphor you choose carries with it a conceptual structuring of the domain.
If it's a good metaphor (and, unfortunately, maybe even if it isn't), you
will be reasoning about the domain in terms of it. Therefore the conceptual
structuring implied by the metaphor will show up in your design whether
you're doing emergent design or up-front design. Good metaphors, if you can
come up with them, will help you create good designs. Bad metaphors will
help you create bad designs.
Or so is my thinking on the matter. I probably have more background in
cognitive linguistics than in OOA&D, so everything I've said here is based
on theory as opposed to programming experience. Hopefully i've said
something that other folks will find interesting.
-brian
Shayne Wissler
"Brian Denny" <br...@dlworkshop.net> wrote in message
news:GsiA8.8172$MR1.1...@news.webusenet.com...
> Conceptual metaphor is one of the primary ways that we (humans) understand
> complex domains. It seems like this could be true for software, too.
Only the disinterested and the mentally lazy attempt to understand something
primarily via metaphor.
Metaphor is only advised as a very early and optional step in the pursuit of
actual knowledge, and should be dispensed with early, as specifics of the
actual existent under consideration are gained.
A metaphor is a shoddy frame, and if it is not torn down, it shackles the
budding idea, preventing it from ever flying. Particularly if the metaphor
is mixed ;)
Shayne Wissler
Universe
Are you...? Nawwhhh....
>> A chosen metaphor will undoubtedly influence the architecture of the
>> system -- that is both its power and its danger. A metaphor is a concept
>> ...
>> Metaphors are not easy things to nail down. When we look at the Windows
>> and...right degree of mapping to the problem?
> as a student of cognitive science, i'd like to relate this topic to the
> topic of Metaphor in cognitive linguistics.
> I highly suggest to *anyone* doing any sort of modeling that you read
> "Metaphors We Live By" (Lakoff and Johnson) if you haven't already.
> Briefly, what L&J call metaphor or "conceptual metaphor" is understood to be
> a mapping from source domain to target domain. This mapping can usually be
> seen in various linguistic examples.
> For example: "I'm on top of the situation." This is an example of
> conceptual metaphor...there is an implicit mapping from the
> domain of physical position to the domain of control....
> But why should we make up new metaphors for our software? Why not use the
> existing language/structure/metaphors of the domain we are trying to model?
Amen to that regarding the high level use case domain/interface/controller
class/object model.
> I don't entirely know, and i'm far from an OO expert. But my hunch is this:
> at a certain level, using the existing metaphors of the user domain makes
> sense.
Yes.
> But then at some other level, the requirements of the computer may
> not map in an obvious way onto the structure of the user domain.
I can't imagine why requirements would not map naturally to the level and
scope of abstraction of the domain they are embedded in.
As I see it, it's the *overall* and mediated, non-directly requirement
related structures, and architecture components where non-domain
model metaphors would be useful.
But it's true for BOTH domain specific and mediated system structure
metaphor and vocabulary where:
> "Creating a metaphor"...the same mental process...we use to find
> coherent ways of talking about any truly novel ideas that we come up
> with.
Again true for both:
1) the requirements (use case)+domain model
-and-
2) designs meant to make the use case+domain model happen
> (digression #1: ever have a bunch of vague thoughts, but you can't figure
> out how to talk about them coherently, and then one day you come up with an
> idea/model/metaphor that makes it all make sense?...
Yes, the clear value of APT metaphor.
> digression #2: this
> process happens in science too... quantum physics is so counterintuitive
> because we haven't found a *single* metaphor that maps well to our empirical
> observations, so we have "wavicles", which is the result of having two
> not-quite-adequate mappings which together do the job.)
I don't think quantum mechanics counterintuitiveness is mainly due to not
finding a metaphor, but the how its basic character contradicts the
classical mechanics that we soley observe and experience face to face, day
after day, year in year out.
> ...
> Or so is my thinking on the matter. I probably have more background in
> cognitive linguistics than in OOA&D, so everything I've said here is based
> on theory as opposed to programming experience. Hopefully i've said
> something that other folks will find interesting.
Yes, yes.
But remember that cognitive linguistics is a science with *practice* as
well as theory. Just as OOA&D is a science and engineering discipline
with *theory* as well as practice. Don't let the xp'ers, etc mislead you.
Elliott
Brian Denny
"Shayne Wissler" <thal...@yahoo.com> wrote in message
news:O7jA8.217628$CH1.143667@sccrnsc02...
>
> > Conceptual metaphor is one of the primary ways that we (humans)
understand
> > complex domains. It seems like this could be true for software, too.
>
> Only the disinterested and the mentally lazy attempt to understand
something
> primarily via metaphor.
>
> Metaphor is only advised as a very early and optional step in the pursuit
of
> actual knowledge, and should be dispensed with early, as specifics of the
> actual existent under consideration are gained.
The words/phrases "via", "step", and "pursuit" in the above text provide
great examples of thinking via metaphor.
The point made by cognitive linguists such as Lakoff is that metaphors
aren't just for loose, artistic speech. We use them all the time,
unconsciously. Some of them are so engrained they seem literal until we
think about them.
You might argue that if you are trying to understand something deeply, you
had best try to understand it literally. But I'll bet you can't find me a
page of explanation of any reasonably complex or abstract domain that
doesn't contain several examples of metaphorical thinking.
> A metaphor is a shoddy frame, and if it is not torn down, it shackles the
> budding idea, preventing it from ever flying. Particularly if the metaphor
> is mixed ;)
Cute.... The above paragraph contradicts itself insofar as it makes sense.
-brian
Shayne Wissler
>
> "Shayne Wissler" <thal...@yahoo.com> wrote in message
> news:O7jA8.217628$CH1.143667@sccrnsc02...
>
> >
> > > Conceptual metaphor is one of the primary ways that we (humans)
> understand
> > > complex domains. It seems like this could be true for software, too.
> >
> > Only the disinterested and the mentally lazy attempt to understand
> something
> > primarily via metaphor.
> >
> > Metaphor is only advised as a very early and optional step in the
pursuit
> of
> > actual knowledge, and should be dispensed with early, as specifics of
the
> > actual existent under consideration are gained.
>
> The words/phrases "via", "step", and "pursuit" in the above text provide
> great examples of thinking via metaphor.
There is such a thing as a term that started out as metaphorical, and
evolved into a self-sufficient term (there's actually a name for such terms,
but I forget at the moment). The words "via", "step", and "pursuit" are not
at all metaphorical in in certain contexts; they are self-sufficient
abstractions. You know this because the terms can be defined in the
appropriate sense without reference to the metaphorical context. Check out
the OED.
Hmmm. I think they're called "dead" metaphors. Half-dead metaphors are words
in transition, and you have to be careful with them as they can come "alive"
in certain contexts and destroy the thought (or make your audience laugh at
you). I.e., normally the meaning is non-metaphorical, but if you include the
word in a certain thought, it all of the sudden appears metaphorical.
> The point made by cognitive linguists such as Lakoff is that metaphors
> aren't just for loose, artistic speech. We use them all the time,
> unconsciously. Some of them are so engrained they seem literal until we
> think about them.
>
> You might argue that if you are trying to understand something deeply, you
> had best try to understand it literally. But I'll bet you can't find me a
> page of explanation of any reasonably complex or abstract domain that
> doesn't contain several examples of metaphorical thinking.
If you're going to include terms that used to be metaphorical, then you're
right. But such terms are not in fact metaphorical.
> > A metaphor is a shoddy frame, and if it is not torn down, it shackles
the
> > budding idea, preventing it from ever flying. Particularly if the
metaphor
> > is mixed ;)
>
>
> Cute.... The above paragraph contradicts itself insofar as it makes
sense.
Intended, of course.
Shayne Wissler
Shayne Wissler
> Hmmm. I think they're called "dead" metaphors. Half-dead metaphors are
words
> in transition, and you have to be careful with them as they can come
"alive"
> in certain contexts and destroy the thought (or make your audience laugh
at
> you). I.e., normally the meaning is non-metaphorical, but if you include
the
> word in a certain thought, it all of the sudden appears metaphorical.
OK, my memory's working now.
A half-dead metaphor is a word that can have the original meaning or
different meaning, depending on the context. "Step" is a good example.
A dead metaphor is a word that originally was derived from a metaphor, but
where the original meaning has completely been dropped. I can't think of a
good example off the top, but you can tell by looking through the OED (OK,
memory's not totally working yet).
This is actually a very relevant topic to the philosophy of programming
languages. One of the worst errors in modern computer science is the lack of
realizing that a computer language is not, in fact, a language, not in the
original sense of language. Natural language and computer languages are not
types of languages; they are completely different things. The kind of
parsing that humans do when they read/listen is not at all similar to the
kind of "parsing" (original term was metaphorical, as in "I can't parse what
you're saying.") that computers do.
Another metaphor is the concept of computer itself. To compute, in its
original sense, is a human operation, an operation of consciousness. The
computers actually do not compute at all in the literal, original
sense--they are not conscious. All they are is wires and semiconductors,
switching states, fundamentally no different than any machine. If a computer
literally computes 2 times 2, then a car's piston "computes" the difference
between the cam's upper and lower position. But the whole AI field is
founded on this bogus metaphor that isn't understood as the metaphor that it
is.
Metaphor is indeed a very poorly understood concept in computer science.
Shayne Wissler
Giovanni Asproni
I've started this thread after I read the books cited in my first mail because I
realized that, when I start to work on a new system, The first thing I tend to do
is to choose an 'architectural style' (maybe after some prototyping or some
exploratory design) and stick with it.
Then I realized that a 'metaphor', as defined and used by XP, is central to the
architecture of the final system, so I wanted to have more opinions about the
relations between the 'metaphor' concept (as defined by XP) and 'architectural
style' concept.
At the end I agreed with what Michael Feather wrote in one mail in this thread
"They don't map exactly but they are ideas at the same level". I think that their
main relation is the fact that, at the end, they have a major influence on the
architecture of the system.
Some time ago I had the opportunity to experiment XP during the development of a
pilot project for a product for telecom companies. A friend of mine and I were the
coaches (we were the most expert programmers in the team), it was an interesting
and rewarding experience (and the developed system was quite good indeed).
In that case we didn't use the 'metaphor' "to find the right place to put the
functionality you're about to add" (as stated in the www.xprogramming.com web
site), instead we designed a very high level outline of the architecture (so we
chose an architectural style) and used metaphors just to clarify issues during
discussions, not to drive the architecture. In my experience this worked quite
well.
Giovanni
Universe
> In that case we didn't use the 'metaphor' "to find the right place to put the
> functionality you're about to add" (as stated in the www.xprogramming.com web
> site), instead we designed a very high level outline of the architecture (so we
> chose an architectural style) and used metaphors just to clarify issues during
> discussions, not to drive the architecture. In my experience this worked quite
> well.
Science wins some and loses others.
Welcome to the slippery slope of the hackerist world view:
empirio-pragmatism, aka craftistry.
Elliott
Universe
> Science wins some and loses others.
> Welcome to the slippery slope of the hackerist world view:
> empirio-pragmatism, aka craftistry.
Whoops! I'm being heavy handed.
Though undoubtably a metaphor may be used with efficacy to "drive" the
enforced design of the domain model, as well as to effectively drive the
enforced overall technical structure the domain model is embedded within,
that does not mean any and all metaphors of necessity are required to play
such a role.
But given the tone and bent of your comments, here's a word the wise:
"caveat emptor" regarding "in eXtremis Programming".
Elliott
Phlip
> Science wins some and loses others.
>
> Welcome to the slippery slope of the hackerist world view:
> empirio-pragmatism, aka craftistry.
Social realism and neocultural socialism
T. Martin Dietrich
Department of Gender Politics, University of California,
Berkeley Charles Tilton
Department of Sociolinguistics, Yale University
1. Realities of failure
The characteristic theme of Long's[1] critique of dialectic narrative is
the paradigm, and eventually the collapse, of subconceptualist culture.
The subject is interpolated into a social realism that includes
consciousness as a totality.
"Society is intrinsically responsible for the status quo," says Debord;
however, according to Pickett[2] , it is not so much society that is
intrinsically responsible for the status quo, but rather the defining
characteristic, and subsequent fatal flaw, of society. But the main theme
of the works of Gibson is not theory, as dialectic narrative suggests,
but posttheory. Sartre's essay on social realism suggests that sexual
identity, perhaps paradoxically, has significance.
However, Sontag uses the term 'predialectic semanticist theory' to denote
the role of the poet as writer. Hamburger[3] holds that we have to choose
between neocultural socialism and precultural discourse.
Therefore, a number of theories concerning dialectic narrative may be
revealed. The primary theme of Dietrich's[4] model of neocultural
socialism is the difference between society and sexual identity.
Thus, any number of discourses concerning the role of the observer as
artist exist. Dialectic narrative suggests that the Constitution is part
of the absurdity of narrativity. 2. Neocultural socialism and Lacanist
obscurity
"Class is fundamentally a legal fiction," says Sartre. But Bataille uses
the term 'social realism' to denote the bridge between sexual identity
and society. Marx's analysis of neocultural socialism states that
language has objective value.
In the works of Gibson, a predominant concept is the concept of
materialist sexuality. Thus, Sartre uses the term 'Lacanist obscurity' to
denote the rubicon, and hence the economy, of subsemiotic class. If
neocultural socialism holds, we have to choose between Lacanist obscurity
and the cultural paradigm of consensus.
The characteristic theme of the works of Gibson is a self-fulfilling
paradox. However, the subject is contextualised into a neocultural
socialism that includes culture as a reality. An abundance of
materialisms concerning social realism may be discovered.
If one examines postdialectic socialism, one is faced with a choice:
either accept Lacanist obscurity or conclude that sexuality may be used
to disempower the proletariat, but only if social realism is invalid;
otherwise, art is capable of truth. Therefore, the main theme of
Tilton's[5] essay on neocultural socialism is the role of the observer as
participant. The premise of social realism suggests that expression comes
from the collective unconscious.
"Class is used in the service of capitalism," says Lacan. However,
Hanfkopf[6] states that the works of Madonna are postmodern. The primary
theme of the works of Madonna is not theory, but pretheory.
The characteristic theme of Pickett's[7] model of capitalist narrative is
the role of the reader as writer. But Marx suggests the use of
neocultural socialism to deconstruct the status quo. Sontag uses the term
'Lacanist obscurity' to denote the common ground between society and
class.
In a sense, Marx's analysis of social realism suggests that the media is
capable of intent. If neocultural socialism holds, we have to choose
between social realism and premodernist nationalism.
Therefore, in Black Orchid, Gaiman affirms capitalist neodeconstructivist
theory; in Neverwhere, although, he denies neocultural socialism. The
subject is interpolated into a social realism that includes sexuality as
a totality.
It could be said that many constructions concerning a constructive
reality exist. Sartre uses the term 'neocultural socialism' to denote the
futility, and eventually the fatal flaw, of subcultural society.
Therefore, la Fournier[8] states that we have to choose between Lacanist
obscurity and the semioticist paradigm of context. The primary theme of
the works of Gibson is not discourse, as Derrida would have it, but
prediscourse.
It could be said that any number of dematerialisms concerning social
realism may be revealed. If neocultural socialism holds, we have to
choose between social realism and neocultural textual theory.
But the subject is contextualised into a predialectic paradigm of
narrative that includes narrativity as a paradox. Sontag promotes the use
of social realism to modify class.
Therefore, an abundance of theories concerning the defining
characteristic, and some would say the futility, of cultural sexual
identity exist. Derrida suggests the use of Lacanist obscurity to
challenge hierarchy. 3. Gibson and neocultural socialism
"Sexuality is part of the economy of culture," says Baudrillard; however,
according to Prinn[9] , it is not so much sexuality that is part of the
economy of culture, but rather the dialectic, and eventually the rubicon,
of sexuality. Thus, the without/within distinction intrinsic to Gibson's
Virtual Light emerges again in Neuromancer, although in a more
self-falsifying sense. The main theme of Tilton's[10] critique of
subconstructive narrative is not, in fact, discourse, but postdiscourse.
"Society is intrinsically dead," says Sartre. It could be said that
several theories concerning Lacanist obscurity may be discovered. In
Virtual Light, Gibson analyses the textual paradigm of context; in All
Tomorrow's Parties he examines social realism.
"Narrativity is impossible," says Foucault; however, according to
Bailey[11] , it is not so much narrativity that is impossible, but rather
the stasis of narrativity. However, any number of discourses concerning
the role of the observer as artist exist. The characteristic theme of the
works of Gibson is the collapse, and some would say the failure, of
prestructuralist class.
In the works of Gibson, a predominant concept is the distinction between
opening and closing. It could be said that Lacan promotes the use of the
textual paradigm of narrative to analyse and deconstruct society. The
premise of social realism implies that truth serves to reinforce the
status quo, but only if language is interchangeable with culture; if that
is not the case, Sontag's model of neocultural socialism is one of
"postcapitalist constructive theory", and therefore part of the stasis of
language.
In a sense, Buxton[12] holds that we have to choose between Sartreist
existentialism and the subtextual paradigm of expression. Derrida's model
of Lacanist obscurity states that class, somewhat ironically, has
significance.
However, Lacan uses the term 'social realism' to denote a mythopoetical
reality. The primary theme of Drucker's[13] critique of neocultural
socialism is the role of the writer as observer. It could be said that
the subject is interpolated into a Lacanist obscurity that includes
sexuality as a totality. Several theories concerning neocultural
socialism may be revealed.
Therefore, Marx uses the term 'social realism' to denote not discourse,
as Lacanist obscurity suggests, but neodiscourse. If neocultural
socialism holds, we have to choose between cultural narrative and
posttextual material theory.
Thus, the premise of neocultural socialism implies that consensus is
created by communication, given that social realism is valid. The subject
is contextualised into a Lacanist obscurity that includes reality as a
whole.
Therefore, Sargeant[14] holds that we have to choose between social
realism and subtextual nationalism. A number of theories concerning the
difference between sexual identity and art exist. 1. Long, C. (1999)
Deconstructing Surrealism: Neocultural socialism in the works of Gibson.
University of Georgia Press
2. Pickett, W. N. T. ed. (1974) Neocultural socialism and social
realism. Loompanics
3. Hamburger, R. (1985) Neotextual Deappropriations: Nihilism, social
realism and capitalist objectivism. University of North Carolina Press
4. Dietrich, O. Q. ed. (1999) Social realism in the works of Tarantino.
University of California Press
5. Tilton, P. B. D. (1984) The Rubicon of Society: Social realism in the
works of Madonna. And/Or Press
6. Hanfkopf, S. ed. (1991) Capitalist narrative, nihilism and social
realism. Loompanics
7. Pickett, G. N. (1987) Subtextual Discourses: Social realism in the
works of Gaiman. Schlangekraft
8. la Fournier, U. E. F. ed. (1973) Neocultural socialism in the works of
Gibson. Harvard University Press
9. Prinn, N. D. (1992) The Forgotten Sky: Social realism and neocultural
socialism. University of Massachusetts Press
10. Tilton, H. ed. (1981) Social realism in the works of Mapplethorpe.
And/Or Press
11. Bailey, K. U. W. (1997) Reassessing Social realism: Neocultural
socialism and social realism. Cambridge University Press
12. Buxton, I. ed. (1983) Neocultural socialism in the works of Rushdie.
Loompanics
13. Drucker, Y. S. (1977) The Dialectic of Reality: Social realism,
nihilism and patriarchial presemioticist theory. University of North
Carolina Press
14. Sargeant, D. ed. (1998) Social realism in the works of Joyce.
University of Illinois Press
--
Jean Paul Sartre
Giovanni Asproni
> Universe wrote:
>
> > Science wins some and loses others.
I think this statement shows bit of arrogance.
>
> > Welcome to the slippery slope of the hackerist world view:
> > empirio-pragmatism, aka craftistry.
Yes, I'm a pragmatic programmer. In my english dictionary the definition of pragmatic
is "dealing with things in a practical and sensible way", this is exactly how I try
to behave, after all I'm payed to do this. I think also to be sort of a craftsman,
since, in my opinion, Software Engineering is not yet "real engineering" because
there is no science (yet) behind it.
Note that I have a MS in Computer Science, but this kind of science deals mainly with
algorithm complexity, languages, formal specifications...not with the production of
complex software systems. So it covers only a (very small) part of the production of
such systems.
I'm pragmatic also in the choice of the metodology, languages and whatever else I use
to develop a system. I'm not an XP zealot, I'm not a RUP zealot, I'm not a CMM
zealot, I can work (as I usually do) without the latest UML case tool, I'm not a Java
or C++ evangelist...I just do my best to choose the right tool for the job. So far
I've been quite successful in doing this. I've developed reusable and reliable
software with useful (not write-only) documentation.
> But given the tone and bent of your comments, here's a word the wise:
> "caveat emptor" regarding "in eXtremis Programming".
The only tone intended of my previous mail was "I've tried it in this way and it
worked", it was neither a praise nor a critic to XP, it was an acknoledgment of the
fact that XP can be used fruitfully for certain systems.
Giovanni
Shayne Wissler
> Universe wrote:
>
> > Universe wrote:
> >
> > > Science wins some and loses others.
>
> I think this statement shows bit of arrogance.
>
> >
> > > Welcome to the slippery slope of the hackerist world view:
> > > empirio-pragmatism, aka craftistry.
>
> Yes, I'm a pragmatic programmer. In my english dictionary the definition
of pragmatic
> is "dealing with things in a practical and sensible way", this is exactly
how I try
> to behave, after all I'm payed to do this.
There are several senses of the term. I don't think Elliott had that one in
mind.
Giovanni Asproni
>
> There are several senses of the term. I don't think Elliott had that one in
> mind.
I know exactly what he means.
But I use the term pragmatic with the meaning I wrote in my mail.
Giovanni
Shayne Wissler
It is evasive to switch the definition of your opponent's terms out from
under him without explicitly recognizing that you're doing so, and why.
Shayne Wissler
Universe
> Shayne Wissler wrote:
Quicklu and not sure of exact context but...
"Pragmatic" for most including myself means "highly practical".
American "pragmatism" is a well established moniker for a philosophical
trend, 'school' actually. It is a kissing cousin of British
"empiricisim".
The 2 philosophies downplay theory and elevate practice above it. So one
can see how "pragmatic" relates, but it doesn't go as far as a coherent
ideological approach, as with "pragmatism".
I find mostly that science leads contextual experiment and endeavor with
previously verified principles and laws - theory - from the context, and
constantly tests and validates that with on-going contextual data and
experience - practice.
Elliott