"Richard Heathfield" <dontmail@address.co.uk.invalid> ha scritto:

> > My (tentative) answer is: "We create a model of the reality written in a
> > language that can be executed by a machine".
>
> Close. A model of some reality or other. [...]
> Of course, one could argue that the user expects a game to model /a/
reality
> that just doesn't happen to be the one we know to exist.

Got it! Let's say that we "create models of *possible* realities".

In this case, what we usually call "requirements" is just a description of
this "reality". If I'm able to "imagine" a possible scenerio, it becomes my
"reality".

Some of this "realities" (but I'm sure a real philosopher already would have
given them a fancier name) may be more recognizable and some may not.

In a "billing for telco companies reality", there is place for clients,
lines, phone numbers, call durations, etc; things that you can recognize in
our everyday life. Other "realities" might contain things like blue
hedgehogs that, hopefully, you will never meet!

> But is it wise to let a dynamic modelling system
> modify our perception of reality, when that model was
> built purely for  entertainment purposes?

It looks to me that we do not necessarily need to *modify* our perception of
reality but just to recognize the fact that during our "programming"
activity we build models that try to capture the essence of (parts) of "some
world", being it the "real" world or not. If that is true, we could find an
uniform way to treat both cases.

Maybe this also answer to Malcom's observation:

>You create a world with rules, and then within those rules design
>something which is fun to play.

This could be exactly what we do ... we should elaborate on that.

About refinement:
> Top-down design is an obvious first step.

Agreed, but I've never seen it working in practice. Everyone seems to work
in a "middle-out" mode instead, but very fews dare to admit it!

A pure top-down approach seems to imply a "perfect knowledge" in advance
(I'll partition my reality in such a way that the different parts will only
interact in predefined ways, however I will sub-partition them).

A pure bottom-up approach seems to imply a "reductionist" view (Let me
prepare all this little pieces, I simply will need to assemble them at a
later stage).

Actually we rarely know which "little pieces" we will need and much less we
know how to "assemble" them (leaving alone how "simple" will it be). For
top-down approach, we do not even know if such "perfect partition" really
exists!

Maybe our (yet to discover) method for representing "models" should
capitalize on this observation and directly suppot a way of working that
proceeds by attempts: an initial model is created, it is checked against
(representations of) real cases, it is extended/modified to include the
cases which it fails to handle correctly.

Does'nt this remind you of the way we humans are supposed to learn?

I'll try to reformulate the initial sentence: "Programming means to learn
enough about a (part of) (a possibily virtual) reality, to be able to create
a model for it".

Don't know if we're getting closer but it looks like we are heading for
somewhere! Is'nt it?

R/D

"Remo D." <rd@nospam.it> wrote in
news:c0rf2j$17fb$1@newsreader2.mclink.it: 

<snip>

> I'll try to reformulate the initial sentence: "Programming means to
> learn enough about a (part of) (a possibily virtual) reality, to be
> able to create a model for it".

Well, there are certain constraints on the model. What you've described 
sounds more like physics (and several other sciences, each for specialised 
'part' of reality), rather than programming!

The significant difference is that the model we're creating can be 
simulated completely using only a small set of axioms which (theoretically, 
at least) can be performed by a computer. In addition, there can be 
constraints (or at least, desirable properties) on simulation and the 
description of the simulation - performance constraints, readability, 
maintainability, robustness and so on.

It's often trivial to create a model of some phenomena that isn't 
computable, and even if the model is computable it may take so long to 
compute that the universe would have suffered heat-death before the result 
was computed. It's the constraints on the simulation that make programming 
what it is, rather than 'just like' physics.

So, here's my additions...!

"Programming is the art of learning about a (part of) (a possibly virtual) 
reality, and then creating a simulation of that limitted reality which can 
be fully performed using only the axioms provided by a computer whilst 
conforming to external constraints."

A bit of a mouthful, but I think it covers most of the bases!

Even with that, in the strictest sense, the programming is only really the 
second bit involving the creation of the simulation. The former is 
something that programmers will typically perform though, and it's often 
referred to as being part of the 'programming' for small projects. For 
larger projects (and especially in software engineering circles AFAIK) it's 
typically a completely non-trivial task of it's own performed by those 
skilled in making such models.

Ian Woods

-- 
"I'm a paranoid schizophrenic sado-masochist.
My other half's out to get me and I can't wait."
Richard Heathfield

Ian Woods wrote:

<snip>

> "Programming is the art of learning about a (part of) (a possibly virtual)
> reality, and then creating a simulation of that limitted reality which can
> be fully performed using only the axioms provided by a computer whilst
> conforming to external constraints."
> 
> A bit of a mouthful, but I think it covers most of the bases!

How do you feel about "a computer is a device for exploring dynamic models" 
and "programming is the art of preparing dynamic models"?


-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Richard Heathfield <invalid@address.co.uk.invalid> wrote in
news:4031ca39@news2.power.net.uk: 

> Ian Woods wrote:
> 
> <snip>
> 
>> "Programming is the art of learning about a (part of) (a possibly
>> virtual) reality, and then creating a simulation of that limitted
>> reality which can be fully performed using only the axioms provided
>> by a computer whilst conforming to external constraints."
>> 
>> A bit of a mouthful, but I think it covers most of the bases!
> 
> How do you feel about "a computer is a device for exploring dynamic
> models" and "programming is the art of preparing dynamic models"?

I don't like it much... you're missing the 'model must be computable' 
(IOW, completely specified using only the basic axioms provided by a 
computer), and the bit about getting the answer out of the programmer 
before the user's died.

Someone who can prepare a model of something isn't much of a programmer 
if it can't run on a computer or the amazingly insightful answer will 
only benefit the user's great-great-great-great-great-grandchildren!

Ian Woods

-- 
"I'm a paranoid schizophrenic sado-masochist.
My other half's out to get me and I can't wait."
Richard Heathfield

Ian Woods wrote:
> "Remo D." <rd@nospam.it> wrote in
> news:c0rf2j$17fb$1@newsreader2.mclink.it: 
> 
> <snip>
> 
>>I'll try to reformulate the initial sentence: "Programming means to
>>learn enough about a (part of) (a possibily virtual) reality, to be
>>able to create a model for it".
> 
> 
> Well, there are certain constraints on the model. What you've described 
> sounds more like physics (and several other sciences, each for specialised 
> 'part' of reality), rather than programming!
> 
> The significant difference is that the model we're creating can be 
> simulated completely using only a small set of axioms which (theoretically, 
> at least) can be performed by a computer. In addition, there can be 
> constraints (or at least, desirable properties) on simulation and the 
> description of the simulation - performance constraints, readability, 
> maintainability, robustness and so on.
 >
> It's often trivial to create a model of some phenomena that isn't 
> computable, and even if the model is computable it may take so long to 
> compute that the universe would have suffered heat-death before the result 
> was computed. It's the constraints on the simulation that make programming 
> what it is, rather than 'just like' physics.
> 
> So, here's my additions...!
> 
> "Programming is the art of learning about a (part of) (a possibly virtual) 
> reality, and then creating a simulation of that limitted reality which can 
> be fully performed using only the axioms provided by a computer whilst 
> conforming to external constraints."

Isn't "virtual reality" an oxymoron?!  ;-)

I'm worried about the use of the word "reality" here.  There are several 
things that don't have any natural correspondence to reality.  It 
implies programmers apply a metaphor of physical things, which I doubt. 
  E.g. a binary tree vs a real one?  Take a compiler: is there a 
"reality" corresponding to a compiler?  A grammar?  A parser?  A database?

Instead of reality, I would use the word "abstractions".  Of course, 
real and abstract are antonyms, just like virtual and real.

What about "programming is the art of creating computational 
abstractions"?  Then we'd need "art is a creative process using a wide 
range of human faculties", and "computation is the process of proceeding 
from one state to another using predefined rules", and "abstraction is a 
(possibly loose) correspondence of one entity or process with another".

I don't know if I'm right or wrong, but it's more concise.

Calum

Richard Heathfield wrote:

> How do you feel about "a computer is a device for exploring
> dynamic models" and "programming is the art of preparing
> dynamic models"?

I donno about "dynamic models" (no static ones?), but per a
well known metaphor, it continues to work when you substitute
concepts: "A <telescope> is a device for exploring <the sky>."

Where <the sky> is a placeholder for "object of exploration".
Change it if you prefer something else (e.g. "the stars" or
maybe "astronomy").

But I get stuck on, "<Making telescopes> is the art of preparing
<the sky>"??  Which seems to point out my difficulty with the
"dynamic models" concept.

Is a dynamic model the program (as the second statement suggests)?
If so, does a computer explore the program (or what the program's
about, as I take the first statement to suggest)?

>> "Programming is the art of learning about a (part of) (a
>> possibly virtual) reality, and then creating a simulation
>> of that limitted reality which can be fully performed using
>> only the axioms provided by a computer whilst conforming
>> to external constraints."

I think Ian's text did--as he said--cover the bases pretty well.
Maybe it can be shortened a little if we argue that creating
a model implies learning about the thing modeled and compressing
some of the contraints verbiage.  My attempt:

'Programming is the art, craft and science of creating a model of
 a (real or virtual) process. The model is limited by contraints
 of the language and hardware used as well as the programmer's
 understanding of the process.'

Well, maybe that isn't really much shorter, and I don't know if
it's any better.  Maybe the programmer limits part can be implicit.
(Maybe the whole constraints issue is implicit and moot!)

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Ian Woods wrote:

> ...the programming is only really the second bit involving the
> creation of the simulation. The former is [...] often referred
> to as being part of the 'programming' for small projects. For
> larger projects (and especially in software engineering circles
> AFAIK) it's typically a completely non-trivial task of it's own
> performed by those skilled in making such models.

What I think you're calling "programming" here I call "coding".

I'd still define it as "programming", which I (in my response to
Richard's response to you) just decided to define as the creation
of the model (that is, I include both steps in "creation").

Thinking about it, there's really many (iterative) steps:

	1. Observation -- gathering data about the model
	2. Analysis -- considering the semantics of that data
	3. Synthesis -- designing a computer-based model
	4. Implementation -- coding
	5. Testing/Debugging

Any of those steps can discover a need to go back to any previous
step.  For example, debugging may discover a implementation error,
or it may uncover a design error.  The latter case could require
you to go as far back as step #1.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Remo D." wrote:

> A pure top-down approach seems to imply a "perfect knowledge" in
> advance (I'll partition my reality in such a way that the
> different parts will only interact in predefined ways, however
> I will sub-partition them).

It doesn't have to.  It can, in some cases, be grown as you explore
the problem.  You start with the top "box"--"my program"--and then
divide that into the basic steps you know you need to accomplish.
Then divide those and so on.

The idea is that the approach is a tool for exploring the problem
space.  If it becomes "ugly", perhaps your thinking is wrong (OR
this type of analysis isn't well suited to the problem).

> A pure bottom-up approach seems to imply a "reductionist" view (Let
> me prepare all this little pieces, I simply will need to assemble
> them at a later stage).

It's tedious making the little parts, but it's fun putting them
together and "suddenly" having a "working" program after all that
long development time.  (-:

Top-down, OTOH, can provide you with a quickly "working" program,
although it'll probably be smoke and mirrors at that point.

> Maybe our (yet to discover) method for representing "models" should
> capitalize on this observation and directly suppot a way of working
> that  proceeds by attempts: an initial model is created, it is
> checked against (representations of) real cases,...

You really should read Plauger's book.  This is a big part of what
he's saying: use multiple tools/approaches to solve a problem.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude
> You really should read Plauger's book.  This is a big part of what
> he's saying: use multiple tools/approaches to solve a problem.

I just checked at amazon and, as far as I've understand, it's classified as
a "hard-to-find" book. They will tell me after the order if they are able to
fulfill it or not. I'll try!

Ian Woods wrote:

> Richard Heathfield <invalid@address.co.uk.invalid> wrote in
> news:4031ca39@news2.power.net.uk:
> 
>> Ian Woods wrote:
>> 
>> <snip>
>> 
>>> "Programming is the art of learning about a (part of) (a possibly
>>> virtual) reality, and then creating a simulation of that limitted
>>> reality which can be fully performed using only the axioms provided
>>> by a computer whilst conforming to external constraints."
>>> 
>>> A bit of a mouthful, but I think it covers most of the bases!
>> 
>> How do you feel about "a computer is a device for exploring dynamic
>> models" and "programming is the art of preparing dynamic models"?
> 
> I don't like it much... you're missing the 'model must be computable'

Oh, I was missing lots and lots of stuff. I was going for "quick summary" 
rather than "definitively defining definition".

> Someone who can prepare a model of something isn't much of a programmer
> if it can't run on a computer

Get A Better Computer? :-)

> or the amazingly insightful answer will
> only benefit the user's great-great-great-great-great-grandchildren!

Depends on the question.

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

"Calum"  ha scritto

> Instead of reality, I would use the word "abstractions".  Of course,
> real and abstract are antonyms, just like virtual and real.

 I would love to keep the word "reality"  in our discussion.

 Starting from the models, once represented in our software, a phone bill
and a blue hedgehog have exactly the same degree of reality (they are bits).
Why should we follow two different routes to model them only because we will
never find a blue hedgehog in our mail box? My mind more easily accepts the
fact that the "reality" is extended to "everything we can possibly imagine".

 Even if we use "abstraction", the next question would be "abstract with
respect to what?" And this would take as back to some form of "reality"
(IMO)

 Again a real philosopher would came handy now, I'm pretty sure that the
notion of "reality as the set of all worlds we can dream of" has been
explored by someone!

 R/D

Let's try to summarize.

  - We all seem in agreement on the fact that "programming" (in its broader
sense, not just "coding") is a "modelling" activities. In other words, taken
a "reality" R and an event E that in R produces the effect F, we expect that
given a model M,  M(E) occuring in M(R) will produce the effect M(F).

  - From a previous observation and from a comment by Programmer Dude,
programming also seems to be a "learning experience" where the knowledge you
gain during the process is essential for the final result. This seems to be
a well-known fact among experienced programmers but, AFAIK, no one present
this aspect as very important. Rather, it's treated as a "necessary evil".
Maybe it's not?

  - A property of the models we are interested in is that they should be
computable, as Ian Wood noticed. Perfectly agreed! No point in a model that
we could not (even theoretically) run in (some form of) computer.

  - Another property is their dependance on our intentions. Unlike physics
(where models of the a part of reality tend to be created so to cover larger
and larger portions of it) we need to build completely different models
depending on the reason why we are doing it. Consider how different a "car"
will be when represented in a game, in a CAD or in a vendor catalog!

The central question seem so to be "what's relevant?" instead of "how it
works?".

But we are not progressing! How do we represent our model?

When using OO techniques, we say that "everything is representable as an
object". How "natural" is to constraint everything in hyerarchies? And to
what extente should it be "natural"? Is the "Aspect Oriented Programming"
what is missing to complete the picture?

Maybe object orientation should be abandoned (or at least redimesioned) in
favour of some other more fundamental concept? (i.e. something that is
closer to our "reality"?).

A philosophical answer could come from the ontology (that's why I mentioned
in my first messge).

Taken into consideration everything we discussed earlier, which aspects
should be taken as "primitives" to describe our "reality"?

OO took the concept of "active object" as fundamental: "the world can be
described as a set of objects that are able to interact each other".
It has been proved itself a good enough concept so far (even if it deliverd
much less than what was promised during the nineties),  but personally I'm
not 100% satisfied.

Maybe if we could take something else as our "basic building blocks", we
could achieve better results!

R/D

"Remo D." wrote:

>  I would love to keep the word "reality" in our discussion.
                                  ^^^^^^^
Okay, well there it is!  (-:

>  ...a phone bill and a blue hedgehog have exactly the same degree
> of reality (they are bits).  Why should we follow two different
> routes to model them only because we will never find a blue hedgehog
> in our mail box?

A possible answer is that, when modeling phone bills we are
constrained by external ("real world" factors), but when modeling
blue rodentia, the constraints are largely imaginary.

> My mind more easily accepts the fact that the "reality" is
> extended to "everything we can possibly imagine".

What then to call "the real world"?  (-:


-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"Remo D." wrote:

>> You really should read Plauger's book.  This is a big part of what
>> he's saying: use multiple tools/approaches to solve a problem.
> 
> I just checked at amazon and, as far as I've understand, it's
> classified as a "hard-to-find" book. They will tell me after
> the order if they are able to fulfill it or not. I'll try!

Well, probably too late if you've ordered it, but they show six
used available (from 15 USD).

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Remo D. wrote:
> "Calum"  ha scritto
> 
> 
>>Instead of reality, I would use the word "abstractions".  Of course,
>>real and abstract are antonyms, just like virtual and real.
> 
> 
>  I would love to keep the word "reality"  in our discussion.
> 
>  Starting from the models, once represented in our software, a phone bill
> and a blue hedgehog have exactly the same degree of reality (they are bits).
> Why should we follow two different routes to model them only because we will
> never find a blue hedgehog in our mail box? My mind more easily accepts the
> fact that the "reality" is extended to "everything we can possibly imagine".
> 
>  Even if we use "abstraction", the next question would be "abstract with
> respect to what?" And this would take as back to some form of "reality"
> (IMO)
> 
>  Again a real philosopher would came handy now, I'm pretty sure that the
> notion of "reality as the set of all worlds we can dream of" has been
> explored by someone!

I was wondering, it an object is in our minds, is it "real"?  It's just 
that so many of the [programming] objects I tend to create don't really 
correspond to physical things.  Hey, a "bank account" is not really a 
physical thing either.  Hmm, I don't know.  A bank account exists in our 
collective minds (assuming you are not just all avatars here to amuse 
me), yet it a purely capitalist invention.  You can't pick up a bank 
account, only bits of paper alluding to the existence of this abstract 
entity.

What's the definition of "real"??

:-)

Calum

Calum wrote:

> What's the definition of "real"??

Here's a very accessible article (which happens to *very* closely
parallel beliefs of mine):

http://www.boston.com/news/globe/ideas/articles/2003/10/05/out_of_the_matrix/

And speaking of the movie, the website also had some interesting
ruminations and references to the "what is reality" question.

http://whatisthematrix.warnerbros.com/

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Calum wrote:

<snip>
> What's the definition of "real"??

Love these discussions!!  Let me take a stab at this:

They say reality is in the mind of the beholder, but it seems we all behold 
it.  The question is, what do we have in common?

I suggest that we all have an environment in common.  And reality is our 
conceptual representation of our environment.  Note here than I'm not 
saying anything about the environment other than that it exists, and that 
we all have certain aspects of it in common.  The differences are largely 
about the differences between us as individuals:  no two of us occupy the 
same point in space and time, and so our experiences thereof must differ.

A second attribute of reality is that it is dynamic.  They say that change 
is one of the few universal constants, and I'd order that by defining 
change as incident process, either directly or indirectly.  But the most 
important aspect as far as we're concerned is what changes mean for each of 
us:  The prime imperative of life is to survive, if not individually, then 
as a species.  So the significance of reality for each of us is in terms of 
how it affects survival.

So a third attribute of reality is that it is binary.  Reality is the 
connection between our environment, and our internal perceptual/conceptual 
model thereof.  And the purpose here is to allow us to predict, to answer 
the question, "What comes next?".  That's how we enable our own 
adaptability, which allows us to survive the changes in our environment.  
So at root, reality is about maintaining a one-to-one basic correspondence 
between the environment and the internal model.

What we do is to fork different processes from this internal model and allow 
them to play out as best they can (given what we know and have 
experienced), and this process is most often hugely complex and ultimately 
confusing to observe unless the basic model in correspondence to the 
environment remains accessible.

Now, we all discover that the changes and processes in our environment 
cannot be completely understood, and so prediction can never be absolutely 
reliable.  This generally means that we learn how to keep some number of 
forks up and running as if they were primary, and we test them regularly 
(reality checks?) to determine their validity.  Each of these, to the 
extent correspondence to the environment is observed, have intrinsic 
substance as potential aspects of the prime reality.

But there is a further complication, and that is that our experience of our 
environment is not at all reliable in itself, and so the prime reality may 
at any point be discovered invalid, such that a fork better satisfies the 
prime's one-to-one correspondence requirements.  Which means we wind up 
carrying around some number of inter-related reality "streams" that contain 
possibilities and probabilities, all of which require regular and sometimes 
continuous testing.

It has been argued that the above analysis is why our brains are as they 
are, that they evolved to address these issues and needs.  In the main, I 
think the arguments are largely compelling.  Which means that we can 
reasonably accept the analysis as valid.

If we do, then we can proceed.  The question at this point is this:  How do 
we successfully handle multiple reality streams?  There are some number of 
ways this can be done.  

One is to contrive to allow them all to run simultaneously in separate 
spaces, where the relationships between them define the ordering of those 
spaces.  To some extent, we all do this, but most of us discover that our 
natural ability to do this falls short of our apparent needs.  
Traditionally, some part of growing up involved learning how to expand 
those natural abilities, even though our experience itself fostered such 
development.  It is often discovered that the ability to force an expansion 
is a definite survival asset, but in the end, we discover that this isn't 
enough.

A second, and more efficient, way is to construct conceptual devices that 
will allow links between these streams, such that some of them can run 
unmonitored.  This works very well, because it relieves the need to be on 
constant watch, often having only one running primary reality that's well 
linked to a number of others.  But the downside of this is that this 
conceptual construct becomes a meta-reality in its own right.  What happens 
is that the meta-reality survives some number of different primaries, and 
then tends to become the default primary in itself.  This, of course, is a 
Bad Thing... <grin>

The most commonly successful way is to contrive a blend of these two ways, 
where a primary reality is carefully monitored, and a meta-meta reality 
comprising several streams of meta-realities performs relatively continuous 
link checks between the prime and the several metas.  In general, this 
meta-meta is best served as an adjunct to the primary monitor itself, which 
we call conscious awareness.  This primary monitor is driven by the input 
of one's major sensory apparatus, generally in the order of kinesthetic, 
visual, auditory/touch/smell/temperature/etc.  These inputs are coordinated 
as the real-time context for the primary monitor.  Apparently the location 
is the prefrontal cortex of the brain.

Such, then, is the physical basis of "reality".  We could say that it is our 
environment as we discern it, along with as many relevant optional streams 
of speculation as may be extant.  Artifice is the name of the game here, 
because the issues are ours, not those of our environment.  We survive to 
the extent we employ these abilities successfully, and to the extent we 
deploy them as useful and effective artifact.

The discussion of reality in this thread views it in one of its myriad 
forms.  For a "reality" to be coherent, it must be informed.  Our primary 
reality is informed by our contact with our environment.  For those we 
create from whole cloth, we must do the informing ourselves.  We do that by 
employing rules to which it must comply, as we do in mathematical and 
geometrical models.  Any reality is valid to the extent it successfully 
fills those requirements, and further does so such that it is founded on a 
form of "ground state", where more effort is required to destroy than to 
maintain it.

Dunno what you guys will make of this, but perhaps there is something of 
value here.  It's kinda off the top of my head, so is obviously incomplete 
and probably ill-formed.  I'll be happy to discuss this if you like.

Not a philosopher...

Bill Tallman  
-- 
Registered Linux User: #221586
Mdk-9.0 and Slackware-9.1
A Luxuriance of Linux!!!

"William D. Tallman" ha scritto

> I suggest that we all have an environment in common.  And reality is our
> conceptual representation of our environment.  Note here than I'm not
> saying anything about the environment other than that it exists, and that
> we all have certain aspects of it in common.

  I would gladly accept your view but for this context it seems to be too
"reductive".
  I'm with you when you describe the reality as a "conceptual
representation", but, IMO, the constraint you impose on the "environment"
(its "existence") is too tight for the purpose of this discussion.

  I'm sure we could go round and round noting that "existance" implies "to
be part of the REAL world" and then your definition is that "reality is our
conceptual rapresentation of what is part of the REAL world" so I would
refrain to note it.

  The other things you said about "surviving" seem very relevant  to me with
respect to the fact that the process we are talking about wpuld be very
fundamental to our nature.

  But let us stop for a moment to talk about "the nature of reality" and
let's imagine that "some" reality exists and that you can apply the
modelling operation to it.

  I think that for our purpose (create a software system) it is not relevant
what this reality is made of, we are much more interesested in understanding
how we could represent it!!

  My personal preference is to include in the concept of "reality"
everything that I could possibly imagine (including "bank accounts") so to
wipe out the problem of its physical existance. When we will discuss the
problem if its representation we will see if that existance has an impact on
the discusion or not.

  R/D

"Remo D." wrote:

> My personal preference is to include in the concept of "reality"
> everything that I could possibly imagine (including "bank accounts")
> so to wipe out the problem of its physical existance.

I've been pondering this, and I find I have a problem with defining
reality to include 'everything we can imagine'.  The problem is that
it trashes the word ("reality") and conflates the common definition
of reality with that of "imaginary".

I think I'd rather keep them separate.

Consider that I can build a model of a 747, in which case I'm making
a model based on reality.  But I can also build a model of a house
I've designed, in which case I'm making a model based on something
in my head.  I think there's a strong analogy here to programming
in that I can build a program that models something that does exist
(e.g. a very realistic flight simulator) or not (e.g. Doom).

Perhaps the problem comes from defining model making (and thereby
programming) as "modeling reality".  Maybe we should just call it
"building models".

I have some futher thoughts on reality, but will post them in reply
to William Tallman's message....

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"William D. Tallman" wrote:

> Love these discussions!!  Let me take a stab at this:

Hey!  Watch out where you're stabbing!!  (-:


> They say reality is in the mind of the beholder,...

I must not be a member of "they", because I *definitely* do not
define it that way, and we can start with an interesting point:

*IS* reality really in the mind of the beholder, or does it exist
and an external object to behold?  I would certainly agree that
the internal representation of our perceptions...is just that: an
internal *representation* of our perceptions.

I just read about an incredible study.  They showed a film of a
basketball game to a group and told them to count the number of
times a certain player passed the ball.  Afterwards, they were
asked if anyone noticed anything unusual.

A *surprising* number of people never noticed the man in the
gorilla suit run through the game!  Strong focus on a task can
cause a kind of tunnel vision.

The point is that our perceptions are pretty awful.  (There is also
the fact that--considering quantum aspects of reality--even the
most perceptive of us is only seeing a sort of image of things.)


> I suggest that we all have an environment in common.  And reality
> is our conceptual representation of our environment.  Note here
> than I'm not saying anything about the environment other than that
> it exists, and that we all have certain aspects of it in common.

Yet what we may have in common about a 'thing' is only the shared,
learned identification of that thing.  Imagine, for example, that men
and women actually experience something quite different internally
when they perceive the color red.  Until we get that telepathy machine
working, we'd never know, because men and women have a common *learned*
"tag" associated with the internal experience.

It's even possible that each being has a different internal experience
and that what we really have in common is those learned tags.

> The differences are largely about the differences between us as
> individuals:  no two of us occupy the same point in space and time,
> and so our experiences thereof must differ.

Exactly.  Further, no two of us have identical brain wiring, so it
is actually possible the internal experience varies considerably
from being to being.


> A second attribute of reality is that it is dynamic.

Very!  (-:


> So a third attribute of reality is that it is binary.

This really caught my eye, because--taken out of context--I'd say
this is the exact opposite of true.  One thing chaos mathematics
has taught us is that any attempt to quantify reality into discrete
bits is doomed to failure.

But I think you mean it differently....  (-:

> Reality is the connection between our environment, and our
> internal perceptual/conceptual model thereof.  And the purpose
> here is to allow us to predict, to answer the question, "What
> comes next?"....

I think--in a different venue--I'd quibble over the wording, but
I think I do agree with the basics here.  Our model of reality
enables us to function within that reality, IF that model is
reasonably accurate.  Yes?

> So at root, reality is about maintaining a one-to-one basic
> correspondence between the environment and the internal model.

Or--at least--an as-*accurate*-as-possible map of it, yes.  One
simplistic definition of mental health is the degree to which
your internal map of reality matches the real thing.

(But, since none of us actually perceived the real thing fully.... :-)


> Now, we all discover that the changes and processes in our
> environment cannot be completely understood, and so prediction
> can never be absolutely reliable.

In fact, Quantum physics suggests pretty strongly that it is
impossible to become absolutely reliable!

> This generally means that we learn how to keep some number of
> forks up and running as if they were primary, and we test them
> regularly (reality checks?) to determine their validity.

Reality checks.  That's one reason I newsgroup!  (-:

> [big snip]

Hmmmm.  I'm not sure I'm down with you on most of this, but that
may be because you present a very abstract concept without any
kind of examples to illustrate it.  AS STATED, it sounds a little
bit like philogibberish, but maybe I'm just not grokking you.

Thing is, I'm not sure I agree about the forking process.  I have
no sense of multiple processes running in my head--only the one.
You use the term "speculation" at one point, so I gather that by
multiple processes, you are talking about imagination and guessing.

Off the top of my head, I'm not sure I agree with the "forking"
model (that might be because fork() has such a specific meaning to
me :).

We certainly do create imaginations (fantasy) and guesses (attempts
at predicting an unknown reality), and you do seem to be saying we
(if sane) distinguish them from our perception of "reality"....

I donno, we may be running into terminology issues here, and it
is off topic (and I feel like I'm typing and typing and managing
to not say anything useful), so I'm just going to skip ahead....

> [masso snip]
>
> Dunno what you guys will make of this,...

Well, to be honest, it didn't do too much for me, I guess.  Not in
any way trying to suggest any of it's wrong (or right)...just that
I'm not tying it in to anything right now.

Let me just ask you this: how do you tie any of this into programming?

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude schrieb:
> "William D. Tallman" wrote:
> *IS* reality really in the mind of the beholder, or does it exist
> and an external object to behold?  I would certainly agree that
> the internal representation of our perceptions...is just that: an
> internal *representation* of our perceptions.

Yeah, and there's a certain kind of perceptions that we think are
perceptions of "reality". 

> > A second attribute of reality is that it is dynamic.
> 
> Very!  (-:

I disagree.
I believe that reality is characterized by persistence.
Only stuff/perceptions that persist are accepted as real.
Of course we've learned as infants to reason about them; to learn that
things that are hidden from view behave as if they persisted though we
can't see them ("when a tree falls in the forest..").

Dream worlds can be perceived, but they don't persist.

> > Reality is the connection between our environment, and our
> > internal perceptual/conceptual model thereof.  And the purpose
> > here is to allow us to predict, to answer the question, "What
> > comes next?"....

Right - and only stuff that persists, that can be expected to affect the
future, is useful to consider in that frame of reference.

> > So at root, reality is about maintaining a one-to-one basic
> > correspondence between the environment and the internal model.

No. The internal model's an abstraction; "chair" is a one-to-many
correspondence ;)

> Or--at least--an as-*accurate*-as-possible map of it, yes.  One
> simplistic definition of mental health is the degree to which
> your internal map of reality matches the real thing.

You can only measure this by how adapted an individual's actions seem to
reality - and the quality of adaption is colored by your perception of
reality... ;)

> Let me just ask you this: how do you tie any of this into programming?

Is a bug real if you can't reproduce it?

mendel
-- 
Feel the stare of my burning hamster and stop smoking!

Programmer Dude wrote:

> "William D. Tallman" wrote:
> 
>> Love these discussions!!  Let me take a stab at this:
> 
> Hey!  Watch out where you're stabbing!!  (-:

<grin>

>> They say reality is in the mind of the beholder,...
> 
> I must not be a member of "they", because I *definitely* do not
> define it that way, and we can start with an interesting point:
> 
> *IS* reality really in the mind of the beholder, or does it exist
> and an external object to behold?  I would certainly agree that
> the internal representation of our perceptions...is just that: an
> internal *representation* of our perceptions.

It's the internal representation that is the reality.  Reality is the mirror 
of our environment that we create for our own purposes.  
 
> I just read about an incredible study.  They showed a film of a
> basketball game to a group and told them to count the number of
> times a certain player passed the ball.  Afterwards, they were
> asked if anyone noticed anything unusual.
> 
> A *surprising* number of people never noticed the man in the
> gorilla suit run through the game!  Strong focus on a task can
> cause a kind of tunnel vision.
> 
> The point is that our perceptions are pretty awful.  (There is also
> the fact that--considering quantum aspects of reality--even the
> most perceptive of us is only seeing a sort of image of things.)

Actually our perceptions, within their limitations, are pretty good.  What 
we do with them is another matter and has to do with our individual 
experience bases.

>> I suggest that we all have an environment in common.  And reality
>> is our conceptual representation of our environment.  Note here
>> than I'm not saying anything about the environment other than that
>> it exists, and that we all have certain aspects of it in common.
> 
> Yet what we may have in common about a 'thing' is only the shared,
> learned identification of that thing.  Imagine, for example, that men
> and women actually experience something quite different internally
> when they perceive the color red.  Until we get that telepathy machine
> working, we'd never know, because men and women have a common *learned*
> "tag" associated with the internal experience.

Our perceptions are generated by our physical bodies, and so I think we can 
expect them to be much more similar than different.  The use we make of 
them varies with the individual, of course.
 
> It's even possible that each being has a different internal experience
> and that what we really have in common is those learned tags.

What we have in common and what we share are two different things.  Lot's of 
arguments about the nature of language and imagery, and it looks like there 
is a physical basis for much of it (not all, of course).  The statement 
that we have more in common than we realize is a human verity, as we focus 
on those things that differentiate us in order to describe our identities, 
speaks to this.  What we do with commonalities is largely prescribed by our 
survival needs of the moment, and civilization is all about such things as 
the division of labor, pooling of resources, etc.  Civilization, when 
possible, is more efficient in promoting mass survival than is basic 
tribalism, and thus provides the individual with the opportunity to enhance 
his/her own survival.  Shared commonality is the basis of civilization, and 
the medium of sharing is communication.

The point is that there are several levels of reality extant, and we take 
some of them for granted.  Those we do are often the ones that bite us 
because we weren't watching them.
 
>> The differences are largely about the differences between us as
>> individuals:  no two of us occupy the same point in space and time,
>> and so our experiences thereof must differ.
> 
> Exactly.  Further, no two of us have identical brain wiring, so it
> is actually possible the internal experience varies considerably
> from being to being.
> 
> 
>> A second attribute of reality is that it is dynamic.
> 
> Very!  (-:
> 
> 
>> So a third attribute of reality is that it is binary.
> 
> This really caught my eye, because--taken out of context--I'd say
> this is the exact opposite of true.  One thing chaos mathematics
> has taught us is that any attempt to quantify reality into discrete
> bits is doomed to failure.
> 
> But I think you mean it differently....  (-:

Well, the fulcrum here is consciousness, where our identity hangs out.  On 
one side is our environment, and on the other is our internal model 
thereof.  Consciousness is ephemeral, of course, leaving the internal model 
and the environment to engage in an ongoing dance as each informs and 
influences the other.  Like a binary star system, the major star is the 
environment and the minor is our model.
 
>> Reality is the connection between our environment, and our
>> internal perceptual/conceptual model thereof.  And the purpose
>> here is to allow us to predict, to answer the question, "What
>> comes next?"....
> 
> I think--in a different venue--I'd quibble over the wording, but
> I think I do agree with the basics here.  Our model of reality
> enables us to function within that reality, IF that model is
> reasonably accurate.  Yes?

There is a critical level of correspondence, below which survival is 
threatened.  It can never be identical, but we can test the internal model 
to see if its predictions are born out by our experiences of the 
environment.  It allows us the opportunity to make the right moves, and to 
the extent we learn how to do this, we not only survive, we thrive.

>> So at root, reality is about maintaining a one-to-one basic
>> correspondence between the environment and the internal model.
> 
> Or--at least--an as-*accurate*-as-possible map of it, yes.  One
> simplistic definition of mental health is the degree to which
> your internal map of reality matches the real thing.
> 
> (But, since none of us actually perceived the real thing fully.... :-)

Which is why science, and the Tao, for two somewhat dissimilar examples... 
<grin>

> 
>> Now, we all discover that the changes and processes in our
>> environment cannot be completely understood, and so prediction
>> can never be absolutely reliable.
> 
> In fact, Quantum physics suggests pretty strongly that it is
> impossible to become absolutely reliable!
> 
>> This generally means that we learn how to keep some number of
>> forks up and running as if they were primary, and we test them
>> regularly (reality checks?) to determine their validity.
> 
> Reality checks.  That's one reason I newsgroup!  (-:

Usenet:  Freefloating intellectual marketplace with service problems 
(sewage, for instance.... lol!!!) 
>> [big snip]
> 
> Hmmmm.  I'm not sure I'm down with you on most of this, but that
> may be because you present a very abstract concept without any
> kind of examples to illustrate it.  AS STATED, it sounds a little
> bit like philogibberish, but maybe I'm just not grokking you.

Yep.  Now the task is to see how these abstractions are manifest in the 
issue of interest; here, programming.
 
> Thing is, I'm not sure I agree about the forking process.  I have
> no sense of multiple processes running in my head--only the one.
> You use the term "speculation" at one point, so I gather that by
> multiple processes, you are talking about imagination and guessing.

My terminology is not consistent and for good reason:  it's not set.  So I 
use various metaphors and other such devices in order to further 
comprehension.  I can't say that the notion of forking is meaningful to 
others, but it seemed appropriate for me.  I guess one has to think about 
it a bit, dunno/

> Off the top of my head, I'm not sure I agree with the "forking"
> model (that might be because fork() has such a specific meaning to
> me :).
> 
> We certainly do create imaginations (fantasy) and guesses (attempts
> at predicting an unknown reality), and you do seem to be saying we
> (if sane) distinguish them from our perception of "reality"....

All internal presentations of an environment are realities, even the 
fantasies, and yes, the primary purpose is to create an opportunity to ramp 
up our preparedness by successful prediction, to perceive the possible and 
evaluate the probable.  Any one of these reality streams can become primary 
in an instant, if a different one satisfies our input from our environment 
better than the current primary (sudden changes for which we are prepared, 
etc).  So it's not our perception of reality we need to distinguish, it's 
that we maintain one that has acceptable correspondence to what we can know 
of our environment.  Thus, it's good to have "reality checks" on all 
significant reality streams (child processes?).
 
> I donno, we may be running into terminology issues here, and it
> is off topic (and I feel like I'm typing and typing and managing
> to not say anything useful), so I'm just going to skip ahead....

Yep, I understand the feeling!  
 
>> [masso snip]
>>
>> Dunno what you guys will make of this,...
> 
> Well, to be honest, it didn't do too much for me, I guess.  Not in
> any way trying to suggest any of it's wrong (or right)...just that
> I'm not tying it in to anything right now.
> 
> Let me just ask you this: how do you tie any of this into programming?

Okay, the OP was talking about modeling reality, and I presented my take on 
how we do that in our daily lives.  In real life, we have an ongoing 
iterative process where we check and adjust on a continuous basis, or we 
gamble that we can do so periodically.  We also have a fork process where 
we allow alternative and optional streams to arise in parallel with the 
working primary.  And there are other things we do, of course.

How about applying these to programming.  I think that perhaps the notion of 
creating a test for the code in parallel with the code itself is akin to 
the reality check we ordinarily do.  I think that having several different 
teams taking different approaches at different points has advantages.  I 
think that acceptance that the fact of the matter is that, when all is said 
and done, what one has done is "muddle through", as the British are wont to 
say.  In the last regard, it would mean that it would be useful to 
accommodate that approach as legitimate and see how to incorporate that 
point of view in the design and execution of a project.

So, a definition of programming might do well to speak to these views as 
well.  Maybe programming is getting a computer to perform as desired, to 
produce what is wanted from it.  Figure out what needs doing, figure out 
how the computer best does that, and write the instructions the computer 
needs to do its job.  Maybe programming is writing computer programs, and 
all the rest of this is just common sense;  apply what you know with what 
wisdom you possess and be prepared to learn a lot.

Now, I'm not a programmer (think I said that), so this is a somewhat 
informed outsider's view of all this.  I'm sure that these views run 
counter to accepted programming wisdom, but perhaps they might have some 
value if only for that reason.

Bill Tallman

Michael Mendelsohn wrote:

>> ...the internal representation of our perceptions...is just that:
>> an internal *representation* of our perceptions.
> 
> Yeah, and there's a certain kind of perceptions that we think are
> perceptions of "reality".

And some are confused about which are which!  (-:

>>> A second attribute of reality is that it is dynamic.
>>
>> Very!  (-:
> 
> I disagree.
> I believe that reality is characterized by persistence.
> Only stuff/perceptions that persist are accepted as real.

Good point, but aren't those things which persist dynamic?  E.g., I
and everyone I've known long are persistant, but we've also changed
constantly.

> Dream worlds can be perceived, but they don't persist.

Oh, I donno about that!  My dream world where I'm a successful
musician is *quite* persistant!  (-:

Also, consider the mentally ill and their persistant perceptions!

>> One simplistic definition of mental health is the degree to which
>> your internal map of reality matches the real thing.
> 
> You can only measure this by how adapted an individual's actions
> seem to reality - 

You can also use as yardstick the distillation of common perceptions.
E.g. We mostly all think snow is cold, and this gives some objective
strength to that datum.  Maybe a more abstract e.g. is that most
people believe casual murder is wrong.  (Further, there is possible
some objective logical *analysis* supporting those views.)

>> Let me just ask you this: how do you tie any of this into
>> programming?
> 
> Is a bug real if you can't reproduce it?

If it's effects are real and detectable, definitely!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

"William D. Tallman" wrote:

>> *IS* reality really in the mind of the beholder, or does it
>> exist [as] an external object to behold?
> 
> It's the internal representation that is the reality.

Ah, we disagree, then.  (And because this part of things is not
hugely on topic, I'm going to skip a lot. Those more interested
in programming aspects can skip down to [Programming])


>> The point is that our perceptions are pretty awful.
> 
> Actually our perceptions, within their limitations, are
> pretty good.

I'm afraid I don't agree with that, either.  For example, law
enforcement people are quite familiar with what bad witnesses
people make--no two will "see" the same thing.

Also, per Quantumosity, NONE of us is perceiving anything like
what's really there, and it's *possible* we all perceive what
we do perceive differently.


>> Yet what we may have in common about a 'thing' is only the
>> shared, learned identification of that thing.
> 
> Our perceptions are generated by our physical bodies, and so
> I think we can expect them to be much more similar than
> different.

I'm not sure I agree.  The wiring of the brain grows uniquely
in each individual.  The connections are different--although
similar.  I'd say the jury is still out big time on just how
common our internal experience really is.

> The point is that there are several levels of reality extant,
> and we take some of them for granted.

I would say there is one reality--dimly and individually
perceived.

> All internal presentations of an environment are realities,
> even the fantasies,...

Reality == Fantasy ??

Hmmmmmm...... doesn't work for me.  (-:
I understand what you're saying, but I prefer other terminology.


[Programming]
>> ...how do you tie any of this into programming?
> 
> I presented my take on how we [create models] in our daily
> lives.  In real life, we have an ongoing iterative process
> where we check and adjust on a continuous basis, or we gamble
> that we can do so periodically.

I think a difference is that a lot of that is subconscious.
Programming should be much more intentional. (Actually, come
to that, what we do in life should be more intentional.)

> How about applying these to programming.  I think that
> perhaps the notion of creating a test for the code in
> parallel with the code itself is akin to the reality
> check we ordinarily do.

(If that check is as intentional as TDD requires.) Yes, I like
that idea.  Good comparison.

> I think that having several different teams taking different
> approaches at different points has advantages.  I

If one can afford the resources, yes excellent.

> So, a definition of programming might do well to speak to
> these views as well.  Maybe programming is getting a computer
> to perform as desired, to produce what is wanted from it.

I sometimes tell people my job is "Training Silicon Lifeforms"!

> Maybe programming is writing computer programs, and
> all the rest of this is just common sense;...

That, too.  I doubt we can derive a one-liner (or even a para)
that fully describes--let alone defines--programming.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude wrote:

> "William D. Tallman" wrote:
> 
>>> *IS* reality really in the mind of the beholder, or does it
>>> exist [as] an external object to behold?
>> 
>> It's the internal representation that is the reality.
> 
> Ah, we disagree, then.  (And because this part of things is not
> hugely on topic, I'm going to skip a lot. Those more interested
> in programming aspects can skip down to [Programming])

Okay.  I guess I should point out that I'm using basic science as the 
foundation of my observations and definitions.  As an accultured species, 
we are wont to describe reality to ourselves and others in great detail, 
and science has repeatedly pointed out that we don't know very much at all 
about what we think we're discussing.  As science does not use the term 
"reality", I go with common usage and reserve it as a human artifact; thus, 
a term used to denote our common and presumable valid mental representation 
of ourselves and our environment.

>>> The point is that our perceptions are pretty awful.
>> 
>> Actually our perceptions, within their limitations, are
>> pretty good.
> 
> I'm afraid I don't agree with that, either.  For example, law
> enforcement people are quite familiar with what bad witnesses
> people make--no two will "see" the same thing.

It's not what we see, it's what we remember that is the major source of this 
problem.  Under hypnosis, we recall very much more than we would otherwise 
believe we actually know.
 
> Also, per Quantumosity, NONE of us is perceiving anything like
> what's really there, and it's *possible* we all perceive what
> we do perceive differently.
 
True and true.  The issue, I think, is the extent of the differences.

>>> Yet what we may have in common about a 'thing' is only the
>>> shared, learned identification of that thing.
>> 
>> Our perceptions are generated by our physical bodies, and so
>> I think we can expect them to be much more similar than
>> different.
> 
> I'm not sure I agree.  The wiring of the brain grows uniquely
> in each individual.  The connections are different--although
> similar.  I'd say the jury is still out big time on just how
> common our internal experience really is.

True.  I think the data supports the notion that there is a great deal of 
commonality.  We focus on the differences to support our individual 
uniqueness, and so come to diminish our appreciation of the similarities.
 
>> The point is that there are several levels of reality extant,
>> and we take some of them for granted.
> 
> I would say there is one reality--dimly and individually
> perceived.

Here, I would not use the term "reality".  Dunno exactly what I would use, 
but there are several choices, each having different connotations.  I've 
used the term "environment", because I'm talking about what is incident 
upon us.  We can also use the term "cosmos" to speak of the general 
totality of existence.   
 
>> All internal presentations of an environment are realities,
>> even the fantasies,...
> 
> Reality == Fantasy ??

Fantasy is one form of reality.  But I understand that the cultural 
tradition strives to limit the sort of mental constructs that are 
acceptable by asserting that fantasy and reality are mutually exclusive.
 
> Hmmmmmm...... doesn't work for me.  (-:
> I understand what you're saying, but I prefer other terminology.

Acknowledged.  <grin>
 
> [Programming]
>>> ...how do you tie any of this into programming?
>> 
>> I presented my take on how we [create models] in our daily
>> lives.  In real life, we have an ongoing iterative process
>> where we check and adjust on a continuous basis, or we gamble
>> that we can do so periodically.
> 
> I think a difference is that a lot of that is subconscious.
> Programming should be much more intentional. (Actually, come
> to that, what we do in life should be more intentional.)

Dunno that our mode of usage makes a difference here.  It may be that the 
modes most used by the subconscious mind are the most effective/efficient; 
after all, most of our subconscious processes have lots of experience in 
unmonitored mentation, and so has had the opportunity to weed out modes 
that don't work as well.
 
>> How about applying these to programming.  I think that
>> perhaps the notion of creating a test for the code in
>> parallel with the code itself is akin to the reality
>> check we ordinarily do.
> 
> (If that check is as intentional as TDD requires.) Yes, I like
> that idea.  Good comparison.

TDD == Test Driven Development (guesses of the top of his head...  <grin>)?

Actually, there's more to it than that, I think.  If you can create a valid 
test for the code you write, then you have a grasp on what (you think) the 
code is intended to do.  But how do you know that what you think is valid 
in terms of the eventual application of the code?  It not, the tests may be 
irrelevant, or even downright contra-indicative?

I would think that a good strategy would be to create a "use" environment 
along with the structure of the code itself, where the former would have to 
fully support the tests written to vet the latter.  I've been privy to the 
users view of applications in business, specifically in accounting, and 
I've heard the horror stories of software that didn't accommodate the 
realities of actual usage in the clerk's (hen-pen?  lol!!!).  Best guess 
was that the software was written to accommodate an ideal usage environment 
provided by the management level specifications.  As one could imagine, 
those were the only specifications available, and I suspect that this is 
common.

There are, even in my own severely limited experience, always the situations 
where one posits impossible conditions (things that cannot happen).  Those 
are theoretical considerations, of course; things that should not be 
possible.  Yet all too often the unthinkable happens, and for reasons and 
in ways not previously envisioned.  I'm well aware that this is part of 
'Programming 101' in the view of most programmers, but it continues to be a 
problem (security holes, etc).

So, it seems to me that a significant part of the design of a software 
package should be a careful and thorough evaluation of all the ways its 
usage could be misused and abused, and that should take place right along 
with the development of the design itself.  This is, in point of fact, a 
significant difference between the behavior of a mature adult and the 
behavior of the immature adolescent.  Not that the adolescent is stupid, 
just inexperienced.  Programmers are not, or certainly should not be, 
inexperienced, at least in that regard!
 
>> I think that having several different teams taking different
>> approaches at different points has advantages.  I
> 
> If one can afford the resources, yes excellent.

Another thought:  modularization at several levels.  Stand-alone modules 
that are capable of gracefully handling input of any kind, where the 
default (kind/style of) input is what is expected.  I get this from both 
general and specific (computer) experience.  One of the things we do is to 
discover our capabilities and our limitations (the latter inevitably, one 
way or the other... <grin>).  Our capabilities we eventually hone into 
skill sets, which are successful to the extent they can be applied in a 
wide variety of situations.  One or more of these are generally used to 
support our livelihood.  A skill set becomes a reality stream in its own 
right (think like a ......), and very many people manage to allow it to 
become primary (can't stop thinking like a .....).  You get the idea... 
<grin>

Of course, the whole idea of *NIX itself is just that:  lots of tools and 
utilities that can be assembled to form a process... (sits thinking...are 
there UNIX utilities that can't be piped?  If so, what and why not....).  
Ultimately, *NIX wins simply because it most closely emulates how most of 
us do things anyway:  we assemble our skills on an ad hoc basis and muddle 
through our lives, hoping in the process to expand our skills and our 
awareness of our limitations in the process.

Now, the degree to which modularization is extended into some number of 
levels is a matter of choice, I would suppose.  But one things seems clear:  
getting a discrete module to be bullet proof should be a hell of a lot 
easier than getting an entire application to that point.

I'm prepared to learn that I've just re-invented part of the second mandated 
lecture from Programming 101, of course.  In any case, I've showed how our 
understanding of our lives in general can be applied to programming.  Which 
was the purpose of this response... <grin>
 
>> So, a definition of programming might do well to speak to
>> these views as well.  Maybe programming is getting a computer
>> to perform as desired, to produce what is wanted from it.
> 
> I sometimes tell people my job is "Training Silicon Lifeforms"!

And wouldn't you be shocked to eventually discover that you were right!!!  
What are the chances that alien life will be discovered right here in our 
own backyard, that what we thought were micro computers are actually nano 
beings!!  ROFL!!!!
 
>> Maybe programming is writing computer programs, and
>> all the rest of this is just common sense;...
> 
> That, too.  I doubt we can derive a one-liner (or even a para)
> that fully describes--let alone defines--programming.
 
True enough, I think.  At least it's arguably true of life in general.

Good discussion!

Bill Tallman
-- 
Registered Linux User: #221586
Mdk-9.0 and Slackware-9.1
A Luxuriance of Linux!!!

"William D. Tallman" wrote:

>>>> *IS* reality really in the mind of the beholder,
>>>
>>> It's the internal representation that is the reality.
>>
>> Ah, we disagree, then.
> 
> As an accultured species, we are wont to describe reality to
> ourselves and others in great detail, and science has repeatedly
> pointed out that we don't know very much at all about what we
> think we're discussing.

So true!  However, as you touch on later wrt shared internal models,
we share a great deal of the *experience* of that external world
and share it incredibly precisely (I'm referring to scientific
experiments, e.g., which return identical and precise results no
matter who does the experiment or where they do it).

Once we go beyond solipsism, these precisely shared experiences go
a long way towards suggesting the consistancy (persistance, as
another poster put it) of the "real world".

> As science does not use the term "reality", I go with common usage
> and reserve it as a human artifact;

Okay, at least I'll understand what you mean when you talk about
reality.  I'm very much a "map is not the territory" kinda guy, so
(as I've said earlier) I'm not happy calling that map by a term I
reserve for the territory.  Science may not use the term, but I sure
do, and it means, basically, "what's out there".


>>> ...our perceptions, within their limitations, are pretty good.
>>
>> ...law enforcement people are quite familiar with what bad
>> witnesses people make--no two will "see" the same thing.
> 
> It's not what we see, it's what we remember that is the major
> source of this problem.  Under hypnosis, we recall very much
> more than we would otherwise believe we actually know.

(Hypnosis has also brought out false memories, though.)  I re-read
a short article I earlier referred to, and I'm going to have to
disagree that memory is the problem.  *Perception* is very much the
issue here.

The experiment went like this: You are a member of a group that is
going to be shown a 60-second video displaying two teams consisting
of three members each.  One team wears white shirts, the other black.
They will be passing two balls amongst themselves (article is not
clear on whether passing can go from team to team or only within).

YOUR MISSION is to count the number of passes made by the white team.

At the 35-second mark a gorilla (man in suit), comes into the scene
and stands around waving his arms for 9 seconds and then leaves.

As many as 50% (!!!) of test subjects do not see the gorilla, EVEN
when asked if they saw anything unusual.  I forget the term used by
the article for the phenomena--my video game buddy and I refer to it
as "target fixation".  (-:

So, no, it ain't just memory that's faulty.  It's perception itself!


>> I would say there is one reality--dimly and individually perceived.
> 
> Here, I would not use the term "reality".  [...] I've used the term
> "environment", because I'm talking about what is incident upon us.
> We can also use the term "cosmos" to speak of the general totality
> of existence.

Stubbornly, I like "reality", but "environment" and "cosmos" are
also good.  I think we know what we mean here.


>> Reality == Fantasy ??
> 
> Fantasy is one form of reality.

Agreed, but that's the conundrum, isn't it.  Saying that gives you
the odd equality quoted above.  There is also an element of play--
sane people know the difference between fantasy and, um, reality.

Those who don't live in a different perceptual world.

> But I understand that the cultural tradition strives to limit the
> sort of mental constructs that are acceptable by asserting that
> fantasy and reality are mutually exclusive.

[shrug] Can't say any of that means anything to me.  Reality (to me)
comes from "real world" and LotR just ain't "real world".  I find
nothing traditional or socially limiting in the distinction.


But, let's move into..

>> [Programming]
>>
>> Programming should be much more intentional.
> 
> Dunno that our mode of usage makes a difference here.  It may be
> that the modes most used by the subconscious mind are the most
> effective/efficient;

Definitely some truth to that!  One can sometimes solve a problem
by NOT thinking about it and letting the subcon level munch on it
for a while.

> TDD == Test Driven Development

Yep.

> Actually, there's more to it than that, I think.  If you can create
> a valid test for the code you write, then you have a grasp on what
> (you think) the code is intended to do.  But how do you know that
> what you think is valid in terms of the eventual application of
> the code?  It not, the tests may be irrelevant, or even downright
> contra-indicative?

Pretty much the exact conclusion reached in the TDD thread next door!
(Reached, that is, by some people--others disagree.)

> I would think that a good strategy would be to create a "use"
> environment along with the structure of the code itself, where
> the former would have to fully support the tests written to vet
> the latter.  I've been privy to the users view of applications
> in business, specifically in accounting, and I've heard the
> horror stories of software that didn't accommodate the
> realities of actual usage in the clerk's (hen-pen?  lol!!!).

Indeed!  One of my big "meta-rules" is that software is for humans,
not computers.  You do NOT design code to be convenient for the
CPU--it doesn't mind the extra work (far as I know, but if it does,
tough, it's my little silicon slave and it'll darn well do what I
tell it to do).  You design software for the **users**.

Speaking of use environments, I find my GUIs begin to evolve and
become much better once the product grows to the point I can begin
simulating actual use.  I run a LOT of user-level tests, and the
more heavily a fixture will be used, the more heavily I test it.

If using a common fixture becomes tedious to me (test after test
after test after test....), I know it will to the user.  So I make
it better, easier, faster.  But always, I try to think like a user
when I design the system.

> Best guess was that the software was written to accommodate an
> ideal usage environment provided by the management level
> specifications.

Or designed by someone who didn't think much about it or who used
inappropriate criteria in designing or who just didn't talk much
(or more importantly, LISTEN much) to the users.

Programmers are often not socially oriented or socially skilled,
and user requirements gathering can be a VERY social task.  Yourdon
(and co.) wrote a good book, "Structured Analysis & Design" that
talks a lot about this aspect of system design.


> There are, even in my own severely limited experience, always the
> situations where one posits impossible conditions (things that
> cannot happen).  Those are theoretical considerations, of course;
> things that should not be possible.  Yet all too often the
> unthinkable happens, and for reasons and in ways not previously
> envisioned.

Very true.  This is one reason, for example, when testing to see if
a number sequence reaches a certain value, I NEVER EVER test for that
specific value.  I test to see if it's over or under or equal-to-or-
under or whatever.  That way if the "unthinkable" happens causing the
sequence to skip a step, I don't risk missing the loop termination.

> I'm well aware that this is part of 'Programming 101' in the view
> of most programmers, but it continues to be a problem...

Lotta crap programmers out there.  :-(

> So, it seems to me that a significant part of the design of a
> software package should be a careful and thorough evaluation of
> all the ways its usage could be misused and abused, and that
> should take place right along with the development of the design
> itself.

Absolutely!!!  "Go ahead, TRY to break it!" should be a big part
of everyone's development cycle.


> Another thought:  modularization at several levels.  Stand-alone
> modules that are capable of gracefully handling input of any kind,
> where the default (kind/style of) input is what is expected.

Yep.  That is a standard aspect of design, in fact.

> A skill set becomes a reality stream in its own right (think like
> a ......), and very many people manage to allow it to become primary
> (can't stop thinking like a .....).  You get the idea...  <grin>

Certainly.  This is why cross-training (on many levels) and inter-
disciplinary education are so valuable.

> But one things seems clear: getting a discrete module to be bullet
> proof should be a hell of a lot easier than getting an entire
> application to that point.

Generally.  If for no other reason than that there are so many more
"variables" affecting the final product.  I wrote just today that
programming is like writing a book where you aren't allowed one single
typo, spelling error or grammatical error.  Let alone that you have
to write a story that is logical and sensible.

Much easier to get a paragraph right than a novel!  (-:


>> I sometimes tell people my job is "Training Silicon Lifeforms"!
> 
> And wouldn't you be shocked to eventually discover that you were
> right!!!

[grin]

> Good discussion!

Very!!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

The gorilla video is available on one of the researchers' site,

http://viscog.beckman.uiuc.edu/media/sciam.html


Martin

Martin Eisenberg wrote:

> The gorilla video is available on one of the researchers' site,
> 
> http://viscog.beckman.uiuc.edu/media/sciam.html

ROFL!  Thanks!!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|