Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 03-31-2003, 09:39 PM   #41
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
Thought of in precisely this way, yes. It came as rather a surprise to me at the time, and I had to do a great deal of explaining to the other (professional, highly-educated) C++ programmers I was working with. They hadn't bothered to learn how C++ does its magic at a bitwise level, so ugly little artifacts like this were entirely unintuitive to them. I have yet to see a book on C++ that provides the required background to make any sense of this, in fact. Given that multiple inheritance and typecasting are both quite standard features and are in essentially every C++ book, I consider that an interesting commentary on whether adding features is basically benign.

Well, yes. If it had any more flexibility or genericity in those areas (colloquially: "did it right"), you'd have to call it a dynamic or functional language.

My coming up with that has a lot to do with your arguments about adding features always being a good thing (unless they prevent adding other features) and your claiming that adding features only adds to the expressiveness of a language so I'm obviously being fascist by disagreeing with the use of any feature.

So yes, you *do* know where I came up with that. We've been having this same argument in minor variations for awhile now. But you told me what I needed to know to lose interest. More on that in a second.

Here we go! You're not interested in how badly other people abuse C++ because you don't work with other people regularly and you don't particularly want to. Okay, I'm jiggy with it. Since I have *very* few projects where I don't work with others or plan to in the future, this explains about all I need to know. As I say, "enough to lose interest" :-)

I'm familiar with what you're talking about, and what you did isn't that. For instance: I claimed that C was different from C++ in that a single person will much more commonly know all of C to an extreme degree (John did, I do, I've met others that do), thus enabling somebody to reasonably debug a random sample of code using all language features. Speaking as a former Teaching Assistant who debugged code in a Computer Graphics class, I'm glad we used little or no C++ since I had to read arbitrary code from questionable coders to do that job.

But yes, if you'd stated some assumptions and the principle you were extending, it would be similar. Done crudely, as you did there, it's just mockery. You're welcome to do it, but calling it logic is pretty silly.

Sure, but that's pretty irrelevant to whether it breaks the type system.

I'm not entirely sure what you mean by the whole "not reassignable" thing here. You can reassign a variable which holds a reference to instead hold another reference in Java, LPC, Dylan, Perl and CommonLISP. Which language were you thinking of?

And references aren't always valid, at least in LPC, CommonLISP, Dylan, Perl and (I think) Java, all of which have a NULL value or the equivalent.

You've got me on the Chinese/English thing. Those do tend to be alternated rapidly and constantly by native speakers. Languages borrowing individual phrases from each other and having minor spillover actually *supports* my point -- instead of taking the fully-expressive union of the two languages, they take one of the less-expressive components and timidly add little extra bits of expressiveness to it. Pretty silly if more expressive was always better.

This is the other reason I've lost interest. I'd thought you were suggesting it for him, not for you. What you do by yourself is your business, in pretty much every sense :-P

Roughly. I believe that a programmer of average competence should be able to write very usable, pretty debuggable code, and a programmer of high competence (but not utterly brilliant) should be able to write good, usable, debuggable code. This should be true even if using a fair subset of the language features since the overlap of any five programmers is likely to use the vast majority of the features of a given language -- even Perl :-)

True. I agree entirely. I just don't care about that as an excuse since I already have a perfectly good language that is 100% compatible with C :-)

Okay. Unless we raise a new topic (or you'd like some very specific question addressed), I think I'm done with this thread.
angelbob is offline   Reply With Quote
Old 03-31-2003, 11:10 PM   #42
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

Debugging and examining memory is mostly a function of the system you're using, not the language. It's so intertwined in C because C is so intertwined in Unix. But one needs to do away with these C assumptions when working with C++. I think this is a case of beginner's wisdom, where you have just enough knowledge to get yourself in trouble.

Even if I thought that adding features was always a good thing, I still never made the silly assumption that they don't affect things that they're not directly related to. If they didn't affect these things, we wouldn't be having this argument. So no, I have no clue how you attributed this assumption to me.

Hahahaha. 50% of what I do professionaly is interface with other people's code. Bad MFC-influenced C++ code. Bad traditional C code written when I was in kindergarten. Bad C++ written by VB programmers. Bad VB written by doctors and financial guys. Large projects and small, you don't call in the consultants until you're sure your code is thoroughly screwed. So yes, I work with a lot of other people and yes, I understand the abuse very, very well. Yet still I hold the position that I do. I've come to realize that there's a lot of screwed up code out there, even in "safe" languages like VB. I simply make language recommendations based on the level of ability I perceive of my clients, nothing more. Note how the original poster had a specific goal, and I made a recommendation that would seem counter to what I've been arguing for this entire time. When there is no stated goal, however, everything is on the table and every last possibility must be accounted for.

So this is your answer: People should only avoid features that are "misused, or commonly misused" within languages that people can not understand to an extreme degree. You base this on the fact more people know C to an extreme than C++. Shouldn't this be obvious though? If one is going to master C++, one will naturally master C in the process. Most of the 'serious' programmers I've met know C++, or are not daunted by a simple debugging session with some random C++ code. With any of the competent programmers I've met, syntax means nothing once the basic idioms are mastered, and google is the instant reference for anything =). So from the start we see that this condition will never be met due to C++ being a superset of C. Many people write books using only a subset of a language. It's not impossible to restrict one's vocabulary, and I've worked on several projects with strict rules (mostly for portability, though, I wouldn't trust a manager that hired a guy that couldn't debug a random subset of valid code). So I disagree with that premise as well. Debugging standard code is a simple matter for most programmers I've met -- it's the library stuff that gets ya =). Thus, it is indeed logic, I simply disagree with the premises that excludes VB.

Then the references to which you refer are basically the same as pointers that memory arithmetic operations cannot be applied to. Your beef isn't with pointers, it's with memory address manipulation.

When did I do that? I don't remember doing so... all I remember is responding to your points about C++ and C cleanliness =).

LPC and C++ are two vastly different things. And before you ask -- LPC doesn't have nearly as many features for writing extendable, generic and safe code that C++ does =). Of course I usually forgive this because one can extend LPC from within C (and thus C++).
Yui Unifex is offline   Reply With Quote
Old 04-01-2003, 01:26 PM   #43
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
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.
angelbob is offline   Reply With Quote
Old 04-01-2003, 02:40 PM   #44
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

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.
Yui Unifex is offline   Reply With Quote
Old 04-01-2003, 03:57 PM   #45
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
True, I didn't give the full context.

The way this came up was that I had a function taking a pointer, and I was passing in the pointer in question. I was using void pointers for intermediate storage, mainly because this was autogenerated code and looking up the type name for the pointer being passed was a massive pain and involved parsing an entire extra file.

But typecasting to (void*) and then to what was needed turned out to give garbage results, and cause crashes. I had no clue why. Eventually, on one of those "Oh God, that would be so evil" hunches you get in debugging, I did a straight-up assertion -- assert((B*)var == (B*)(void*)var) -- and discovered that C++ was changing the value on me, but only sometimes.

There was no obvious way to find the problem, though I did manage to figure the rest out once I figured out that the typecast was changing the pointer's value. But as you say, there's nothing obvious to google for there. Inheritance? Typecasting?

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.

Well, yes. You never state most of it. And if "state your premises if you want your argument to be taken seriously" is too onerous, that's tough. I could take your position, that every feature added (that doesn't conflict with other features) is good because it adds to the expressiveness of the language and put some pretty ridiculous points in your mouth as well, but (as when you do it to me) it would just be mockery, even though it obeys your stated reasoning.

I remember back to my classes: using unstated premises and unstated rules to get conclusions based on what you think I think you think is outside the domain of logic, so I can pretty much ignore it.

Now, back to the point you want to debate, the C vs VB thing and what the actual difference is.

While I think the understanding thing is important -- I've never worked with somebody who even claimed to fully understand C++, let alone somebody who actually does -- it's not the main point. Let me introduce a pretty exact concept and then a very small number of very inexact data points.

One could imagine rating every construct one sees in code for cleanliness, effectiveness and brevity. One could then look at various language features and based on the constructs that they had contributed to, decide whether they contributed to good or bad code, on average.

One could then look at multiple possible language subsets (or designs or whatever) and decide on that basis whether the features included were good, and whether in concert they tended to produce good or bad code. By beginning with a language that is very clean but very simple (something like SCHEME, for instance, but even simpler), you could guarantee that the language had a baseline minimum of expressiveness and then add features from there, bearing in mind one's tolerance for ugliness in code. Adding "goto" would bring the total up a lot, so you'd much rather add loop constructs, perhaps with labelled loops (Perl's usual answer to goto). You could add exceptions, but only if, as in Java, it's easy to be sure of the full range of exceptions a given function can throw. You could add something to do template-like work, but instead you might choose procedural macros to make the results less syntactic and more semantic in the way they work. Or you might just skip them entirely if you have runtime compilation already, since then you could construct whatever you like in the language itself, very much like how LISP handles its procedural macros.

If one had a very low tolerance for syntactic ugliness (or were trying to irritate Yui specifically) one could wind up with a very simple language with very few features, a lot like SCHEME. If one had a very high tolerance for syntactic ugliness, one could bolt on features 'til the cows come home, and wind up with something a lot like Perl. With a sufficiently high tolerance for semantic ugliness, you could come up with something like TCL.

And each of these languages has an associated power in various domains. C has massive ability at systems programming, Perl can manipulate strings astoundingly well, TCL can be compiled very quickly, and Scheme does none of these things (being simple) but it embeds like the dickens (being simple) and compiles lightning-fast (being simple).

So that's a fine abstraction, but it tells us very little about C versus VB. What's the difference?

C has a higher tolerance than VB for syntactic ugliness, though not nearly as much so as C++ or Perl. Yes, this is subjective, but it's accepted in the vast majority of programming forums that more kinds of punctuation in more random places in the code is generally a bad thing -- Perl's regular expression syntax, much as I love it, is just not a pretty thing. It's also hard to read because density of expression leads to poor reading comprehension, especially if you don't know if there are bugs. Similarly, code that has bits that don't label their functions well is hard to comprehend, and usually ugly. Dylan's structure-definition stuff is a joy to behold, especially if you don't know the language very well. Since it's been awhile for me, don't take this syntax as gospel, but it's reasonbly close:

class <MyClass>
inherit <MyOtherClass>;
field data-one, type: <integer>, setter: data-setter;
end class <MyClass>;

In C++, you have:

class MyClass : public MyOtherClass {
int data_one;
public:
void data_setter(int new_val) { data_one = new_val; }
}

Note how in this class it's less obvious what the individual bits do? You can get away with less keystrokes, at the cost of reading comprehension. And yes, yes, you're welcome to say that somebody that knows the language well will understand what the class declaration does, and you'd be right. But there's a difference between the possible and the pleasant, and if you make it more pleasant, it's usually more maintainable.

So what about C versus VB? Neither looks like Dylan. VB doesn't even usually use classes, at least the way I've seen it done.

C is substantially more powerful than VB for most uses (note: "most uses" here means "stuff I do" -- VB is actually more common than C in the real world, and probably rightly so). Far more powerful. Hands down. It's also uglier, at least the parts I've used. And faster, though that's effectively part of "more powerful".

Thus, VB is to C as C is to C++ -- one is more powerful, and uglier. So rather than saying "why don't we all use VB?", you might have extended the point to "why don't we all use 'Hello World' in Scheme?". It does nothing and is very pretty, so it's the logical conclusion of going for a less-powerful, prettier choice of language.

Of course, if I was saying, "y'know, the Honda Insight is a lot less economical than an Accord considering what the two do", you could equally validly say "well then just walk, cheapskate." This would be why I don't consider it logical. I'm considering a tradeoff, so you assume that if I prefer a trade toward cheapness and lower performance that obviously something that costs nothing and does nothing is perfect.

No. It's a tradeoff. In the same way that I assume you wouldn't want a language with every possible feature, I prefer you not assume that I want a language with no features. I'm considering the cost and the value of using one thing versus another, which is different from taking a single principle and applying it to the absolute utmost.

Maybe I'm wrong. Maybe if there were something with more features than C++, you'd just automatically use that, no matter how ugly and no matter how hard to debug. I don't think so, though.
angelbob is offline   Reply With Quote
Old 04-02-2003, 03:53 AM   #46
Kastagaar
Member
 
Join Date: Apr 2002
Location: Hampshire, UK
Posts: 117
Kastagaar is on a distinguished road
Send a message via Yahoo to Kastagaar
In all the world, I think there are possibly 7 people who fully know C++, and they're all on the C++ standards committee. There are, however, many programmers who know enough C++ to a) be able to use it effectively and b) know where to look when they come across some esoteric aspect of the language. I think it all follows the 90% rule.

I came across an aspect involving the width of an enum when having an int constructed from it just last week. Oh wait, that exists in C, too. And then there's the returning static thing from that poster on TMC. Except that's also the rule in C. Let's ban C, it's too easy to make silly mistakes.

Kas.
Kastagaar is offline   Reply With Quote
Old 04-02-2003, 05:44 PM   #47
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

It's important to note that if we all stated *all* of our premises before every conclusion, we wouldn't be able to argue effectively with our hands so crippled from overtyping =). No, instead, we use a set base of assumptions -- or a ridiculous assumption like my own statement -- and see which parts of it the other party takes issue with. Then we clarify and re-clarify until we get to immutable core principles (and a set of extrapolations based on them) or uncover fallacies. It would be ridiculous for us to specify *every* assumption simply because different sets of people take issue with different assumptions for different reasons.

By all means! Be my guest -- and I'll either clarify why such ridiculous points don't fit the premises, or alter my premises, or point out fallacies, etc. I don't see it as mockery at all, unless it is done continually with no eye towards giving it some intelligent thought.

I agree, and I think this is a good system for rating programming languages in general. Note the underlined portion of this quote: Some languages by necessity must consider more than this (unfortunately) idealistic view. C++, for example, wished to draw from the large body of C users out there. These users absolutely had to have a compiled system because of the large amount of systems programming and performance considerations attributed to the previous language, which makes it very difficult for dynamics. Java is facing the same problems that C++ faced many years ago: Do you keep the cruft and make new versions of the language backwards compatible, or do you do away with it and risk alienating former users of the language? The C++ Standards committee has been bending over backwards to maintain backwards compatibility. What I'm trying to say is that every language has a set of unique considerations over and above the goal of producing good or bad code; that producing good or bad code, while an important consideration, is something that must be balanced against other important considerations.

These other considerations particularly shine in the mud community. Because of the backwards compatibility with C, a coder can port their source over to take advantage of certain features (like strings, linked list objects that are decoupled from the object they store, and constructors/destructors to initialize memory and subsequently free it) while still maintaining the large body of code that they have already written.

I wouldn't say that a language with few features is irritating =). I've been enjoying greatly my time with a ridiculously simple (but still quite powerful) language called =).

Great! I'm glad we agree =). My only goal is recognizance that one language is not best suited for all purposes. Even languages like Brain**** are useful for modeling how one needs to do things on a pure Turing machine.

Right, that's what I usually go by. I don't expect someone to literally fully know a language -- that would be pretty silly =). But it's easy to tell people that have achieved a certain mastery over a language. They can generally sense if something's not right in the code, and lookup the answer to solve most problems they have.
Yui Unifex is offline   Reply With Quote
Old 04-03-2003, 02:43 PM   #48
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
My experience has been that a problem involving a feature I have trouble understanding, or with serious subtleties, will take many times as long to debug. You can produce those in C as well (or any language), granted, though I've found that every situation in C where I have that problem involves a lot of indirection (pointers). Then again, I'm very comfortable with a lot of the parts of C that tend to give many people problems like unions, signedness, widths and bit-layout, and bitwise operators, so it's entirely possible that there are other features of C where other people would have problems like you describe.

If 10% of your problems take 10 times as long to debug as the other 90% (which is about right for me and C++ in my experience), you wind up spending half of your time on that 10%. That's fine if that's where the meat of your problem is, and in that case it's fully justified. But I've found that in C++ I wind up spending way too much time on trivial problems caused by nasty syntax or questionably-designed language features.

In C, I still spend half my time on 10% of my problems. But they're the 10% that occur in places with genuinely weird logic where the hard part is figuring out the algorithm. That'd be the right 10% to my mind.

There are certainly language features in C that could be clarified, changed or banned. Like I say, I'd love to have references in C, especially if pointers could be easily identified by the very distinctive syntax they required. Star and ampersand are okay except that star is used for multiplication as well, and pointers are currently used too readily.

And as far as figuring out what size an enum is, granted, that should be standardized. But it has the same problem C has always had -- too many platforms. C is old enough that it can't even be sure that its integer types are multiples of eight bits. Scary but true.

I haven't seen the returning static thing. I'll take your word for it.

And yes, it *is* too easy to make silly mistakes in C. I'll run the risk of irritating Yui by blaming some of that on the language designers :-)
angelbob is offline   Reply With Quote
Old 04-03-2003, 02:56 PM   #49
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
Yup. Poor schmucks, they fell for it :-) You're welcome to justify this way ("C++ may be ugly, but it had to be in order to get popular"), but I'm not sure it's helping your case.

Yup. C++ takes a lot of flak for every instance where the same code (in C, like) compiles to something slower. It doesn't seem to take the same flak for all the places where the C code gets bigger, but that's neither here nor there. Unless you work for someplace like Palm, and then you just don't use C++ :-)

And, oddly enough, doing quite well by it. But then Java has a marketing budget like no language before it. I *do* think it's a step in the right direction from C++. Or the wrong direction from most dynamic languages, so it depends how you look at it :-)

The performance thing that you mention is a good point. Languages certainly must be designed with efficiency in mind. Whether that's programmer-time efficiency, cpu-time efficiency, memory-efficiency or something else determines a lot about the language.

I consider popularity concerns ("if it doesn't look like C, nobody will use it") and time-to-market concerns ("but we don't have time to make a real VM language for Java! Use the language directly") pretty irrelevant to whether I should use the language, and what I should use it for. Instead I'll judge it based on its actual merits ("gee, that's a lot uglier than C" and "gee, that's really slow", respectively, in the two examples above).

Yup. Speaking of ugly code. It gives you all the syntactic ugliness of C++ and the reduced range of debugging tools, but without the object-oriented design.
You can say "but you can refactor". The codebase has to be *very* clean and *very* OO already for that to work well, though, especially at the talent level of most current MUD coders.
angelbob is offline   Reply With Quote
Old 04-03-2003, 03:01 PM   #50
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

You know, irritating me is really not as easy as you think it is ;). Even though I may argue for one side or another, I don't particularly associate any emotional state with their successes or failures. You've made this same mistake twice now, and I don't expect you to make it again! =)
Yui Unifex is offline   Reply With Quote
Old 04-03-2003, 03:43 PM   #51
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

What case is that? If it's the one where I stated that C++ is cleaner than C for some purposes (and to which you agreed), then that's already been proven. I am simply discussing what considerations the language designers were bound to over and above the features you describe. But you're missing an important point (and oddly enough, one that you quoted):
I don't think the language designers were all sitting around a table thinking about designing a totally new language when suddenly one of them had the brilliant idea to base it off C. No, it evolved from C; rather than itself being a separate entity. So no, I don't "justify this way", I'm simply telling you how things probably were back then. Now you should understand that C++ isn't the way it is just because it wanted to be popular, but because it wanted to supplement C.

That's fine. Just be aware that 'actual merits' for some people include backwards compatibility with their previous codebases and ways of doing things.

You mean syntactic ugliness like:
[code] /* C version */
char *build_magic_string (...) {
static char magic[256];
...
return magic;
}[/quote]
As opposed to:
[code] // C++ version
string build_magic_string (...) {
string magic;
...
return magic;
}[/quote]
And all that reduced range of debugging tools, like the exact same debugger and tools they were using before? Yeah. You got me there.

The lack of forced object-oriented design is an incredible plus when you simply want to take advantage of one or two features but also want your codebase to use the same idioms and design as before. Many C++ codebases use procedural C code, and this is a very good thing for programmers, because they have to do a minimal amount of porting. If you're suggesting that to take advantage of a few useful features, a programmer should have to refactor and redesign his codebase, you're crazier than I thought you were.
Yui Unifex is offline   Reply With Quote
Old 04-03-2003, 05:06 PM   #52
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
I'd been arguing (for pretty much this whole thread) that C++ tends to encourage bad code. We then hit the point last page where I suggested a metric for programming languages based on whether their feature set encouraged clean code. It sounds like you're apologizing for C++ scoring badly on that metric by saying it gains C backwards-compatibility in return. Is that what you're doing?

Well, yes. It started off as a preprocessor. I still choose to judge it on its merits as a language. You're welcome to judge it on its history as a language instead, but I'll laugh at you.

I'm aware of that. And you misspelled "supplant" ;-)

Actually, no. I was thinking of template syntax and class declaration syntax. The couple of things you can do with C++ without classes or templates or operator overloading are kinda cool. I wouldn't take the extra space hit in return for default arguments to functions, and they're not done that well anyway, but they're not bad. Not excellent, but they *are* one of the early things that worked in a preprocessor. So I provide them historical slack, if not slack on actual execution (satisfied?)

Well, other than purify working right. And many profilers. And a bunch of memory debugging tools. But if "the exact same debugger and tools they were using before" is VC++, you're right. So yeah, if you only use your compiler and one debugger, you're probably golden. In that case, there's no such thing as a "reduced range of debugging tools" except "no debugging tools", though, so I can see why you take exception.

You seem to read a lot of my mental state into my random utterances, so would probably be hard for me to be crazier than you thought I was and still successfully use a keyboard.

The problem with giving the programmer "a few useful features" and letting him run with it is that he'll either hate them, in which case nothing will happen, or he'll like them and use them everywhere. It's that second scenario, the one where you bastardize the codebase by adding a second paradigm on top of the first one, that gets folks into trouble.

Do I think that people should redesign their whole codebase to add a few useful features? No. But I find that adding a few useful *language* features after the fact is usually a major inviation to trouble. I've seen it work, mostly, by adding callout to another language. Usually that means that most developers on the project only know one language or the other. There are at least well-documented interfaces between the two, but debugging anything cross-language remains a pain.

You can add features after the fact with an extra preprocessor, too, the way C++ used to work. SGI apparently does their arcane template-like data structure stuff that way. By and large, though, nobody does. Why do you think that is? My vote would be: adding features to the language, especially when you have a large existing codebase, is usually an invitation to trouble.

By contrast, switching languages entirely guarantees that you do *not* have a large existing codebase, one way or the other. Am I in favor of switching languages instead? Not usually. Usually I'm in favor of keeping your large existing codebase in the language in which it was written, or rewriting it pretty much entirely.
angelbob is offline   Reply With Quote
Old 04-03-2003, 07:38 PM   #53
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

Allow me to clarify your confusion with a quote:
I am simply providing a reason why languages often must consider more than your metric. I even said that it was a good metric, I simply had issues about its completeness. I'm not apologizing for anything out here, and I'll be the first one to say that certain things have been done far better in other languages. I simply wish to widen the view that you provided.

You're being silly. I offer some history and a major feature related to that history, and you say I'm judging entirely by the history. This feature is even part of the "important point" I had to quote due to your missing it the first time! Now you've missed it again *and* leapt to a false conclusion. For shame. To make it completely black and white to you: This history shows why C++ is backwards compatible with C. I judge by *features* not history, and this is a ridiculously important feature.

I meant what I said.

If you're talking about Rational Purify, it does indeed support C++. If you're talking about Pure Software's Purify, it also supports C++. If the exact same debugger and tools is gdb, gprof, and valgrind, which is what the vast majority of the mud community uses, then I'm also right. Most memory debugging tools I've used simply preload and hook into malloc/free, so they don't care what language is being used. Of course all of the C-compliant code that you write is still debuggable by the C-only tools (like lint), but there is a C++ equivalent for almost any operation.

It's a good thing we have you to clarify the psychology of the programmer. Don't you think that it's best to let the programmer decide what he wants to do, rather than deciding it for him? I can think of dozens of scenarios where moving a C codebase to C++ don't include your two extrapolations: It could be for library support (yes, there are C++-only libraries), educational purposes, or to sync the codebase with with a planned migration to a different paradigm in which individual modules are added onto or replaced.

I think the people over at Trolltech would disagree with you, and they're adding features onto an already large featureset. For those that aren't aware of the best gui toolkit around, Qt uses a meta-object compiler to add signal/slot functionality to C++.
Yui Unifex is offline   Reply With Quote
Old 04-04-2003, 03:58 PM   #54
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
How hard are you willing to work to turn the tone of this into a flame war? We've already got all the usual attributes of one, but we've managed to stay reasonably civil and on-topic.

But yes, you did in fact offer a major feature. I still choose not to weight the history itself in my consideration of the language. I weight the feature in my consideration of the language, and I in fact debate precisely that feature later in the same message. I'm not ignoring that feature, no matter how many time you repeat that I am. Happy?

They're actually different revisions of the same software. Pure Software merged to become Pure/Atria, which was bought by Rational. So yes, I'm talking about both. Have you actually used the C++ support you mention, say with VC++, on an actual project? They have several *really* annoying bugs that make sorting through the warnings in C++ take several times as long. That whole mismatched new/free warning is the main culprit, though there are several other things that make it hard enough to track down that I'm 90% sure they don't use C++ much internally.
I haven't used the new Rational revision with gcc/g++ on a Unix system, only the older Pure Software version. It also has serious bugs that make it hard to use, but the new (far more expensive) version might fix that.

Interesting. I'm not familiar with valgrind, I'll look it up. Yes, I was referring to gprof, as well as tools like ElectricFence.

And if you don't care what function is being called, or whether the tool can deal with extra layers of function calls and name-mangling, you're golden. Of course, if the tool *doesn't* deal gracefully (in a way specific to your C++ compiler) with name-mangling...

So basically, you're not in favor of language designers doing *anything* besides tacking on features until the whole edifice collapses? Are you a big Ada fan, then? It was something like ten years after their language standardization before they had a compiler that supported them all. C++ only managed the more modest feat of taking ten years to hash out the details, at least those that were ever agreed on.

I believe that by and large, simple clean languages are a very good idea. I believe that languages like C++ and Perl (which I would put near the far opposite end of the current spectrum from "simple, clean languages") have very specific uses, but primarily those uses boil down to "prototyping". I believe that a hybrid prototyping/systems language (like C++) encourages people to build on those prototypes to turn them into the finished product, which creates lousy finished products (see "The Mythical Man-Month" for more on this phenomenon -- I know you've read it, you recommend it on your site).

I'm well aware of them. We were busily locking the programmers into specific C++ compilers by including some of them in the Operating System when I left Palm. While related, that's not actually the reason I left Palm.

This comes closest to a good reason for a mixed-paradigm language (between Procedural/Systems and OO, anyway) of any I've heard.
I've never seen this done well, though I've seen it done badly many times. I'm referring specifically to C-to-C++ transitions when I say that.

Here, let me ask you a question as a thought exercise, and because I need to know how crazy *I* should consider *you*. Say there was a tool which advertised a particular service, but didn't usefully perform. Using that tool was always worse than not using that tool for the advertised purposes. There were conceivable uses for the tool, but the common and advertised ones weren't really among them.
Should the tool exist?

I'm a GTK+ man, myself. They do a full dynamic inheritance system for widgets in C rather than preprocessing C++ to get the same result. I'd expect (sight unseen) that the Qt way requires storing less of the type system at runtime, but allows for less adding dynamic stuff at runtime. S'okay, I like dynamic type systems better than I like decreased memory footprint when it comes to GUI toolkits on the desktop. Where memory footprint matters (at Palm, for instance) we used neither so it was a non-issue.

If Qt is preprocessing C++ to add features then I'll remember to avoid it. "Meta-object compiler" is certainly a lovely euphemism for that, though.
angelbob is offline   Reply With Quote
Old 04-04-2003, 05:33 PM   #55
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

My issue is not necessarily with you ignoring the feature, but with you believing that I'm judging based on the history rather than the feature here:
I used it for a little while on a project, but I ended up moving the development to a Linux machine with valgrind. I honestly didn't give Rational Purify as much use as I've given valgrind, though, so I wasn't aware of any of the bugs it had with C++.

gprof has a switch that can be toggled for C++ name mangling. Interestingly enough, I just checked the manpage on FreeBSD 4.5 and 5.0, and couldn't find the switch in the manual. I'm positive it's in the Linux manpage, though. I haven't used ElectricFence.

I don't think that this conclusion follows from my statement. I'm in favor of language designers adding features that make a language more useful than it is, and properly weighing the constructs involved in any given feature to make them consistent, clean, and unobtrusive. Some constructs (like Ruby's incredible object orientation and concept of iterators) do away with things like the 'for' loop, but since there is a satisfactory alternative, I don't think that the designers should concentrate on adding a for loop. From what I hear about C99 and the C++0x standardization process, designing a language is very, very difficult and time-consuming. So while I agree that there are very few features that I would *not* want to have in a language, designers often have other overriding concerns and adding 'ugly' features simply becomes a matter of priority, as they fall to the bottom of things to be done. To be idealistic, if I could have a language that did anything I could ever want and much more, so long as the 'much more' part did not impact the performance of the 'anything I could ever want' part, I'd use it. For now, I simply have to pick and choose various languages based on how well their particular philosophies fit what I want to build, which makes crossovers (such as a rapidly-developed but performance-critical application) much more difficult to write (because of interface concerns) than I believe it should be.

I'm not sure if I'm a fan of it... I've never used it =).

This is an interesting question, but I don't think I'm in a position to answer a yes or no here. Oftentimes the common and advertised uses for something fall by the wayside as people think up innovative uses for things, so it's difficult to tell where something really fits in with one's goals. If someone else has an interest in the tool, who am I to tell him that the tool should not exist? If noone has an interest in the tool, why is it worth my time to even consider its existance? If many people hate the tool, and I have no interest in it, I probably wouldn't stop them from causing it to cease to exist, but I would take no action myself. If I have an interest in one of the tool's uses, then I would probably think that it should exist. This is presumably because I have evaluated my options in relation to the particular use and the tool, and have decided that using the tool over some other tool was in my best interests.

The signals and slots are dynamic, and type-safe.
Yui Unifex is offline   Reply With Quote
Old 04-07-2003, 07:03 PM   #56
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
<i>"From what I hear about C99 and the C++0x standardization process, designing a language is very, very difficult and time-consuming."</i>

Yup. Though it's amusing how many people manage to randomly do it on-line without nearly as much time or effort.

The big difference between them and what standards bodies are trying to do is that most people spell out what their implementation does, but not what the language guarantees. You're probably familiar with the same distinction from designing libraries -- "if you do this, the behavior is undefined", even though your library may always do the same thing in response to that. You just don't want to guarantee it forever, or in all circumstances.

Plus, of course, the standards bodies are dealing with established languages and so they have to deal with implementation issues a lot more carefully than most, and they usually need to do so without taking the time to actually implement the changes they mention. A difficult job, that. Particularly in C++ where different compilers still do genuinely different things to implement certain features, so it can be hard to tell if you're breaking something that somebody's doing.

A decent C++ ABI (Application Binary Interface) would solve a lot of that problem, but that's been "just about to happen" for ten years and counting so I'm not holding my breath.
angelbob is offline   Reply With Quote
Old 05-05-2003, 07:02 PM   #57
visko
Member
 
Join Date: May 2002
Posts: 98
visko is on a distinguished road
Send a message via ICQ to visko Send a message via AIM to visko
Hey there,

I've been watching this thread for a while now, and I've actually recommended it to a few programmers I know who like to rant on and on about this very topic. Having very little programming experience total to draw from, and none in the area of C++, I've had to take what I could from the thread, mainly looking at the philosophies of each person and deciding which made more sense to me.

In the end, I have no opinion on which is a "better" language. However: Yui, go work for M$. Their PR department would worship you.

-Visko
visko is offline   Reply With Quote
Old 05-05-2003, 07:33 PM   #58
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
For the Evil Empire?!

I think that MS' style of C++ is one of the best, most prominent examples of how you can go wrong with the language =).
Yui Unifex is offline   Reply With Quote
Old 05-05-2003, 11:17 PM   #59
Ingham
 
Posts: n/a
10 PRINT "I code my MUD in BASIC!"
20 GOTO 10
  Reply With Quote
Old 05-06-2003, 06:03 AM   #60
Kastagaar
Member
 
Join Date: Apr 2002
Location: Hampshire, UK
Posts: 117
Kastagaar is on a distinguished road
Send a message via Yahoo to Kastagaar
Are you talking about Hungarian, The Code That Is MFC, all of the above or something else?

Kas.

(Edit: Ack! that came out bad first time around)
Kastagaar is offline   Reply With Quote
Reply


Thread Tools


Which is preferred? - Similar Threads
Thread Thread Starter Forum Replies Last Post
Preferred Role Playing Level enigma@zebedee Advertising for Players 27 04-23-2003 07:01 AM

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 10:56 AM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2022