So you'd rather have to think about EVERY SINGLE PIECE OF CODING in your game EVERYTIME you make something new, say an NPC or moving obj, instead of making it robust to start off with?

Where's the logic in that?

As for you efficiency thing, it isn't less efficient. Because you'd waste at least a few minutes of your own time in thinking about EVERY THING IN YOUR GAME each time you add something. As opposed to a virtually 0 (unnoticable) lag.

Dever wrote:

'So what you're saying is, 1 proc doing 3 things, is less effient (sp?) than 3 procs doing 1 thing?'

I did not say a proc doing multiple functions, but a proc wokring in mutliple situations. If you know the current situation of how its being used, then code that way.

And watch it fall apart if the proc is used in other ways, or if one of the many procs in the call chain changes. Worse yet are the problems that appear in those circumstances but you don't see, because they don't affect anything too seriously until another part breaks. Having one damaged beam in your house is probably not going to bring it down; having many will void your insurance.

Lummox JR

'If you think you're capable of catching every one of those changes and predicting how each will affect every single piece of code (and how changes you must make to cope will affect other code in turn), you have no experience nor any ability to make a good guess.'

Maybe you don't know how it works because your robust design is the true flaw. I code things for their specific function. I know exactly how it is going to work. I have plenty of experience and very well know what I am doing.

Dever wrote:

'If you think you're capable of catching every one of those changes and predicting how each will affect every single piece of code (and how changes you must make to cope will affect other code in turn), you have no experience nor any ability to make a good guess.'

Maybe you don't know how it works because your robust design is the true flaw. I code things for their specific function. I know exactly how it is going to work.

No, you know only how it is going to work in the local section where you placed it, under ideal conditions you picture in your mind while writing the code, without regard to what problems could derail either the proc you just wrote or the ones that called it.

I have plenty of experience and very well know what I am doing.

You may have spent a lot of time programming (based on what I consider "a lot", I doubt it), but you clearly have no experience to speak of. If you did, you'd have run into enough snags debugging programs by now to have learned a thing or two about how to avoid obvious problems. I'm not here to pull rank on you or put you down for inexperience, but rather to take you to task for embracing ignorance. There's a lot you don't know yet, and you'll never know it if you're not willing to learn.

Lummox JR

Dever wrote:

'You speak philosophically on a subject you clearly know nothing about. You know nothing about the dangers of brittle code, and as little about efficiency. It's called brittle code for a reason: It's easy to break, either by a user doing something unexpected or something else smashing into it.'

My code is not brittle. It runs completely stable for the situation it was created for, and as long as thats what it is used for.

You've failed to grasp this concept here. Brittle means that it's prone to break. It may be stable as-is but may just as well fail in the event of some unanticipated user input, and maybe for reasons completely unrelated to the proc itself because another piece of brittle code gave it bad input. Moreover, it's brittle in that it's hard to move or change--or move or change anything around it--without breaking. The latter difficulty is more common; it's like trying to rearrange a bunch of tall glass statues that stand very close together, and having to maneuver around them.

'You've obviously never handled or had to debug any project big enough to do more than say hello.'

Do you really believe that? Actualy thinking that would be definite igorance on your part.

A slight exaggeration, but only slight. It's not possible for you to have written even, say, a simple RPG with the design philosophy (or rather, the total lack thereof) you defend, without running into debugging issues far more frequently and for sillier reasons than you otherwise would. It may be that you've had all those debugging headaches, yet you shrug it off as normal because you've never worked with code that didn't have those sorts of problems.

Lummox JR

Dever wrote:

'You've failed to grasp this concept here. Brittle means that it's prone to break. It may be stable as-is but may just as well fail in the event of some unanticipated user input, and maybe for reasons completely unrelated to the proc itself because another piece of brittle code gave it bad input. '

Stop assuming you know how I do things. I have explained this before, and I guess again. Unanticipated input is impossible, it can't happen. Everything is coded specificly for its function and NOTHING else. Maybe this would be possible under your design, but not mine.

You speak as if your design is absolutely perfect. You also state that unanticipated input in your code is impossible, yet, as I recall, NOTHING is impossible. Things can be coded for specific reasons, and to act under strict conditions, yet, they can be play a big role in...let's say a game crash. All because of brittle code.

Also, you constant insults are tiring.

He's not insulting you, he's stating facts.

Why don't you try to put out actual points to why your design is somehow better instead of relying on your exgerated put downs.

Use Forum Search.

Definitely looks like this has gone beyond a code problem, guys.

Shouldn't this be carried on elsewhere?

Dever wrote:

'You've failed to grasp this concept here. Brittle means that it's prone to break. It may be stable as-is but may just as well fail in the event of some unanticipated user input, and maybe for reasons completely unrelated to the proc itself because another piece of brittle code gave it bad input. '

Stop assuming you know how I do things. I have explained this before, and I guess again.

Indeed you do. When one abandons logic, guessing is inevitable.

Unanticipated input is impossible, it can't happen.

Interesting worldview you have there. Which part exactly is impossible--you failing to anticipate an action or someone actually doing something you didn't expect? Both are highly amusing, but I think the latter is funniest: "If I cannot imagine it, it cannot be."

No wonder you don't get the importance of robust programming. You can't imagine it's useful, ergo it must not be. You can't imagine you're not an experienced programmer, ergo you must be.

Everything is coded specificly for its function and NOTHING else. Maybe this would be possible under your design, but not mine.

It must be nice to live in a world where the chance of breakdown is zero. Clocks and cars would never need maintenance, and medical catastrophes could never occur. Indeed, if your ability is as you say, I'd like you to be my mechanic, my doctor, and my financial planner. Sure, you're willing to cut corners, but I guess that doesn't matter if you can't do anything wrong.

Also, you constant insults are tiring. Why don't you try to put out actual points to why your design is somehow better instead of relying on your exgerated put downs.

I'm not insulting you, but I am trying to direct you back to reality. The reality is, you don't know as much as you think you do, you have far less experience than actually counts, and your insistence on bad design is proof of both. Experienced programmers don't speak as you do; they've been hit over the head with enough of their own mistakes to know better. Therefore your experience is limited at best, and indeed no matter how many hours you rack up programming you'll never hope to gain actual experience until you're willing to learn something about it.

Only a liar or a great fool can say they never make mistakes. On the assumption that you are neither, then you are casually overlooking your own fallability to try to make a pretty flimsy point. It's okay to be fallable; it means you're human.

Lummox JR

Dever wrote:

Then do you think maybe that it is possible that Lummox is wrong?

On some subjects, sure. On this one, not a chance. I've been programming for roughly 25 years now; I have a pretty good grasp of the subject and know what I'm talking about.

'I'm not here to pull rank on you or put you down for inexperience, but rather to take you to task for embracing ignorance.'
'You know nothing about the dangers of brittle code, and as little about efficiency.'
'You've obviously never handled or had to debug any project big enough to do more than say hello.'

Those are obvious insults. And are difinetly not facts.

You're taking them as insults, but they're not intended that way. Indeed in that first sentence you quoted I made it quite clear that I'm not in this for a putdown.

But based on what you've been saying, clearly you think 1) you've got a lot of experience, 2) you understand robustness and efficiency inside out, and 3) you can't make mistakes. All of those are wrong.

1) Experienced programmers simply don't insist on bad design. Quite the opposite--they know what works and what doesn't, and they also know what's safe and what isn't. More experienced programmers inevitably put in more safety checks and robustness, not less. Code I've seen from people who know far more than I do has also borne out this tendency: they ASSERT() the living crap out of their code. That's just one of many aspects of robustness; professional programmers learn to rely on it, because they know they're not perfect and neither are their users.

2) If you understood the value of robust design, you simply wouldn't question it, let alone argue so strongly against it. This also takes us back to 1), since you couldn't have run across any serious debugging challenges yet. Furthermore if you understood efficiency, you'd realize how very very little of it you gain from slipshod code vs. robust code. Optimization is a very interesting subject, the realm of intermediate programmers and above, and you my friend are not one of them yet. I hope you'll grow of course, and someday become as good a programmer as you think you are now. See 1).

3) The idea that you are omnicient and infallable is clearly ridiculous. Therefore, you will make mistakes, just as we all do. Therefore, not planning for those inevitable mistakes is a bad idea--which again you would know if you had any significant experience. See 1).

Not insults, just hard truth. If you want to think you're the best programmer that ever was or will be, that's just dandy, but you'll learn nothing that way, and what's more you'll only screw up others if you pass that along.

Lummox JR