[angelbob]

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.