Kija, I didn't say you stated the exact same thing he did, I'm not trying to start something with you, I was merely relating this converstion to one like it. Actually, I never once mentioned you saying that Lummox said, "Using usr is bad in all cases."
You said "there is never a place to ue usr." That is a very general statement, you should really be just a tad more specific.
Also, I did NOT twist your words in any way. I quoted you exactly and took it literally. | |
No, you did not. I was giving an example of what you may think I twisted around. There is nothing to relate on twisting words, for I never did so. If you did not wish to start something, then do not mention my name on false information and accusations.
| |
I'm sorry for anything I might have implied, then. I just seem to remember ( for some odd reason ) that you twisted something around. I'm sorry if I am mistaken.
| |
Dever wrote:
'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."' You said it's impossible for unanticipated user input to occur. And even if you hadn't said that, it's the only way that you could know exactly how your code will behave in all circumstances, particularly if you do not follow robust programming practices. There is know writing it robustly to where it can work in different siutations and having to guess how its going to be used. Granted. Your code doesn't have to be at a library level of robustness where it can handle all kinds of input and is meant to be pretty durable in the face of people abusing it. It should however be built to handle even a little of the unexpected. You are the one who isn't able to learn and understand that your way is the way that is cutting corners. Now you're just being silly. I've been arguing this entire time against cutting corners, in favor of using extra safety checks and sending proper information to procs, not relying on usr. None of that counts as cutting corners--it's exactly the opposite. You seem to be so desperate to make your point now that you're willing to simply contradict everything on its face. Lummox JR | |
Lummox JR wrote:
It's okay to be fallable; it means you're human. I have never seen you proven wrong =P | |
What you said.
'Now you're just being silly. I've been arguing this entire time against cutting corners, in favor of using extra safety checks and sending proper information to procs, not relying on usr. None of that counts as cutting corners--it's exactly the opposite. You seem to be so desperate to make your point now that you're willing to simply contradict everything on its face.' What I had said earlier, read carefully and understand. 'Yes rewrite them. I am willing to do that. I want to make sure that everything will work as effiencly as possible. The one cutting corners are the ones trying to make where they won't have to rewrite things later.' | |
Dever wrote:
Writing effienct code is no where near 'slipshod'. You obvisously don't understand true effiency and performance. It's slipshod if you're not using any safety checks or any safe practices. It may be marginally faster, but it will not be strong code and will be all the more likely to fail in the event of a bug. Effiency is the ability to perform its true function as fast and acurractly as possible. That is what I do. Yet you throw accuracy to the wind by making assumptions and removing all safety checks that can prevent a bug from propagating. In tight loops, for optimization you absolutely do want to trim down what you can, but in those cases you do your safety checking before the loop. You can't hyper-optimize every part of your code and still have it function well, particularly if it is at all in flux. I'm not really aware of any program that doesn't remain in flux to some degree throughout its lifetime. Having something written robustly slows it down and lowers its effiency. In much the same way that the extra weight of seat belts on a car does, yes. That is, the effect is beyond miniscule. Any optimization work you do here is a waste of time, and if to do it you have to throw all caution and all hope of graceful failure to the wind, then you've screwed up your priorities. Mind you, I'm an optimization freak. I like code to be as tight and fast as possible. But there are not just some, but many places where optimization just doesn't matter for crap, and doing a simple safety check in those places does not impact your performance in any measurable way. I'm not talking about the difference between 60 FPS and 59 FPS, either; I mean 60 and 60. The difference is undetectable unless you actually go down to measuring cycles. Moreover, you'll find that in loops or procs that require maximum efficiency, you can find another way to do the safety check that itself is an efficiency improvement. Bottom line: You don't know either of these topics well enough to hold any sort of informed opinion on them. Or even, at this point, a grossly uninformed one. You just don't know what you're talking about. Lummox JR | |
Dever wrote:
Maybe unflexible in its current state, but not broken. The fact is though, that if needed. JUST REWRITE IT! And now its fixed for that new situation. That simple. You've been ignoring this point pretty steadily, so I'll repeat it: Rewriting one piece of brittle code will necessitate rewrites of many others. The interconnectedness of the code often goes well beyond what you may be aware of, even if you're intimately familiar with all of it. Brittle code is ten times harder to rewrite or adjust in this fashion, so the idea that you can simply fine-tune your code to perfection is ludicrous. The degree of control and precision you're suggesting is simply not possible, even for a phenomenal programmer. Lummox JR | |
Audeuro wrote:
You definately have the weirdest habits I have seen when it comes to the subject of programming. Sure, I've been programming for a little under a year, but I'm not anywhere near as persistent as you are. If you have done -any- debugging of apps that you wrote in C++, then you'd know that some of the tiny errors come from stupid things. Things like forgetting to initialize a variable, or forgetting to delete what you new'd or free'ing what you malloc'ed. Or forgetting a call to a function. Oy. You're right there. C++ is a trainer of men. Some of the weirdest errors you'll ever encounter can occur from just one typo that ends up writing past the end of a memory buffer. Lummox JR | |
Dever wrote:
According to Lummox and others, there is never a place to ue usr. Which is incorrect. Indeed it is, because I've never said that. I've said: No put usr in proc. Ungh. Obviously usr in verbs, or virtual verbs like atom/Click(), is okay. That's why it exists in the first place. There alot of places where using usr is more effienct, and so I will use it there. Many of those places, "more efficient" is a bogus technicality. That's like dropping two bowling balls from the same height and saying one hit the ground mere picoseconds before the other. You're gaining literally nothing there because those picoseconds are going to be eaten by other delays and system overhead. In exchange for that gain of nothing you make your code next to impossible to maintain, and completely unable to fail gracefully in the event of a bug or unexpected user event. That's not worth defending. Lummox JR | |
'Yet you throw accuracy to the wind by making assumptions and removing all safety checks that can prevent a bug from propagating.'
You still don't understand. The way I code it, it doesn't need safety checks to begin with. Following your way of thinking, it would appear that you you would think people should say, have umbrellas opened with them in a building just in case the roof magickly disappears and it starts raining. Good thing you carried that umbrella opened with you that entire time. | |
Kija wrote:
Not only that, I am still right. You can keep thinking that, but that doesn't impact reality. You lost that one, dude. Let it go. And this discussion is very similiar to mine. And yet again, it is the exact same insults, the exact same reliance on these "facts" rather than the topic. Even if it was a fact, does not mean you should say it. Would you go up to a burn victim and say "Hah! You are so ugly! But you cannot be mad at me; I am just stating the facts!" Whether it is true or not, it is still an insult, and still pointless and pathetic to say. Although, in this case these "facts" are not true. They are insults and have no place here. Saying someone is ugly is an insult. Saying someone is inexperienced and doesn't know what they're talking about is not. I know next to nothing about plumbing; clearly I'm not qualified to weigh in on the best way to place sewer lines for maximum efficiency and ability to keep maintained. Ofcourse, my example, you could say that in certain cases, you could say that to someone. I am not argueing that, I am argueing that stating something as a fact does not make less of an insult. People seem to forget that it does not matter who knows more, but who is right. In a sense that's correct, but you forget one important point: If one person knows a great deal on the subject and the other knows very little, the odds of the second person being right are jack to diddly crap. Experience isn't a dead lock, but if I had a choice between a seasoned professional and an intern to rewire my house, it wouldn't even be close. Your entire argument boiled down to "It works, so I must know what I'm doing." The former does not imply the latter, even if "it works" is more than just a tenuous statement. And so instead of pointing out the correct topic and argueing against it, they simply brag about how much smarter and better they are and hope that will prove them correct. It isn't a matter of bragging, and as in that thread it's not smarts but knowledge that's the difference here. Although it is worth mentioning that defending a point one doesn't understand is not a smart thing to do. Just because you're comfortable with something does not mean it is defensible or right. It just means that's what you're used to. If it's not right, you should be willing to learn why and to eventually adapt to avoid it. If not, well, the decision not to improve is your own concern, but you should definitely not encourage others to do the same, which is what you were doing in those threads. Lummox JR | |
Dever wrote:
'Yet you throw accuracy to the wind by making assumptions and removing all safety checks that can prevent a bug from propagating.' And again we're back into the fluffy-bunny world where nothing can possibly go wrong and all user actions will follow exactly what you expected. Look, that's not reality. Things are going to go wrong. If your program is more complex than "Hello world", if you have so much as simple get and drop verbs, it can go wrong. The degree to which the inevitable problems will impact your code depends on how well you plan for them, how early you catch them, and how robustly you manage individual elements of the code to prevent a minor shower from becoming a landslide. All programs need safety checks. Novice programmers will tend to use few of them, and that's fine, because they're still learning and haven't figured out yet the best way to use them. Advanced programmers will avoid putting safety checks directly in sections that must be optimized, but they will always look for a place to do those safety checks beforehand. Following your way of thinking, it would appear that you you would think people should say, have umbrellas opened with them in a building just in case the roof magickly disappears and it starts raining. Good thing you carried that umbrella opened with you that entire time. 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. A good roof is made up of many layers to prevent water and snow from penetrating. Similarly, a good program is capable of catching problems at multiple points. Shingles aren't just placed next to each other; they overlap. Ponder that. You're basically arguing that your roof is exactly as thick as you need it to be at all times, while having built it out of one layer. Indeed not even one layer, if you have no safety checks whatsoever. You have no roof at all. What you're relying on is the complete lack of rain. Lummox JR | |
Dever wrote:
What I had said earlier, read carefully and understand. How utterly you have misunderstood that phrase. Since "cutting corners" refers to slashing safety tolerances to the bone, that is not what robust code does. The end result of robust (or even just modular) design can only be more redundancy, particularly in safety, not less. Lummox JR | |
I lost nothing. I still disagree and you still disagree, nothing was proven by it. Why not let go of your arrogance and get over that? There is nothing for me to let go.
My arguement is not about I know what I am doing because it works. It works because I know what am doing. Nor did I forget that point, I am well aware that someone more experienced has a better chance of being correct, but you should not rely on that fact to get you anywhere in things such as this topic. Your example is flawed. This intern after studying before may cross a wire differently than the proffesional. And although the proffesional is over all better, that simple change in a situation may prove to be better. Do not look at things so broadly. You thinking that a person does not understand it does not make it true. Instead of pushing such a point, why not just argue against the topic? Your last comment could be applied to you as well. As I have said before, it is about preference, and it remains that way. And it is definatly not right insult someone in a thread either; nomatter how much you disguise it as "facts." Even now it is still sad to see, which is why I lost my respect for you long ago. I encourage others to see all points of view and learn that just because someone has a different preference, does not make it wrong. If you do not wish to learn to accept other points of view, that is your loss. | |
Lummox JR wrote:
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. Definitely been hit over the head quite a few times, I have. =D Especially when I was trying to pick up on C++(about a month or so into it)....I spent hours trying to figure out what was causing several run-time errors. I fixed a few design flaws and it worked. Imagine that! Apparently, robustness(as usual) saved the day!(Granted I wished I would have did that part robustly in the first place; it was the "brittle code" that you would speak of.) Hiead | |
Kija wrote:
I lost nothing. I still disagree and you still disagree, nothing was proven by it. The fact that you still disagree doesn't mean you didn't lose the debate. It's pretty clear where that one landed, and it wasn't in your camp. My arguement is not about I know what I am doing because it works. It works because I know what am doing. If you knew what you were doing, you would not champion this technique nor suggest it to others. This is not the argument of someone accomplished, skilled, or experienced; it's the argument of someone who's found something that "works" for them, and won't let go of it. You don't have the experience to know how little you know, and you refuse to even think that. Nor did I forget that point, I am well aware that someone more experienced has a better chance of being correct, but you should not rely on that fact to get you anywhere in things such as this topic. The simple reality is, you know very little about programming overall because you have very little experience on the subject. That you wouldn't consider your point could be wrong the first time when confronted with strong supporting arguments by people who do have such experience means you're merely being stubborn. But hey, you're entitled; if you don't want to learn, just stop trying to teach. Your example is flawed. This intern after studying before may cross a wire differently than the proffesional. And although the proffesional is over all better, that simple change in a situation may prove to be better. Do not look at things so broadly. So basically you're saying a master electrician could accidentally make a single mistake whereas an intern could accidentally wire the house perfectly. One catch: A master electrician's one mistake would be caught, not only due to his rigorous testing and safety measures, but also because of the manner in which he would wire the rest of the house precisely to prevent that miswiring from becoming a greater problem. You thinking that a person does not understand it does not make it true. Instead of pushing such a point, why not just argue against the topic? Your last comment could be applied to you as well. As I have said before, it is about preference, and it remains that way. It is not a matter of preference unless you prefer to have sloppy, difficult to maintain, all-around bad code. To that extent, sure. But that's nothing you should go pushing on other people. You may prefer to sleep every night with a bowling ball poised on a shelf 4 feet over your head--that doesn't make it smart. And it is definatly not right insult someone in a thread either; nomatter how much you disguise it as "facts." Like I said, to say someone has a lack of experience is not an insult. To say they have a lack of knowledge because of said lack of experience is also not an insult. To say someone is ignorant is not an insult. To call them an ignoramus would be. Big difference there. If you do not wish to learn to accept other points of view, that is your loss. This isn't a point of view, it's just someone stumbling along blindly in the way they chose while stubbornly refusing to stick to safer ground. You can go off and stumble along all you like, but don't tell others to follow you. That was what sparked this entire thing in the first place. Lummox JR | |
I did not lose the debate. It landed nowhere. Others may disagree, others may agree. But it is not for me or for you to decide, so do not bother.
You have entirely missed my point about the electrician. I never said the entire house, as I said do not look at things so broadly. I was suggesting a specific event in which the intern may be right. The simply reality is, you are constantly repeating yourself over pointless facts. Yes, I am entitled to my opinion and the way I want to teach things. And it includes using many points of views and not insulting someone just because they disagree. If you do not want to learn to accept other people's view, then stop insulting them and just leave them alone, for it is not acceptable for you to do so. And yes, it still remains and insult because you are exgerating everything. Such as your hello comment. It is also an insult because it still has no place in these sort of topics, because by just stating that they do not know anything, you are avoiding the true topic and once again trying to use "I'm smarter than you, so I am right" approach. It is a point of view, whether you accept that or not. If you wish to blindly believe in one way of doing things, then so be it, but do not oppress others over it. | |
Well since the discussion was about using usr in PROCS then assume I meant no place to use usr in procs. It seems like your trying to twist my words.