By writing tests to clarify uncertainties, by reading books, talking to people more knowledgable in this particular field than they are, and by learning the underlying system architecture (something that debugging often requires). It's pretty much like learning anything else, except for the fact that it's not covered in most books presumably because it isn't that important. The perceived importance of the numerical value of a pointer changing is the part about beginner's wisdom that I was referring to.
Correct. The DoD is quite fond of Ada for this purpose. Sometimes, restrictions that require very explicit permissions are impossible to implement due to the black-box nature of some code modules that one works with. So this absolute guaruntee of protection actually excludes some certain interoptability requirements.
It's not irrelevant at all -- I was confirming your point. But then I took it a step further and showed that even if C++ were within the bounds of comprehensibility, it's still a superset of C and therefore there would still likely be more people that fully understand C. You address this by stating that you've never met someone that fully knows C++, and I counter that I've met many =).
That wasn't actually a problem though; there was nothing wrong with it. I would first probably search for multiple inheritance, assigning pointers, etc. But one needs a bit of architectural knowledge to understand why it does this. This isn't necessarily a bad thing, there are architectural issues behind the 'why' of every language that can't be easily explained to a new programmer. However a few simple test programs are enough to show that this behavior wasn't likely to cause problems, and could thus be ignored. I don't usually google issues that can be resolved so easily.
Debugging code not written to you is akin to reading books not written by you. If your team can't agree on a vocabulary, I'm sorry but there's nothing I can do.
That is indeed how the logic goes, especially after I and Lindahl pointed out features that are commonly misused (pointers, strings as arrays) in nearly the same breath. While it's true that we haven't talked about VB, I would like to see why you feel that C is more justified than VB due to this confusion. Are bad features alright because you've met people that fully understand a language that makes use of them? Do you decide with a contest of bad features, with the language that has the lesser amount winning out? Is it because the reasonably good programmers (a subjective term, of course ;)) can produce reasonable code in both VB and C, so there is no preference either way? You've used several arguments between here and the beginning, and many that I have addressed as being mostly subjective and thus unarguable. I want to find the common ground that we can both address. You fight my attempts, claiming that they aren't logical when you simply do not understand what I'm trying to do. Remember back to your classes, then: Any argument in which the premises force you to a conclusion is logical, even if you disagree with those premises.
What I like most about 'object references' as opposed to 'memory pointers' is that they decouple memory operations from object operations. The primary abstraction behind a reference is the object, whereas the primary abstraction behind a pointer is a chunk of memory that usually has a type that goes along with it. I believe that languages should still offer the ability to access lower-level memory, but I also agree that they should use a different construct for this than the pointer.
|