Re: Philosphy of programming
From: Programmer Dude (Chris_at_Sonnack.com)
Date: 02/27/04
- Next message: LRW: "good ASCII editor with features?"
- Previous message: TLOlczyk: "Re: PHP - I give up."
- In reply to: William D. Tallman: "Re: Philosphy of programming"
- Next in thread: Martin Eisenberg: "Re: Philosphy of programming"
- Reply: Martin Eisenberg: "Re: Philosphy of programming"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 27 Feb 2004 14:19:52 -0600
"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 | |_____________________________________________|_______________________|
- Next message: LRW: "good ASCII editor with features?"
- Previous message: TLOlczyk: "Re: PHP - I give up."
- In reply to: William D. Tallman: "Re: Philosphy of programming"
- Next in thread: Martin Eisenberg: "Re: Philosphy of programming"
- Reply: Martin Eisenberg: "Re: Philosphy of programming"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
