[Yui Unifex]

Originally Posted by (Yui Unifex @ foo) What? Given that almost all projects spend most of their lifetime in the maintenance stage, I obviously wouldn't know how to take advantage of Perl's features if I couldn't read or modify it.

Originally Posted by (angelbob @ foo) As you say, most projects spend the vast majority of their time and effort in the maintenance stages. Features that are hard to read are a fine example of wasting effort -- how many times do you read code compared to how often you write it? With that said: sure, whatever.

Originally Posted by (angelbob @ foo) This kinda contradicts your statement, earlier in the same message, that you're in favor even of features that are easy to write but hard to read or modify.

I am in favor of choice in all features. If one is doing rapid development or prototyping, those features can be immensely useful. So long as these features are not mandatory I am in favor of them. Since I have said this many times and you still can't seem to grasp it: I am in favor of optional features.

Originally Posted by (angelbob @ bar) For instance, I've had a bug where typecasting from one C++ type to another (legally, within the heirarchy, from a parent to a child class, yes) changed the numerical value of the pointer. So the literal value of the pointer was different than if you typecast to a void pointer in between. This is a fine example of a case where the "feature" is so "interesting" that even most people who use it don't know how to debug it.

Sounds like either you did something wrong here or you ran into a compiler bug. If assigning the memory address of a child to a parent is legal, and downcasting changes the value of the memory address of the child, you would wreak havoc on your data. Way to go, blaming somebody else's irresponsibility on language designers.

Originally Posted by (angelbob @ bar) I was lucky -- I distrust C++, so every feature that I use, I understand down to the bitwise level.

You obviously didn't know that the above wasn't the language's fault, you didn't know that you could catch exceptions at runtime inside of operators, you didn't know that operators could be debugged just like normal functions... I'd say you have a pretty poor understanding of these features of C++ that you've used -- supposing that you've used the features that you're arguing about.

Originally Posted by (Yui Unifex @ baz) To go against the style of the project is both unprofessional and sloppy, no matter how poor the style of the original project is. If you think your style is better than the one being used, hash it out with the project manager.

Originally Posted by (angelbob @ baz) A good project manager will never change a project's coding style, simply because of the amount of legacy code involved. In a corporation, justifying the massive time and expense of changing all the old code is basically impossible. I wish it weren't.

Exactly. Because the project manager understands that changing the style of the entire codebase is a large undertaking (without a beautifier, of course), and he knows that individual coders should not go gung-ho on styles because that leads to inconsistency.

Originally Posted by (angelbob @ foo) The problem doesn't tend to be people wilfully ignoring the standard. It's that the standard isn't usually very complete , programmers don't fully know the language (as we agreed, that's pandemic in C++), and they don't fully remember the project coding guidelines and aren't going to go dig them up before writing more code. It's not maliciousness, just negligence.

And the language designers are not responsible for your organization's negligance.

Originally Posted by (angelbob @ bar) If you believe that C++ guantees privacy to private members, let me give you a nasty little example: class myclass { private: int bob; int sam; public: void playwithbobandsam(void); } /* Nasty code: */ myclass victim; ((int*)victim)[0] = 7; /* Set bob to 7 */ ((int*)victim)[1] = 9; /* Set sam to 9 */

Yes, I just knew that the C++ language designers should have guarunteed the privacy of data once undefined operations have occurred. Anybody that has access to the memory behind your class can change it; a language can never guaruntee such a thing without total control of the OS. If you expect the integrity of your class (which private members are supposed to help protect, but cannot protect absolutely) to be maintained when you've done something as brain damaged as the above code fragment, you're living in a dream world.

Originally Posted by (angelbob @ baz) Where's your strong typing now? Destroyed by pointers.

More like destroyed by idiocy... Give me any language with "strong typing" and I'll destroy its integrity by modifying its memory. You've set unreasonable standards for strong typing that no language can live up to.

Originally Posted by (angelbob @ foo) angelbob: Specialization *restricts* the vocabulary of an individual, and even of a socity. Yui: Not even close. Name one speciality that *restricts* your vocabulary rather than merely drilling down into the complexity of a subject. angelbob: I already did with the "ceramic and glass" thing in the original message, but I'll continue, shall I?

Originally Posted by (angelbob @ original message) ...you see practically nobody that works in clay/glass hybrid objects because those are considered separate specializations so there's little overlap

"nobody works in both ceramic and glass" is not the same thing as "working in ceramics restricts your working with glass". Take a course or two in logic and call me in the morning.

Originally Posted by (angelbob @ bar) Let's say that we have a (natural) language which is English plus Swahili, the full union of the two. Both are complex, and both have a pretty substantial vocabulary. An average speaker is now *less* likely to understand another average speaker, and will be far more likely to need a dictionary to accomplish anything. Speech is now more difficult, comprehension rarer and the whole thing is less effort.

There are millions of people that speak more than one language fluently. Just because angelbob came in and said that this was too difficult to comprehend doesn't stop them from using whichever subsets of that language they feel would best express their thoughts. The real shocker is that these people can still communicate pretty effectively with people that only speak one of the languages they know; obviously they wouldn't be able to communicate if they expressed their thoughts in the language that their target did not know. It is up to the speaker and the speakee to negotiate this -- not you.

Originally Posted by (angelbob @ baz) You continue to argue that language designers shouldn't avoid features just because they can be misused, or are usually misused (see "goto", above). But you're ignoring the fact that a very broad language with a vast array of features is harder to comprehend, harder to debug and harder for other people to get up to speed on or contribute to.

So we should all use VB. C sucks because it's got language features that are hard to understand (pointers! strings as arrays!). Glad that's settled now.

[Yui Unifex]

Almost forgot this gem:

Originally Posted by (angelbob @ foo) Languages with serious type systems (CommonLISP/CLOS, Smalltalk, Dylan) or runtime type systems (Perl, Python, CommonLISP/CLOS, Dylan, LPC) both tend to do better in this respect since they don't have a static type system that can be easily messed with.

Um, ocaml has Obj.magic that allows you to do similar things to the C++ pointer casting. GNU Smalltalk allows one to directly access the memory behind classes, look at the typeAt accessors. So yes, languages with 'serious type systems' also cannot live up to the silly standards you've created.

[Lindahl]

Originally Posted by You continue to argue that language designers shouldn't avoid features just because they can be misused, or are usually misused (see "goto", above). But you're ignoring the fact that a very broad language with a vast array of features is harder to comprehend, harder to debug and harder for other people to get up to speed on or contribute to. So we should all use VB. C sucks because it's got language features that are hard to understand (pointers! strings as arrays!. Glad that's settled now.

In fact, I'd argue that pointers cause more problems in C/C++ than the combination of all features in C++. Should we remove them from the language? Does that make pointers a bad idea? Not at all, it allows the programmer to operate the code at a lower level.

[angelbob]

Originally Posted by angelbob: For instance, I've had a bug where typecasting from one C++ type to another (legally, within the heirarchy, from a parent to a child class, yes) changed the numerical value of the pointer. [...] Yui: Sounds like either you did something wrong here or you ran into a compiler bug.

You could argue that the former is true. The latter is not. That's actually expected behavior. Try it yourself. Create a class A and a class B (I used both virtual, but you don't have to). Make a class C that inherits from both. Typecast a C-pointer to an A-pointer and a B-pointer. Print out the numerical values of all pointers concerned. One, but not both, of the A-pointer and the B-pointer will be the same as the C-pointer. The other will not. There's no decent way around this. If you typecast to a void pointer in between, there's no way for the language to know what the fudged fixup modifier is, so it just leaves the pointer numerically the same, which breaks either the A-pointer or the B-pointer. Usually the first parent class is fine and all later parent classes break -- that's how VC++ does it, and I think GCC as well.

Originally Posted by If assigning the memory address of a child to a parent is legal, and downcasting changes the value of the memory address of the child, you would wreak havoc on your data. Way to go, blaming somebody else's irresponsibility on language designers.

Whose responsibility is that, if not the language designers? The compiler writers, I guess. I'm not sure. Who are you blaming here, besides me? The language doesn't specify the bitwise layout that causes this problem, it just specifies a situation where you pretty much have to do it this way, so everyone does.

Originally Posted by angelbob: I was lucky -- I distrust C++, so every feature that I use, I understand down to the bitwise level. Yui: You obviously didn't know that the above wasn't the language's fault, you didn't know that you could catch exceptions at runtime inside of operators, you didn't know that operators could be debugged just like normal functions... I'd say you have a pretty poor understanding of these features of C++ that you've used -- supposing that you've used the features that you're arguing about.

Actually, I was well aware that you can use exceptions. I've just used compilers that support them poorly, so I don't use them. I've also worked with programmers that understood them poorly so (thank God) we didn't use them. And I'm aware that you can debug an operator like any other function, and that debuggers tend to support it poorly, and you can't return an error code, and using it in questionably-matched problem domains is (still) a bad idea.

Originally Posted by angelbob: The problem doesn't tend to be people wilfully ignoring the standard. It's that the standard isn't usually very complete , programmers don't fully know the language (as we agreed, that's pandemic in C++), and they don't fully remember the project coding guidelines and aren't going to go dig them up before writing more code. It's not maliciousness, just negligence. Yui: And the language designers are not responsible for your organization's negligance.

And yet they do so much to enable it in C++, and so little in a number of other languages.

Originally Posted by Yes, I just knew that the C++ language designers should have guarunteed the privacy of data once undefined operations have occurred.

Well, if not then having a "strong type system" deserves to be in quotes, as I continue to express it.

Originally Posted by "nobody works in both ceramic and glass" is not the same thing as "working in ceramics restricts your working with glass". Take a course or two in logic and call me in the morning.

You're assuming that anything that isn't directly ruled out isn't affected. You're also assuming that anything optional will have no bad effects on behavior. You know how silly that sounds, right?

"We made sure that murder was optional, so we figure it won't cause any problems. Our laws aren't responsible for your neighbor's maliciousness. Move to a better neighborhood."

Originally Posted by angelbob: ... English plus Swahili ... Yui: There are millions of people that speak more than one language fluently. Just because angelbob came in and said that this was too difficult to comprehend doesn't stop them from using whichever subsets of that language they feel would best express their thoughts.

Even in Switzerland (and similar places) where they have more than one official language and more than one language commonly spoken, they tend to speak only one. If adding features is always good, why don't the Swiss constantly speak a French/German/English pidgin to everyone they meet? They know all the component parts, and so does almost everybody they speak to. Is it just angelbob-style contrariness on their part?

Originally Posted by The real shocker is that these people can still communicate pretty effectively with people that only speak one of the languages they know; obviously they wouldn't be able to communicate if they expressed their thoughts in the language that their target did not know. It is up to the speaker and the speakee to negotiate this -- not you.

And yet if they were writing for a mass audience, or even more than one person, they'd still be better off choosing one or the other and sticking to it. And the fact that the two languages are independently defined (are the subsets of C++? Where?) means that they can easily and quickly determine what subset to use, and they don't have to remember individually whether, for instance, Swahili animal names are being used with English grammars in this specific setting.

Originally Posted by So we should all use VB. C sucks because it's got language features that are hard to understand (pointers! strings as arrays!. Glad that's settled now.

Shall I throw your comment about a class in logic back at you now, or wait until later?

To make this explicit: you've taken my position, extended it to its most ridiculous extreme, and thrown it back at me as though I'd said it. "All those liberals should just move to Iraq".

[angelbob]

Originally Posted by angelbob: Languages with serious type systems (...) or runtime type systems (...) both tend to do better in this respect since they don't have a static type system that can be easily messed with. Yui: Um, ocaml has Obj.magic that allows you to do similar things to the C++ pointer casting. GNU Smalltalk allows one to directly access the memory behind classes, look at the typeAt accessors. So yes, languages with 'serious type systems' also cannot live up to the silly standards you've created.

Actually, languages can. You're reduced to mentioning nonstandard extensions to particular implementations to prove me wrong. The language is fine as designed, but it's been sabotaged by a bad implementation.

Besides, they've made it difficult, and they've made it easy to recognize when somebody's doing that. C and C++ don't go so far as that, alas. C-but-with-references would make a quite nice little language. LPC is a bit like that, which is one reason I'm using it.

And DGD lives up to my silly standards surprisingly nicely since I don't use any nonstandard driver extensions.

And from Lindahl (hello!:

Originally Posted by In fact, I'd argue that pointers cause more problems in C/C++ than the combination of all features in C++. Should we remove them from the language? Does that make pointers a bad idea? Not at all, it allows the programmer to operate the code at a lower level.

I'd agree that pointers cause as many problems as all the C++ stuff. I think replacing them with references, or adding references and making pointers hard/obvious to use would go a long way toward cleaning up the language. Making them obvious (as with the GNU Smalltalk example) could be sufficient since anybody can have a look and see easily who is doing something ill-advised. A checkin script and "grep", for instance, would do that nicely. It makes enforcement possible, as it isn't really in the existing language.

[angelbob]

Originally Posted by There are millions of people that speak more than one language fluently. Just because angelbob came in and said that this was too difficult to comprehend doesn't stop them from using whichever subsets of that language they feel would best express their thoughts.

Here's maybe a better example. There are many languages where it's common to know multiple at once. English and Spanish is a common combination, as is French with German (again, as in Switzerland).

These combinations obviously give a combined language with more expressivity than either one individually. French and English are both legendary for their ability to express uncommon and subtle shades of meaning, when used by an excellent speaker. So English-plus-Spanish must beat the #### out of Spanish, and French-plus-German must beat the #### out of German.

There are academic treatises that occasionally intersperse specific phrases in other languages ("Gestalt" being used as a psychiatric term, for instance). They almost universally go to the trouble of defining those terms, or make them entirely optional to understanding the text rather than using them fully (as with books containing random quotes in Latin at the start of chapters). That seems odd given your contention that more features always makes a language better, and given the obviously greater expressivity of those combined languages. Where are all the books written in French-plus-German?

[angelbob]

Originally Posted by There are millions of people that speak more than one language fluently. Just because angelbob came in and said that this was too difficult to comprehend doesn't stop them from using whichever subsets of that language they feel would best express their thoughts.

Ah, here we go. You're representing me as though I were saying "C++ shouldn't exist." Do you remember, way back when, what this thread was about? Somebody asked for a language recommendation.

If I thought English was the right language to use, I wouldn't recommend English-plus-Swahili, even if everybody involved spoke both English and Swahili. Why not? Because some day, God forbid, somebody new might show up on the project, and making sure they're fluent in English-plus-Swahili is a lot harder than making sure they're fluent in English. As a culture Imperialist (yup, guilty as charged) I believe that English © is better than Swahili (single-dispatch OO done on top of pointers) so I feel that an unholy hybrid of the languages gains very little on top of English, and causes more problems than it solves.

I'm not saying people shouldn't speak whatever unholy hybrid they like in the privacy of their own homes. But if somebody asks me "C/English or a hybrid?" I'll immediately answer "C/English" without a qualm and without batting an eyebrow.

I *do* like OO for some things. It's just that what I think of as OO is very poorly represented by C++. LPC isn't all that much better but it cleans up most of the worst nastiness. Java does too, though less so.

Dylan's awfully nice. I'll never write a MUD in it, though, since there'd never be a second developer on the project.

C++? Nope. Too many of its "benefits" over C are things that I would never use personally, and that I've usually seen used badly by other people. Since I would never want to debug another developer's C++ code submissions, I say "C" not "C++".

Is the context clearer now?

[Yui Unifex]

Originally Posted by (angelbob @ foo) You could argue that the former is true. The latter is not. That's actually expected behavior. Try it yourself. Create a class A and a class B (I used both virtual, but you don't have to). Make a class C that inherits from both.

I see you're using multiple inheritence -- I'm sorry, I must have misunderstood your earlier post and thought that it was a single hierarchy.

It is plainly obvious why this is not a bug, however: Class A and class B simply can not share the same memory address. When assigning a pointer to one of the parents here, you have to grab the part of C where B starts. So you should get an address like sizeof(overlapping parent)+sizeof(object overhead)+address. So what exactly is the problem here? The only way to fix this would be to make A and B both share the same address, and that's impossible.

Originally Posted by (angelbob @ bar) And I'm aware that you can debug an operator like any other function, and that debuggers tend to support it poorly, and you can't return an error code.

You can return an error code from "in place" operators where the "real" return value is not something essential to the operation. This tends to break other idioms and is certain to confuse readers of your code, but it's definately possible.

Originally Posted by (Yui Unifex @ baz) And the language designers are not responsible for your organization's negligance.

Originally Posted by (angelbob @ baz) And yet they do so much to enable it in C++, and so little in a number of other languages.

Few non-functional, non-dynamic languages have achieved the flexibility and genericity that C++ has. Every one of the features you consider 'bad' has a use that would cause severe detriment were it removed.

Originally Posted by (Yui Unifex @ foo) "nobody works in both ceramic and glass" is not the same thing as "working in ceramics restricts your working with glass". Take a course or two in logic and call me in the morning.

Originally Posted by (angelbob @ foo) You're assuming that anything that isn't directly ruled out isn't affected.

That is incorrect. I said that they were not the same as each other. I don't know where you came up with this.

Originally Posted by (angelbob @ foo) You're also assuming that anything optional will have no bad effects on behavior.

That is also incorrect. Where did this come from?

I don't think you understood me here. Restricting people from working in both ceramics and glass is radically different than allowing people to choose a specialty of their own accord. In one case, people are forced into what they do. In the other, they still have the choice to make some sort of ceramic-glass hybrid (It'll take the world by storm!) if they felt like it. As you can see, they are plainly not the same thing.

Originally Posted by (angelbob @ bar) "We made sure that murder was optional, so we figure it won't cause any problems. Our laws aren't responsible for your neighbor's maliciousness. Move to a better neighborhood."

Here we move into the realm of principle. More on this in another post.

Originally Posted by (angelbob @ baz) If adding features is always good, why don't the Swiss constantly speak a French/German/English pidgin to everyone they meet? They know all the component parts, and so does almost everybody they speak to.

I'm not Swiss, nor am I a Sociologist, nor am I in a position to understand their situation. But anyone with a little savoir-faire knows that parts of languages tend to seep into others, neh?

Originally Posted by (angelbob @ foo) And yet if they were writing for a mass audience, or even more than one person, they'd still be better off choosing one or the other and sticking to it.

Just as all people do not always write for a mass audience, all programmers do not always write for a mass audience.

Originally Posted by (Yui Unifex @ bar) So we should all use VB. C sucks because it's got language features that are hard to understand (pointers! strings as arrays!). Glad that's settled now.

Originally Posted by (angelbob @ bar) Shall I throw your comment about a class in logic back at you now, or wait until later? To make this explicit: you've taken my position, extended it to its most ridiculous extreme, and thrown it back at me as though I'd said it.

This is a common tactic amongst logicians, to see how a particular argument stands up to scrutiny. If an argument or position, through extrapolation, condones something that is unacceptable, the argument or position must be revised to correct it. By doing this, I hope that you will either clarify your argument so that the unacceptable situation is avoided, or modify your argument for the same effect. In essence: What makes C and C++ so special that your logic only applies to it and not C and VB? Specifically, the part about certain features being confusing (on average) and thus should be removed from the language.

Originally Posted by (angelbob @ baz) Actually, languages can. You're reduced to mentioning nonstandard extensions to particular implementations to prove me wrong.

Even if a language design document states "Private members are never accessible under any circumstances not controlled by the class", these extensions (btw, Obj.magic is part of ocaml's standard library) prove that they were useful enough to include. Even still, one that relies on private members as anything more than a way to keep oneself from making stupid mistakes with regards to encapsulation of data is placing far too much trust in their environment.

Furthermore, unfettered access to a class' memory is very useful for those languages which lack functional properties like closures. It is useful for serialization and optimizations that scrunch classes together to avoid overhead, like a memory pool. There are thousands of C libraries which C++ was designed to interoperate with, that require a void or char pointer and a size, and then provide an operation on that memory. C++ wouldn't be operating as designed if it did not provide this functionality, and provide it easily.

Originally Posted by (angelbob @ foo) I'd agree that pointers cause as many problems as all the C++ stuff. I think replacing them with references, or adding references and making pointers hard/obvious to use would go a long way toward cleaning up the language.

They're pretty obvious: Every time you see the dereference operator (&), look for an address to be used. References and pointers are too different things.

References come with their own problems. They aren't re-assignable, so you are forced to encapsulate changes to them which causes problems with iteration constructs. They're always "valid", so you can't have a find operation return NULL. And for languages that pass them by value (like Java and Ruby), you have to implement silly workarounds (like encapsulating them in another object) to assign to the base value.

[Yui Unifex]

Originally Posted by (angelbob @ foo) There are academic treatises that occasionally intersperse specific phrases in other languages ("Gestalt" being used as a psychiatric term, for instance). They almost universally go to the trouble of defining those terms, or make them entirely optional to understanding the text rather than using them fully (as with books containing random quotes in Latin at the start of chapters). That seems odd given your contention that more features always makes a language better, and given the obviously greater expressivity of those combined languages. Where are all the books written in French-plus-German?

Books are obviously not the only measure of language. Go to Beijing and watch Channel V sometime, you'll hear tons of music with both Chinese and English lyrics. Same thing over here with Spanish and English, although I don't keep up with that much =). Music is particularly influenced because certain words flow in one language with certain beats better than it does in other languages. It's also quite popular in Japan to plaster English words everywhere, just as it's pretty popular over here to put Japanese symbols on cars. My wife speaks both Mandarin and English, and she converses with the American Chinese community while switching between the two constantly (English for more technical things, Mandarin for the rest). There are plenty more examples of language exchange, but I think I've proven my point -- that the various combinations have a purpose that simply can't be captured using only a pure form.

[Yui Unifex]

Originally Posted by (angelbob @ foo) Do you remember, way back when, what this thread was about? Somebody asked for a language recommendation.

Yup, and if you'll look back at my post over there, I also recommended C =).

Our principles are fundamentally different. I believe in free choice of language features, even if it's possible that someone may not choose wisely. I say this because ultimately your language is more powerful. I approach this from the standpoint of an individual: I don't want anybody restricting what I can do with a language, and if I want write a large project in it, the responsibility for enforcement of my practices falls on my own shoulders.

You believe that we should specifically tailor languages so that the general quality of code that the lowest-common-denominator (I think?) writes will be as high as possible. This means either restricting common pitfalls or making it impossible to be caught in them. I agree that C++ does a rather poor job as the latter, but I think this is mainly because it was designed to be backwards-compatible with C,

As you can see, excepting where certain pitfalls be made harder to fall into, these principles do not overlap. In fact, they are mutually exclusive if there are any features that the second school wishes to restrict.

[angelbob]

Originally Posted by It is plainly obvious why this is not a bug

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.

Originally Posted by Few non-functional, non-dynamic languages have achieved the flexibility and genericity that C++ has.

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.

Originally Posted by Yui: "nobody works in both ceramic and glass" is not the same thing as "working in ceramics restricts your working with glass". Take a course or two in logic and call me in the morning. angelbob: You're assuming that anything that isn't directly ruled out isn't affected. Yui: That is incorrect. I said that they were not the same as each other. I don't know where you came up with this.

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.

Originally Posted by angelbob: And yet if they were writing for a mass audience, or even more than one person, they'd still be better off choosing one or the other and sticking to it. Yui: Just as all people do not always write for a mass audience, all programmers do not always write for a mass audience.

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" :-)

Originally Posted by Yui: So we should all use VB. C sucks because it's got language features that are hard to understand (pointers! strings as arrays!. Glad that's settled now. angelbob: Shall I throw your comment about a class in logic back at you now, or wait until later? To make this explicit: you've taken my position, extended it to its most ridiculous extreme, and thrown it back at me as though I'd said it. Yui: This is a common tactic amongst logicians, to see how a particular argument stands up to scrutiny.

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.

Originally Posted by Furthermore, unfettered access to a class' memory is very useful for those languages which lack functional properties like closures.

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

Originally Posted by References come with their own problems. They aren't re-assignable, so you are forced to encapsulate changes to them which causes problems with iteration constructs. They're always "valid", so you can't have a find operation return NULL.

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.

Originally Posted by Books are obviously not the only measure of language.

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.

Originally Posted by Yup, and if you'll look back at my post over there, I also recommended C =)

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

Originally Posted by You believe that we should specifically tailor languages so that the general quality of code that the lowest-common-denominator (I think?) writes will be as high as possible.

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 :-)

Originally Posted by This means either restricting common pitfalls or making it impossible to be caught in them. I agree that C++ does a rather poor job as the latter, but I think this is mainly because it was designed to be backwards-compatible with C

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.

[Yui Unifex]

Originally Posted by (angelbob @ foo) 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.

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.

Originally Posted by (angelbob @ foo) Yui: "nobody works in both ceramic and glass" is not the same thing as "working in ceramics restricts your working with glass". Take a course or two in logic and call me in the morning. angelbob: You're assuming that anything that isn't directly ruled out isn't affected. Yui: That is incorrect. I said that they were not the same as each other. I don't know where you came up with this.

Originally Posted by (angelbob @ foo) 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.

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.

Originally Posted by (angelbob @ bar) angelbob: And yet if they were writing for a mass audience, or even more than one person, they'd still be better off choosing one or the other and sticking to it. Yui: Just as all people do not always write for a mass audience, all programmers do not always write for a mass audience.

Originally Posted by (angelbob @ bar) 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.

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.

Originally Posted by (angelbob @ baz) 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.

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.

Originally Posted by (angelbob @ foo) [snip references]

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.

Originally Posted by (Yui Unifex @ bar) Yup, and if you'll look back at my post over there, I also recommended C =)

Originally Posted by (angelbob @ bar) This is the other reason I've lost interest. I'd thought you were suggesting it for him, not for you.

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

Originally Posted by (angelbob @ baz) I just don't care about that as an excuse since I already have a perfectly good language that is 100% compatible with C :-)

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++).

[angelbob]

Originally Posted by (... that typecasting/multiple-inheritance thing...) 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.

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).

Originally Posted by 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.

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.

Originally Posted by Hahahaha. 50% of what I do professionaly is interface with other people's code. (...) 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.

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

Originally Posted by angelbob: 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 (...), thus enabling somebody to reasonably debug a random sample of code using all language features. Yui: 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.

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.

Originally Posted by 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.

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?

Originally Posted by With any of the competent programmers I've met, syntax means nothing once the basic idioms are mastered,

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.

Originally Posted by Many people write books using only a subset of a language. It's not impossible to restrict one's vocabulary

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

Originally Posted by Thus, it is indeed logic, I simply disagree with the premises that excludes VB.

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 :-)

Originally Posted by 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.

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.

Originally Posted by angelbob: I just don't care about that as an excuse since I already have a perfectly good language that is 100% compatible with C :-) Yui: 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++).

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.

[Yui Unifex]

Originally Posted by (Yui Unifex @ foo) 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.

Originally Posted by (angelbob @ foo) 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?

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.

Originally Posted by (angelbob @ bar) Well, yes, but there are degrees of "screwed up". There are, in fact, languages that make pretty good guarantees of modularity.

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.

Originally Posted by (YUi Unifex @ baz) 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.

Originally Posted by (angelbob @ baz) 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?

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 =).

Originally Posted by (angelbob @ foo) Again, take my typecasting and multiple inheritance problem above. What would you do a search for to figure out what's wrong with that?

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.

Originally Posted by (Yui Unifex @ baz) Many people write books using only a subset of a language. It's not impossible to restrict one's vocabulary.

Originally Posted by (angelbob @ baz) But it's unusual to get that luxury during debugging, unless you write everything you work on.

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.

Originally Posted by (angelbob @ foo) 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.

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.

Originally Posted by (angelbob @ bar) [on references, again]

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.

[angelbob]

Originally Posted by angelbob: Again, take my typecasting and multiple inheritance problem above. What would you do a search for to figure out what's wrong with that? Yui: That wasn't actually a problem though; there was nothing wrong with it. (...) I don't usually google issues that can be resolved so easily.

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.

Originally Posted by angelbob: Presumably the logic you used (...) Yui: That is indeed how the logic goes(...). You fight my attempts, claiming that they aren't logical when you simply do not understand what I'm trying to do.

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.

Originally Posted by 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.

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.

[Kastagaar]

Originally Posted by (angelbob) 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?

Originally Posted by (yui) 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 =).

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.

[Yui Unifex]

Originally Posted by (angelbob @ foo) [on logic]

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.

Originally Posted by (angelbob @ bar) 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.

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.

Originally Posted by (angelbob @ baz) 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.

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.

Originally Posted by (angelbob @ foo) 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.

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 Ruby =).

Originally Posted by (angelbob @ bar) Thus, VB is to C as C is to C++ -- one is more powerful, and uglier.

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.

Originally Posted by (Kastaagar @ foo) 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.

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.

[angelbob]

Originally Posted by Kas: 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.

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.

Originally Posted by 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.

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]

Originally Posted by 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.

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.

Originally Posted by 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.

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++ :-)

Originally Posted by 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?

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 :-)

Originally Posted by 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;

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).

Originally Posted by 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.

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.

[Yui Unifex]

Originally Posted by (angelbob @ foo) 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 :-)

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]

Originally Posted by (Yui Unifex @ foo) 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.

Originally Posted by (angelbob @ foo) 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.

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):

Originally Posted by (Yui Unifex @ foo) 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 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.

Originally Posted by (angelbob @ bar) 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).

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

Originally Posted by (angelbob @ baz) 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 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.

[angelbob]

Originally Posted by angelbob: 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. Yui: 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'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?

Originally Posted by 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.

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.

Originally Posted by 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.

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

Originally Posted by You mean syntactic ugliness like: Code Sample (replacing "char *" with "string")

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?)

Originally Posted by And all that reduced range of debugging tools, like the exact same debugger and tools they were using before? Yeah. You got me there.

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.

Originally Posted by (...)forced object-oriented design(...) 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.

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.

[Yui Unifex]

Originally Posted by (angelbob @ foo) 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.

Allow me to clarify your confusion with a quote:

Originally Posted by (Yui Unifex @ foo) I agree, and I think this is a good system for rating programming languages in general. Note the underlined portion of this quote [whether in concert they tended to produce good or bad code]: Some languages by necessity must consider more than this (unfortunately) idealistic view.

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.

Originally Posted by (angelbob @ bar) 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.

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.

Originally Posted by (Yui Unifex @ baz) 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.

Originally Posted by (angelbob @ baz) I'm aware of that. And you misspelled "supplant" ;-)

I meant what I said.

Originally Posted by (angelbob @ foo) 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.

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.

Originally Posted by (angelbob @ bar) 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.

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.

Originally Posted by (angelbob @ baz) 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.

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++.

[angelbob]

Originally Posted by 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.

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?

Originally Posted by 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++.

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.

Originally Posted by If the exact same debugger and tools is gdb, gprof, and valgrind,

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

Originally Posted by Most memory debugging tools I've used simply preload and hook into malloc/free, so they don't care what language is being used.

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...

Originally Posted by 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?

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).

Originally Posted by 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),

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.

Originally Posted by or to sync the codebase with with a planned migration to a different paradigm in which individual modules are added onto or replaced.

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?

Originally Posted by angelbob: You can add features after the fact with an extra preprocessor Yui: 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++.

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.

[Yui Unifex]

Originally Posted by (angelbob @ foo) 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?

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:

Originally Posted by (angelbob @ foo) You're welcome to judge it on its history as a language instead, but I'll laugh at you.

Originally Posted by (angelbob @ bar) 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 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++.

Originally Posted by (angelbob @ baz) Yes, I was referring to gprof, as well as tools like ElectricFence.

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.

Originally Posted by (Yui Unifex @ foo) 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?

Originally Posted by (angelbob @ foo) So basically, you're not in favor of language designers doing *anything* besides tacking on features until the whole edifice collapses?

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.

Originally Posted by (angelbob @ bar) 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'm not sure if I'm a fan of it... I've never used it =).

Originally Posted by (angelbob @ baz) 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?

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.

Originally Posted by (angelbob @ foo) 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.

The signals and slots are dynamic, and type-safe.

[angelbob]

<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.

[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

[Yui Unifex]

Originally Posted by (visko @ foo) However: Yui, go work for M$. Their PR department would worship you.

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 =).

10 PRINT "I code my MUD in BASIC!"
20 GOTO 10

[Kastagaar]

Originally Posted by (Yui-san @ Barbados) I think that MS' style of C++ is one of the best, most prominent examples of how you can go wrong with the language =).

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)