[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