Re: copying arrays



Dan Bensen wrote:
Alan Manuel K. Gloria wrote:
> In my experience it's quite rare to have to have to *copy* a
> sequence. If you're manipulating an array, why would you want to
> retain the previous version? What is it that you are trying to do?
> In general, it is usually very rare that you have to actually copy
> the sequence.

Dan Bensen wrote:
> In a game, you might want to pass the state of the game
> (e.g. the board in a board game) to a computer player
> so it can decide what it wants to do. The safe way to do that
> would be to pass the player a copy, so the player doesn't
> corrupt the game. Often the player will destructively modify
> the board, but undo all its changes at the end. With a copy,
> you can also check the player for correctness by comparing
> the final state of the player's copy with the original board.

Kent M Pitman wrote:
> Warning: The "rant" below might or might not be relevant to Dan's
> remarks directly. So don't take this as necessarily responding to
> his particular situation.
With all due respect, Kent, that's exactly how I take it.
You directly addressed me and my comments in a highly critical way.

That reaction is understandable given the use of the "u"-word, but if one thinks on it, a public forum invites public rants and ruminations merely triggered by one's actual question or comment so one might not in fact want to take the "u"-word literally. When coupled with an explicit and it turns out precisely accurate disclaimer not to take the "u"-word personally, methinks a simple "nice rant, but as you so graciously allowed, not relevant to my requirements" would suffice.

We call these things "articles". What if we never used the words "you" or "I"? I have gone back and re-edited to get those words out and was impressed at how much less inflammatory the same content seemed. Of course my general intent here on c.l.l is to kick off entertaining flame wars, so...



> it's no "more safe" to call a function that's supposed to
> add 1 to a number only to find that it subtracts 1.
This is ridiculous. In many cases, one glance at (incf x)
will be enough to determine whether it's correct.
The same cannot be said for dozens or hundreds of lines
of tree-searching code.

> A program that does not understand its contract is unsafe.
> If a program does understand its
> contract, it can use side-effects safely.
A buggy program is also unsafe, even if it understands its contract.

....and...

There's also a strong question of whether human programmers are
infallible and whether bugs should be guarded against in a modular way.

....and...

I don't think it's code, I think it's a simple fact. You can't teach
people to be perfect. If your code is in production use, it may be
safer for it to fail gracefully instead of blindly allowing
every part of the program to change important data.

I won't bother with the disclaimer. I see a gray area, and I am not just bullsh*tting as usual, this came up in code reviews on projects in Tall Buildings, and it addresses what I heard Kent saying, which of course did not apply to anyone's actual situation as Kent guessed was possible. Where was I? Oh, the gray area.

Correctimundo, defensive programming (DP), folks (esp. moi) screw up. But then we have paranoid programming (PP), referring of course to Kent's straw man, not anyone's particular situation. I'll be using DP and PP to keep down the message length, necessary because I will be continually reiterating that nothing I am saying or have ever or will say relates to anything else. So...

The problem with PP is that, if our assumption is that people cannot program, then we cannot program. It is one of those complexity deals. That's wrong, let me try again: we cannot /in our programming/ make allowances for programmer fallibility. It's a slippery slope. Once we make that bet, er, hedge, where do we stop? If we want to say this bit of code might be flawed or this programmer might be a loose cannon, where does the descent into paranoia halt?

The whole TDD thing (test-driven development) says, right, we screw up a lot, but let's work out a way that we can code with confidence anyway -- we'll add a fixed percentage of development time to produce a great honking regression test and bank on that.

But it is a gray area. I do a /lot/ of defensive programming, but more in the sense of embedding TDD in the form of assertions to flush out likely faults. If a TDD-based system completes a test run it is correct, if my programs run at all they are correct. If the latter ever happens, man am I going to party.

Note that assertion-sprinkling does not mean I am /programming for incompetence/, tho of course (assert nil) is code. I am talking about the functional algorithm having code that reflects the fact that I might have screwed up. There's an infinite recursion if I ever saw one.

Note again that this rant was merely triggered by the comment about programmer fallability, and in no way ... ah, f*ck it, this is Usenet. (Yes, the espresso just cut in.)

kt

--
http://www.theoryyalgebra.com/

"Algebra is the metaphysics of arithmetic." - John Ray

"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts

"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz

"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen

.