Top Mud Sites Forum - View Single Post

angelbob · 04-01-2003, 01:26 PM

Well, sure, but (other than people like me that rederive the bit layout based on how we'd write the compiler) how is a beginner supposed to turn into somebody that expects the behavior that C++ has there?

I was only able to do it because I've played with ugly bitwise manipulation of several other C++ constructs. Knowing the behavior is required to debug the problem, and it's not behavior that I've ever seen documented (with the exception of email/posts written by me).

Actually, if you agree that adding features affects how people use the rest of the language, I'd say that brings us closer to agreement rather than furthering our disagreement. You're in favor of optional features, even optional features that are badly used in almost every case (at least, so you said), because they increase the expressivity of the language, presumably in all the cases that aren't part of the "almost every case" I just mentioned.

Well, yes, but there are degrees of "screwed up". There are, in fact, languages that make pretty good guarantees of modularity.

Well, no. They should avoid those features whever possible. However, they get an extra safety net in languages where people can't use features they're not basically familiar with, such as one where they know all the features because there aren't all that many. I'd say C is near the largest set of features a language can have and still be that comprehensible. It may even be slightly larger than that, given how few people I've met that really know it. C++ is unquestionably over the limit.

Wait, wait. It's obvious that more people will fully know C than C++ (I've still never met one that fully knows C++). And therefore it's obvious, so it's irrelevant?
But yes, I feel that a language that is fully known is easier to debug than a language that you only partially know. You're welcome to say Google is a full reference to everything, and I'll reply that some things are very hard to find. Again, take my typecasting and multiple inheritance problem above. What would you do a search for to figure out what's wrong with that? Would you know to search for that without already knowing what the problem is?

Sure. Syntax isn't the problem. How the language handles things can be pretty unintuitive, though. You're welcome to call it semantics, which is more accurate. I consider the basic point correct, though.

But it's unusual to get that luxury during debugging, unless you write everything you work on.

Actually, I was disagreeing with the idea that the bald statement, the one starting with "so we should all use VB", was using the logical principle in question. You never stated how you got there, it certainly wasn't obvious, and you never gave most of your other assumptions.

Presumably the logic you used goes, "bad features are bad, C++ contains bad features, C contains bad features, VB contains fewer bad features, so VB must be where his argument goes". But then, that sounds pretty illogical, at the very least the part that says "VB contains fewer bad features" given that we haven't talked about VB.

So you apparently got there some other way. If you'd stated how, or even given a serious hint, I could have taken that as a logical utterance. You didn't, so you were simply using a challenging tone and using a statement you were pretty sure I'd disagree with, but attributing it to me. Again, that's fine, but calling it "logic" is still a stretch.

I have, incidentally, taken classes in logic. That's one reason I'm calling you on this. If I hadn't, I wouldn't bother calling you on it. Nor would I bother taking classes in logic if I hadn't already since your examples make 'em look pretty useless :-)

Yes, that's pretty much what references are in the languages I mentioned. The fact that you can't typecast them helps as well. Between those restrictions and array bounds-checking, those references are guaranteed not to allow you to write to memory without knowing what type it is, unless you have a "cheat" function to let you supply a numerical pointer somehow.

So yes, they look a lot like pointers, and yet they're much safer to use.

Huh? No, I didn't mean LPC. LPC isn't 100% compatible with C. Not even close. C is 100% compatible with C.

And I actually make a point of using a dialect of LPC that can't do C callout. The fact that it doesn't means that it can make several other guarantees in the language, which lets it do cute tricks like atomic functions and the rlimits() construct safely. Unfortunately, neither of those things is compatible with C, nor is there any easy way to do the equivalent.

04-01-2003, 01:26 PM	#43
angelbob Member Join Date: Feb 2003 Location: Bay Area, CA, USA Posts: 39	Well, sure, but (other than people like me that rederive the bit layout based on how we'd write the compiler) how is a beginner supposed to turn into somebody that expects the behavior that C++ has there? I was only able to do it because I've played with ugly bitwise manipulation of several other C++ constructs. Knowing the behavior is required to debug the problem, and it's not behavior that I've ever seen documented (with the exception of email/posts written by me). Actually, if you agree that adding features affects how people use the rest of the language, I'd say that brings us closer to agreement rather than furthering our disagreement. You're in favor of optional features, even optional features that are badly used in almost every case (at least, so you said), because they increase the expressivity of the language, presumably in all the cases that aren't part of the "almost every case" I just mentioned. Well, yes, but there are degrees of "screwed up". There are, in fact, languages that make pretty good guarantees of modularity. Well, no. They should avoid those features whever possible. However, they get an extra safety net in languages where people can't use features they're not basically familiar with, such as one where they know all the features because there aren't all that many. I'd say C is near the largest set of features a language can have and still be that comprehensible. It may even be slightly larger than that, given how few people I've met that really know it. C++ is unquestionably over the limit. Wait, wait. It's obvious that more people will fully know C than C++ (I've still never met one that fully knows C++). And therefore it's obvious, so it's irrelevant? But yes, I feel that a language that is fully known is easier to debug than a language that you only partially know. You're welcome to say Google is a full reference to everything, and I'll reply that some things are very hard to find. Again, take my typecasting and multiple inheritance problem above. What would you do a search for to figure out what's wrong with that? Would you know to search for that without already knowing what the problem is? Sure. Syntax isn't the problem. How the language handles things can be pretty unintuitive, though. You're welcome to call it semantics, which is more accurate. I consider the basic point correct, though. But it's unusual to get that luxury during debugging, unless you write everything you work on. Actually, I was disagreeing with the idea that the bald statement, the one starting with "so we should all use VB", was using the logical principle in question. You never stated how you got there, it certainly wasn't obvious, and you never gave most of your other assumptions. Presumably the logic you used goes, "bad features are bad, C++ contains bad features, C contains bad features, VB contains fewer bad features, so VB must be where his argument goes". But then, that sounds pretty illogical, at the very least the part that says "VB contains fewer bad features" given that we haven't talked about VB. So you apparently got there some other way. If you'd stated how, or even given a serious hint, I could have taken that as a logical utterance. You didn't, so you were simply using a challenging tone and using a statement you were pretty sure I'd disagree with, but attributing it to me. Again, that's fine, but calling it "logic" is still a stretch. I have, incidentally, taken classes in logic. That's one reason I'm calling you on this. If I hadn't, I wouldn't bother calling you on it. Nor would I bother taking classes in logic if I hadn't already since your examples make 'em look pretty useless :-) Yes, that's pretty much what references are in the languages I mentioned. The fact that you can't typecast them helps as well. Between those restrictions and array bounds-checking, those references are guaranteed not to allow you to write to memory without knowing what type it is, unless you have a "cheat" function to let you supply a numerical pointer somehow. So yes, they look a lot like pointers, and yet they're much safer to use. Huh? No, I didn't mean LPC. LPC isn't 100% compatible with C. Not even close. C is 100% compatible with C. And I actually make a point of using a dialect of LPC that can't do C callout. The fact that it doesn't means that it can make several other guarantees in the language, which lets it do cute tricks like atomic functions and the rlimits() construct safely. Unfortunately, neither of those things is compatible with C, nor is there any easy way to do the equivalent.