But according to the majority here, nothing is impossible, so therefore the electrician can still make a mistake unseen.
If you have listened to anything I have said, it is that I believe in all points of view. Which means I have no desire to teach anyone anything on the basics of what I believe to do, but rather than on what they could do. Any person wanting to learn anything would have their own preference of doing things.
"I am vastly more experienced, so I am right." Rather you change the first phrase or not, the poor approach remains the same. And that is a very large exaggeration, and your tendecy to refuse to say otherwise only shows my point.
"Well it works for me, so I'll keep using it." Do not put words in my mouth. I never said that, for if you have been listening to anything I have said, you would seen plenty of points of why I do somethings the way I do. And you would also know that since I believe in all points of view, that would obviously that I am not so concrete to not change anything, but in your so desire to continue to insult with anything you can, you will refuse to see this as well.
Nor do we need more people who just insult others simply because they have a different way of doing things. I do know what I am doing, and you saying otherwise does not change that. But ofcourse, you have to insult me though. Do not teach others to opress; do not teach others one view. There are many ways of doing things.
'That's actually not a bad analogy, except for the assumption that the roof is as stable as all that. The thinner your roof, the less you can expect it to survive a stiff wind.'
Once again, you are the one avoiding the actualy point. My story had nothing to do with the roof. What you were suppose to understand is that the possibility of rain was nearly impossible so carrying around an umbrella is pointless, but yet you dodged that and tried to talk about the roof instead. | |
Kija wrote:
But according to the majority here, nothing is impossible, so therefore the electrician can still make a mistake unseen. Absolutely. But the master electrician's unseen mistake will have little or no impact. The intern's unseen mistake will have as much impact as he was allowed to influence the design. That is, if the intern was working alone and did not do all the safety checks and such a master electrician does, his mistake will have a greater impact, pretty much 99.999% of the time. If you have listened to anything I have said, it is that I believe in all points of view. Which means I have no desire to teach anyone anything on the basics of what I believe to do, but rather than on what they could do. Any person wanting to learn anything would have their own preference of doing things. That's just like saying you don't believe in logic or truth. If you don't, then you're no programmer. 2+2=5 is not a point of view; it's just wrong. Teaching 2+2=5 as a possible point of view won't get you hired as a math teacher anytime soon, except in California. "I am vastly more experienced, so I am right." Rather you change the first phrase or not, the poor approach remains the same. And that is a very large exgeration, and your tendecy to refuse to say otherwise only shows my point. If that were to be an accurate paraphrase of what I said, you'd have to include a middle section: "...so in matters of overall design, good practice, and safety,..." Experience teaches those things. And the fact remains that I have a very great deal more experience than you do, as indeed do many other developers on BYOND. Nevertheless, I've not relied on that as the entire basis (or even most of it) for the argument. Rather I've supported it with further arguments about design issues that can and do arise. "Well it works for me, so I'll keep using it." Do not put words in my mouth. I never said that, for if you have been listening to anything I have said, you would seen plenty of points of why I do somethings the way I do. And you would also know that since I believe in all points of view, that would obviously that I am not so concrete to not change anything, but in your so desire to continue to insult with anything you can, you will refuse to see this as well. To say you believe in all points of view is just a way of saying you don't want to believe you can be wrong. It's one of those easy cop-outs to get out of a debate without having to present an argument of any substance. There is simply no substance to support the notion that usr abuse is a good thing. Nor do we need more people who just insult others simply because they have a different way of doing things. I do know what I am doing, and you saying otherwise does not change that. Again, that's not an insult. You don't know what you're doing--yet. That's because you haven't learned any better yet. I believe you could be capable of learning that, if you would be willing to do so. You're sticking with something because it's easy for you, because it's comfortable, not because it's sound. Do not teach others to opress; do not teach others one view. There are many ways of doing things. Teaching that right and wrong exist is not oppression; it's reality. And while there are many ways of doing many things, there are also many things that can only be done one way, and many more that can only be done properly in one or a few ways. Edison went through a thousand prototypes before developing a stable light bulb; clearly that was something where most approaches turned out to be wrong. Industrial machinery is designed so that on failure of a component, it will turn off the entire machine; to do otherwise is wrong, because it's a huge safety hazard. People's limbs aren't at stake here, but this "nothing is absolutely true" stuff is no basis for an argument--only an attempt to slip out of making one. Lummox JR | |
Dever wrote:
'That's actually not a bad analogy, except for the assumption that the roof is as stable as all that. The thinner your roof, the less you can expect it to survive a stiff wind.' Well in fairness, you did mention the roof. You said if the roof was ripped off and it happened to start raining, then the umbrella would be needed. And the roof is indeed important. As for rain being "nearly" impossible, well, they still put a roof on any home built in the desert, because sometimes it rains even there. (And appropriately enough, when it does rain it's a downpour.) Rain happens. It's beyond your control. So are user mistakes (or exploits). What is not beyond your control is the ability to handle at least some of the problems that can come up. Lummox JR | |
Lummox JR wrote:
Dever wrote: I did not say 'ripped off', I said magickly dissapear. And the only reason I mentioned it as being there is because I knew you would try to say that the roof might not be there. And the reason I said magickly dissapear was to stress the point that its not going to. And I never you shouldn't handle problems are have no safety. What I have been saying is, it is not nessicary to put safety design to protect agaisnt an impossible situation. Don't implement just because that situaion might be possible in the future. When it becomes possible, then implement. Effiency.. | |
Once again you are missing my point. My point was that sometimes the intern can be right compared to the electrician did. The entire point was that just because you are more experienced at something, does not mean that someone of lower experience will never be right.
No, that is not saying that. I am saying that there are many ways of doing things, and no one way should ever be taught. If you insist of completly changing what I mean, then you obviously have no tendecy on having a normal conversation even on this. Another attempt to put down something; a rather poor one too. The fact is, you have relied on it. It was pointless to ever bring up in the first place, and the fact that you did only shows that you are. If you truly believed in your points, you would have no need to bring any such comments up. I do not believe I cannot be wrong. I do have preferences, but I am not one so foolish to say that all other views are wrong. This is not a cop-out; it is that you are very rigid. My arguement has plenty of substance, and I have plenty of points, yet you ignore them and try your weight on another poor and warped example. Again, it is an insult. Your constant bashing that I do not anything is not acceptable. I have learned plenty of ways of doing things, which yet again you are ignoring my points. But I will repeat myself again. I believe in all points of view. Which means that I have tried many ways of doing things, and have grown preferences from it. It is not out of comfort, it is not out lack of knowledge. It is out of preference. Do not tell me why I am sticking with something. I know why I am doing it, and that is not for you to decide. I never said usr abuse was a good thing. But using usr in a proc is not bad. It just depends on how you define abuse in a given situation. To some, it may be abuse, but it to others it is not. Reality is that there are many ways of doing things and right and wrong is not always concrete. Yes, somethings are better done in one way, but this one way is subject to opinion by many other people. Which is why there are many different views on subjects. | |
Dever wrote:
As for rain being "nearly" impossible, well, they still put a roof on any home built in the desert, because sometimes it rains even there. (And appropriately enough, when it does rain it's a downpour.) Rain happens. It's beyond your control. So are user mistakes (or exploits). What is not beyond your control is the ability to handle at least some of the problems that can come up. But of course it won't magically disappear. It's not like an entire section of your code will up and vanish. But it can fail, certainly, or let through a minor leak, or even be bypassed altogether in some unusual cases. Point is: Design the roof for the rain. It will come. And I never you shouldn't handle problems are have no safety. What I have been saying is, it is not nessicary to put safety design to protect agaisnt an impossible situation. Don't implement just because that situaion might be possible in the future. When it becomes possible, then implement. Effiency.. Sometimes a situation you deem impossible isn't so impossible after all, particularly as your code becomes more complex. Also "impossible" becomes slippery when you make assumptions that can be voided by subtle changes; as much as you've said you can "just change it" as needed, such changes can have unforeseen consequences. In many such cases you can make the difference between a major runtime error and smooth operation by just putting a simple check in a non-critical piece of code. (If efficiency is what you're after, then naturally you want to avoid extra code inside tight loops, but a simple sanity check will have zero impact on speed.) Lummox JR | |
'But of course it won't magically disappear. It's not like an entire section of your code will up and vanish. But it can fail, certainly, or let through a minor leak, or even be bypassed altogether in some unusual cases. Point is: Design the roof for the rain. It will come.'
Once again you bring up the roof. The roof had nothing to do with my actualy point. The roof is a non changable factor in this enviroment that shows that rain is impossible. Stop avoiding the truth and trying to change others story to fit your corrupted views. | |
Kija wrote:
Once again you are missing my point. My point was that sometimes the intern can be right compared to the electrician did. The entire point was that just because you are more experienced at something, does not mean that someone of lower experience will never be right. But you're talking about execution, and the usr abuse issue is design. The intern is not going to do a better job planning the overall wiring job than the master electrician. No, that is not saying that. I am saying that there are many ways of doing things, and no one way should ever be taught. If you insist of completly changing what I mean, then you obviously have no tendecy on having a normal conversation even on this. Another attempt to put down something; a rather poor one too. There are many ways of doing many things, and one or two ways of doing many things. The fact that multiple solutions may exist to one problem does not mean all problems have more than one solution. Putting usr in a proc is almost never a right way of doing something. The cases where it's reasonable are very very few. The fact is, you have relied on it. It was pointless to ever bring up in the first place, and the fact that you did only shows that you are. If you truly believed in your points, you would have no need to bring any such comments up. I brought up experience for two reasons. One, to point out that when there's a right way and a wrong way to do something, the right way is always clearer with experience. To argue in favor of the wrong way only proves you don't know the subject. The second reason is because someone without experience really has no business teaching. I do not believe I cannot be wrong. I do have preferences, but I am not one so foolish to say that all other views are wrong. This is not a cop-out; it is that you are very rigid. That would only be logical if this was a point-of-view or opinion issue. It isn't. You're trying to make it one because it keeps you from having to defend this on substance. My arguement has plenty of substance, and I have plenty of points, yet you ignore them and try your weight on another poor and warped example. But you haven't presented them. You keep falling back on "It's a point of view", which leads to "nothing that is a viewpoint can be wrong". Even the latter point is highly questionable, but the former is simply not true. "I prefer" is a point of view; you have stated that you have a preference. "It can't be right or wrong" is a statement of logic, without any. Again, it is an insult. Your constant bashing that I do not anything is not acceptable. I have learned plenty of ways of doing things, which yet again you are ignoring my points. You've learned a lot of ways of doing things, many of them wrong ways, some right, and many that are neither for situations where right and wrong don't apply. But if you don't learn to sift the good from the bad, you're not learning anything of value. Indeed even among methods that are not intrinsically "good" or "bad", some will be better than others in general or for specific applications. usr abuse doesn't fit that model because there's almost no specific application where it makes sense. But I will repeat myself again. I believe in all points of view. Which means that I have tried many ways of doing things, and have grown preferences from it. As will any programmer. Everyone will have preferred methods, techniques they like more than others. But a good programmer will also know some methods are right out. It is not out of comfort, it is not out lack of knowledge. It is out of preference. Lack of knowledge is definitely involved, but I think you're talking about a different kind of knowledge. I'm not implying you don't know a zillion different ways to do things. I'm saying you don't know why some ways should be avoided; at best you've heard the reasons but have yet to internalize and learn from them. As this is rather crucial knowledge and an important skill, it should not be absent from anyone who would presume to be a teacher. I never said usr abuse was a good thing. But using usr in a proc is not bad. It just depends on how you define abuse in a given situation. To some, it may be abuse, but it to others it is not. Abuse is abuse. Clinton had to ask what "is" meant, but no one rushed out to rewrite the dictionary. What you're advocating is, by the known and accepted definition, definitely usr abuse. You may consider it less abusive than the name suggests, but that is a matter of opinion. (Playing with definitions, by the way, is another slippery way to cop out of a debate.) Reality is that there are many ways of doing things and right and wrong is not always concrete. Yes, somethings are better done in one way, but this one way is subject to opinion by many other people. Which is why there are many different views on subjects. This one thing does have a right and wrong. The extent to which it's not concrete is only that to which an example can be found where usr in a proc does not influence robustness. Those pickin's are about as slim as a good use for goto or the : operator; they do exist. Opinion only comes into play in that some people may be more comfortable using the shoddy method as opposed to the right one. For many objective reasons, the right way is better than the wrong way. Lummox JR | |
Kija wrote:
I never said usr abuse was a good thing. It isn't good. Period. But using usr in a proc is not bad. In pesuedo-procs (verbs, Click(), etc.) it's normally okay. In other procs, it's just plain old B-A-D. It just depends on how you define abuse in a given situation. Abuse is abuse. It does not depend on the situation, but more of how the programmer tends to do something in a certain manner. To some, it may be abuse, but it to others it is not. To those others that think not, they need to get priorities straight because learning one solution now, sometimes will never be the best solution in the future. | |
Dever wrote:
'But of course it won't magically disappear. It's not like an entire section of your code will up and vanish. But it can fail, certainly, or let through a minor leak, or even be bypassed altogether in some unusual cases. Point is: Design the roof for the rain. It will come.' How is the roof a non-changeable factor? It would, by analogy, necessarily be part of your code. That makes it relevant. The only other possibility is that the roof represents the means by which you are absolutely 100% bet-your-life certain nothing unexpected will happen. In which case, you have no roof. Lummox JR | |
Lummox JR wrote:
Dever wrote: The roof isn't part of the code, but the enviroment it is existing in. Try to understand that. | |
If you integrate to relate to coding, it is. Considering Lummox's previous posts, he was trying to get the point across that robust and safety checks (The roof), can protect you in the future (the game), from all the rain (The run-time/compile errors).
| |
Mega fart cannon wrote:
If you integrate to relate to coding, it is. Considering Lummox's previous posts, he was trying to get the point across that robust and safety checks (The roof), can protect you in the future (the game), from all the rain (The run-time/compile errors). ( And if would have ready the 'analogy' correctly, you would seen that the umbrella was the safety check and the roof being the reason why the umbrella was unesscary) What I was trying to get across is that safety checks are unessecary if you know they aren't going to be used or going to be of an actualy need. | |
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.
There was no good reason for you to bring it up. You can easily argue your points without doing so. In these post so far, I am not defending my preferences. That was a long time ago, and if wish to view them, I suggest you read the threads that I presented where they were being defended. The only reason I bothered to point in this thread was because I had been falsly accused of something. It was your decision to bring any further than that, and the discussion brought from that was not about this current topic, so obviously I am not going to be presenting any points for it or any other preference. 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. 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 am not here to argue whether using usr in a proc is right or wrong. That is not what started this conversation. It is your opinion that using such methods is shoddy, so it is rather flawed for you to say that. | |
Dever wrote:
Mega fart cannon wrote: I would agree with you to a point. You wouldn't need safety checks if you're 120% sure that your code absolutely cannot crash under any circumstances given to you in the world, which I doubt it likely. Safety checks are handed to you on a silver platter, all you need to do it take it. | |
Dever wrote:
Mega fart cannon wrote: Alright, you're totally ignoring some of the parts of good design. You generally try to write code that you can reuse, not code that you're ever only going to use once. On a team, you don't know that they aren't going to be just used once, and if you follow this belief of yours, you will never make it into the higher-level languages. If you try to get a job, your team will hate you, you will cause more bugs than you fix with this habit of yours. Safety checks are necessary in all cases. You have to be out of your mind to argue with some of BYOND's finest ( Lummox ). This whole thing is not about opinion, it's about fact. A fact is that safety checks ARE necessary. Another fact is that you can never be sure that something is only going to be used once, and be certain how it is going to be used every time, and know that it won't be misused or sent a bad value. Notice the amount of posts about runtime errors involving "Null.Variable?" That's because they didn't put in the proper checks the first time. Another fact is that you can not be sure what usr will be every time inside of a proc. Another fact is that you will always know what src is going to be, always. One final fact is that in most situations, you will not need the colon operator. | |
Audeuro wrote:
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. | |
Dever wrote:
usr is ALWAYS the mob that called the original proc. I'm sorry if you don't understand this, but I do. IIRC: 'usr' is TRUE if the following conditions are met: 1) 'usr' is the initializer of the proc. Otherwise, FALSE. Therefor, verbs, Click(), DblClick(), etc. are allowed to have 'usr' in them because 'usr' is not FALSE in those pesuedo-procs. | |
Well yeah, but that specific event refers to the case of the master electrician making a mistake. In terms of proper design, knowing how to do the entire job safely, and in knowing how to decrease the likelihood of a mistake in any particular section, the master electrician is always right. Since this is a point not of execution but design, the big picture matters.
You're entitled to opinions, but not to teach what is clearly wrong and will throw people off track. If you've decided doing things bass-ackwards is good for you, more power to you, but leave it with you.
This is not a point of view; the one design method is wrong, the other right. Your level of comfort with either design is a point of view, and that's what you're really trying to defend here. You can't simply push all arguments into the realm of opinion just to cop out of them.
"Smarter" and "vastly more experienced" are two separate concepts. I've only stated the latter. Saying that anything more complicated than "Hello, world" will land your design method into trouble or that you couldn't have done much more than that if you haven't encountered that trouble is an exaggeration, sure, but a slight one. It simply doesn't take much complexity at all to develop a problem with the way you're doing things.
To blindly believe would be to ignore all arguments for or against. But this I have not done. I've presented strong arguments in favor of good design. You on the other hand have basically had to say "Well it works for me, so I'll keep using it." Well fine, but don't teach it. You don't know enough to be a teacher. Hopefully someday you will; we need more of them. What we don't need more of are people who think they know what they're doing but don't, and are willing to screw up others for the sake of puffing up their own egos.
Lummox JR