Dever wrote:

How do you I'm not in he higher-level languages and don't already have a job? And about reusing it, and I never said only used once. I said created to be used for the situation. Doing that creates a specific design. If for some reason the situation changes, then I can easily change the code to work with that new situation. As for not knowing what usr is going to be. usr is ALWAYS the mob that called the original proc. I'm sorry if you don't understand this, but I do.
You also said that safety checks are nesseicary. They can be, and I will use them is so. But to use them to protect agaisnt an impossible situation is ridiculous and ineffienct.

I'm not going to answer the first question, because it'd only make for more insult.

And about the reusing thing, you said you make it for a specific function, and talk about rewriting it later on. Well, if it's reusable, then you shouldn't need it to be rewritten to work with something else. Post [link] states that you write it for a specific purpose, and will re-write it if necessary. The only time to rewrite it would be during the refactoring process.

I'll point you to the Usr Unfriendly article.

Quote: "(Except usr could change to null if the mob it's pointing to gets deleted while the proc sleeps. Just keep that in mind every time you call sleep()--check usr again afterward to make sure it's still valid.)"

Quote: "So why isn't usr valid in movement procs like turf/Entered() or in mob/Logout()? The problem is that a player can be moved by other code in the game, not necessarily of their own free will, and they can be logged out automatically too. usr could well be null, or could be another player."

Safety Checks are really necessary. With the whole 'impossible' stuff, come on. Anything is possible without proper protection, usually. Like if a buffer overflow occurs, that can cause major security problems, but you can still protect against it from happening in the first place.

Also, as we get later on in the day you're spelling seems to be getting worse and worse. Might I suggest you use a spell checker or something?

Dever wrote:

How do you I'm not in he higher-level languages and don't already have a job?

The latter is clear from the fact that you don't understand the need for good design and think there's no such thing as a problem you can't anticipate. As for working with higher-level languages, I wouldn't be surprised if you've tried your hand at programming in some others, but based on this entire conversation you haven't amassed much experience in any of them.

And about reusing it, and I never said only used once. I said created to be used for the situation. Doing that creates a specific design. If for some reason the situation changes, then I can easily change the code to work with that new situation.

The only code that is easy to change is robust code. Brittle code is brittle precisely because it is written to so specific a situation that it will snap apart if something else changes. You talk about changing one part as if it's in a vacuum; it isn't. When you change one part of your code, particularly code that's been designed to work with other parts that are all a certain way, you'll have to change others.

What brittle code basically gives your program is a very delicate crystalline structure. Each individual section is linked to the others in very specific ways. Making any modifications is equivalent to sending shock waves throughout the structure, and it can shatter. Robust code is more like a flexible solid: the bonds between sections are forgiving and have a certain stress tolerance.

As for not knowing what usr is going to be. usr is ALWAYS the mob that called the original proc. I'm sorry if you don't understand this, but I do.

I'm afraid you don't even understand that. usr is the mob that called the original verb--and it may become null if that mob has been deleted, although in those cases often the entire verb-proc chain will fail.

You also said that safety checks are nesseicary. They can be, and I will use them is so. But to use them to protect agaisnt an impossible situation is ridiculous and ineffienct.

As I said before, and I'll say again, there are many situations you may deem impossible that are not so. I wouldn't suggest you defend against all of them, but it does not impact the efficiency of your code in any way to defend against some of them, nor to choose robust code over brittle code.

Assuming you had two programs with identical algorithms, one brittle and one robust, and ran them side by side, you might notice after a century or so that the robust one was lagging half a second behind. This is the "efficiency" you're fighting for: a truly worthless prize, not worth the sacrifice of stability. Those who truly understand code optimization know that.

Lummox JR

Kija wrote:

When I was giving this example, I was not speaking overall. I making a point that the electrician was not always going to be right. Once again, do not look at it so broadly.

But the broad picture is the whole point there. Of course anyone can make a mistake in an isolated individual case, but the big picture is precisely why all this stuff about robust code and usr abuse matters. Robust code recovers gracefully from that isolated mistake, and keeps it isolated; brittle code transmits it from one section to many others.

I understand your point of view, but that does mean I must agree that is the best way of doing things. Because I have a difference preference does not make me any worse, it is just different.

It does make you worse off. I know you don't see it that way, but then, you don't have to. All you have to do is stop trying to drag down others with you. What you don't know, you should not teach.

And no, you don't understand my point of view. To understand it, you'd have to grok the difference between robust code and brittle code, and why the difference matters. You don't understand that--not yet, anyway.

I was not trying to redefine the word abuse, I mean in the defination of the situation. You say that using usr in proc is "usr abuse." But someone saying usr abuse may not refer to using usr in a proc as abuse. This does not mean that the word abuse has a changed, but the sitiuation on which it is considered. It is rather "slippery" of you to try to warp my example. But you have already attempted to do so many times, so I am not surprised anymore.

I didn't say you tried to redefine abuse; I said you tried to redefine the term "usr abuse", which has a solid accepted meaning. And you're still doing it. The meaning hasn't changed.

I am not here to argue whether using usr in a proc is right or wrong.

No indeed, because you've been ducking that question by trying to pass it off as an opinion. If it's an opinion, it can't be right or wrong (a point for a separate debate), so you get a pass for teaching it to others. Well 2+2=5 is not an opinion, just a mistake, and putting usr in procs is also a mistake.

It is your opinion that using such methods is shoddy, so it is rather flawed for you to say that.

shoddy (adj.)

1. Made of or containing inferior material.
2.
a. Of poor quality or craft.
b. Rundown; shabby.

To put usr in procs when you can avoid it is poor craftsmanship, and there's simply no arguing around that. It transmits stresses throughout the entire call stack, to break at the weak point which is usr. In good building, the proc is designed to be somewhat independent, to rely only on the arguments its parent sent and not a value that has been passed through many unknown hands.

That usr is unreliable in procs is a well known issue, and therefore to do so is wrong. Therefore "shoddy" represents not an opinion, but a fact. An opinion would be to say: "I don't mind shoddy code." Which, in a sense, you have. (Actually you've more or less said "I don't think it's shoddy, so I don't mind it." The first part is a mistake and quantifiably wrong, the second an opinion. And since that opinion is based on a wrong conclusion, it is itself invalid.) And it's fine for you not to mind it, because you're the one who has to live with your own code (well, you and your players). But you shouldn't be teaching others, any more than a carpenter who uses splitting and damaged beams (or worse, can't spot the damage) should take on an apprentice.

Lummox JR

Kija wrote:

Yes, that is true, but the point was not refering to that. It was refering that just because you are more experienced does not mean others of lower experience cannot be right.

But where experience differs by several orders of magnitude, the inexperienced person cannot be right unless their idea is an innovation, or is in agreement with those who came before. Usr abuse is not an innovation; it is a mistake, and is discounted so by those who have experience.

No, I do understand. You may have experience in programming, but unfortunatly that does give you the ability to read minds, so do not say such things. What you cannot see, you should not claim.

All you've demonstrated that you understand is that I have something to day. You don't really understand the reasoning behind it. If you did, you would either agree with it or be able to present counter-arguments in kind.

It seems you have a quite tendecy to completly miss the point. Usr abuse has a solided accepted meaning, but instead of clarifying that it is abuse to usr in procs, if you just say "usr abuse" it can many different meanings of where usr is abusive depending who you are. So saying "usr abuse is bad", does do not do much unless you state where it is abusive.

You just agreed usr abuse has a meaning, and then denied it. It does have a meaning, and that meaning is that the use of usr in procs is usr abuse. This is the well-known meaning and it does not vary by circumstance. What varies is only the degree to which you're willing to live with usr abuse.

I am not ducking anything. Thank you for cutting the rest of the paragraph so that your last comment would actually seem right. Hm, removing parts of a paragraph in order to insult someone. You are sinking real low.

I was snipping parts I didn't find relevant to the issue. How exactly is that an insult?

I know the definition.

No, you don't. You just said above that it varies, which it does not. The definition is solid. The only thing up in the air is how much usr abuse you'll tolerate.

Again, you missed the point. It is your opinion that it is of poor quality.

Quality is a judgment more of fact than opinion. A 200 thread-count sheet is of better quality than a 100 thread-count. An item made of sturdier materials that is otherwise identical to another is of better quality. You keep trying to push this into the realm of opinion, but it just won't go there.

But as I already said, I am not here to argue about usr, I did that a long time ago. I only posted once when someone falsy accused me of something.

Indeed, you were accused of twisting people's words. I think it wasn't so much that you did that, but that you didn't understand what was said and didn't respond to their actual point. Of course in this case, you tried to twist "quality" into "opinion", so maybe Audeuro had a point there.

Lummox JR

Kija wrote:

But they can still be right. And that was the point.

They can only be right if they innovate or agree. Since implementing a known mistake is not innovation, in this case you can't be right.

I will repeat myself once more. You do not have the ability to read minds. I understand it very clearly and your reasoning behind it. If you wish to view my points behind my preference, then reread the comments posted on the topics in which there were presented, not here.

If you truly understood my point, then respond to the arguments instead of trying to put it into the context of opinion or redefinitions.

usr abuse is wrong because:

1) It makes code brittle, and therefore a) very difficult to maintain, and b) unable to cope with problem situations gracefully.
2) It often responds unpredictably in situations where the author did not anticipate conflicts.
3) There is always a simple method of avoiding it.

I did not deny usr abuse has a meaning, but you cannot assume everyone sees usr abuse to mean putting usr in a proc. Which therefore, them saying usr abuse would be different if you said it. And so it is an unreliable term if you do not specify where it is abusive.

You've just said again it has no meaning. If everyone can put their own spin on it to mean completely different things, common meaning is void. Well that's not the case. It has a meaning, it's just that some may view usr abuse as more acceptable than others. The fact of usr abuse doesn't change depending on how you look at it; the only thing that changes is your willingness to live with it. To the extent that perspective is an issue, it's in how seriously you view the fault, not whether the fault exists.

If a house has a cracked support beam, it is no less cracked for one inspector vs. another. Where they may differ is in their opinion of whether it's a serious problem, and how to remedy it if necessary. "Cracked beam" does not have multiple meanings, and neither does "usr abuse".

It is an insult because the issue is not putting usr in the proc. You were cutting out my paragraphs inorder to twist what I was really saying. A very low thing to do. I have said that many times and even in the paragraph you cut out. Instead of cutting them out, reread them.

Again, I cut them out because they didn't really add anything to the discussion. The ones you quoted last time, I snipped again because they were still irrelevant. I feel they need no response.

I meant I know the definition of shoddy, which you insisted on pasting the meaning, another insult to me.

Not at all; I was just clarifying that it has a concrete meaning which is outside the scope of opinion.

I have already push it there, and it is an opinion. Just because you disagree does not make your side a fact.

Claiming a fact is an opinion doesn't make it one. (And as much as you've harped on me for snipping sections of what you wrote, why haven't you come up with a retort to that 2+2=5 bit yet? That cannot be called an opinion; it is simply wrong.) There are opinions involved here, to be sure, but in a different context. Usr abuse is not a matter of opinion; it's either there or it isn't. What's a point of opinion is whether you mind it or not.

You're trying to call the whole thing a matter of opinion, because it neatly escapes the whole right/wrong issue. The only actual opinion you've stated is that you have no objection to usr abuse. Fine, but don't teach it.

Lummox JR

Kija wrote:

In the case in which I brought it up it is right.

But that case is irrelevant to the discussion at hand.

I did not say it did not have a meaning. But "cracked beam" is far different than "usr abuse." Cracked is concrete, it is there. Abuse is not.

Of course usr abuse is concrete. Since usr abuse is defined as the use of usr in a proc that is not nominally considered a pseudo-verb, it too is concrete. To argue otherwise is to argue that no definitions have meaning.

Some may consider shooting animals, "gun abuse." But if you went up to a hunter and said "I believe gun abuse is wrong." He may say, "I agree." not understanding what you believe is abuse is different. Concepts such as abuse is not the same as something as concrete a cracked.

But "gun abuse" is a phrase which could have different meanings to different people. "usr abuse" is not one of those phrases; its definition is locked down, commonly agreed on. That you wish it to mean something else does not change its meaning.

Peta likes to pull this same kind of trick. They believe animal abuse is wrong. Well sure, pretty much everyone does. But they try to push the concept of animal abuse to killing any animal under any circumstances, including raising farm animals. Is that animal abuse? Of course not, not by the accepted definition. Locking a dog outside for 2 days in temperatures below freezing is animal abuse.

In Peta's case they want the definition to be extended to something more inclusive. In your case you want something less inclusive. Both are trying to twist the meaning of a phrase which is already pretty well set in stone.

The scope opinion is whether it is shoddy or not. By defining the word, it does not change this.

That usr abuse constitutes shoddy code is inescapable fact. Opinion is whether you mind that said code is shoddy. (And whether you mind the perception that you're okay with shoddy code is a whole different thing. I sense you do mind that one, yet it's the logical consequence of your statements.)

If you have been reading what I said, I did. You keeping saying it is a fact, but the point is I believe to be a matter of opinion. So saying 2+2=5 does nothing but only state that you believe it is still a fact.

Yes yes, but if you believe that 2+2=5, you're simply wrong. This is not a matter of opinion. Likewise the fact of usr abuse is not a matter of opinion; its existence is either true or false.

I believe the subject is of opinion.

Opinion is involved, but not in the central fact of whether usr abuse exists. Opinion only comes into this in that you can have your own feelings on whether it's okay or not. You feel usr abuse is okay. Fine, you're the one who has to deal with that, as long as you're not teaching that to others.

You've been trying to argue that your being okay with usr abuse is equivalent to usr abuse being subjective. usr abuse is objective; it can be (and has been) objectively defined and measured. There are also objective reasons it's a bad idea. However, it is possible to have a subjective belief about whether or to what extent those reasons matter. Your belief, apparently, is that they do not.

Lummox JR

digitalmouse = GOD of this thread, since it's getting way out of hand. if you kids are going to argue, please do it in a chatroom or IM system of your choice.

thread closed.