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

Reply
 
Thread Tools
Old 03-26-2003, 02:59 PM   #21
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
Your argument (Yui) that every feature is a good feature because it improves the expressivity of the language is interesting. Are you a massive fan of Perl for large projects for that reason?

My problem with C++ in practice has been that the average quality of code I've seen is terrible, even compared to similar projects in C. And the code I'm talking about is actually at professional software companies I've worked at. By "terrible" I mean "prone to crash/deadlock and hard to debug". The problems have been that different people use different subsets of the language, nobody knows the whole language, and you have to debug the code of people that use a different subset of the language than you do.

In a programming project that you control, you get to be the autocrat and spend a lot of time tearing misused or "wrong" (i.e. forbidden) features out of code other people submitted. As in a professional software environment, nobody reads the coding standards and nobody follows them, so you still have to go in and fix the results afterward.

Fair enough.

Goto is a fine example of the same principle. There are specific examples where it's basically acceptable. Palm (the company) used it for about the same purpose you list above, though with a couple more restrictions. Nonetheless, the vast majority of C code I've seen using "goto" is quite bad. Overall, its existence has done far more harm than good for the maintainability of the code I've seen in my professional career. In my private code I don't work on C++ projects with other people so it's a non-issue.

I'd like to again draw attention to the phrase I used above, the one that goes "nobody knows the whole language". C is a pretty snappy little language, and a clever fellow can figure out the whole thing and know the vast majority of the subtleties (what does "++bob++" do if "bob" is an integer? Is it legal? Which has higher precedence?) within a couple of years of regular use.

I've interviewed with a guy who was on the C++ ANSI standards committee. I've worked professionally in C++ for several years, and I've worked with many people who use it very regularly. I've built C++ parsing code, code to produce it from a template, debugged massive systems and worked under about four different template libraries in it at three different major companies. What I have never done, though, is to meet somebody with a very firm grasp of all the current standard language subtleties and how they work together.

By contrast, I've probably met about six people who could say that for C and who actually keep up with all the latest ANSI standards. Perl, like, C++, seems to have no full-on experts. It's simply too big, too varied and too weird.

Like you say, we could just rule out big chunks of the language and be an expert on the rest. If you believe that will work, you've worked on very different projects with very different people than I have. At least at the companies I've worked at and on the OSS projects I've worked on, you can't get people to follow the project's coding standards without constant and painful enforcement.

Though I suppose, if you had any significant number of contributors, you could just reduce your whole role to "constant and painful enforcement". That's what I've been doing primarily on my project lately -- and I'm using a simpler, cleaner language than C++.
angelbob is offline   Reply With Quote
Old 03-26-2003, 05:13 PM   #22
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

I don't believe that every feature is good because some features are 'forced', or are mutually exclusive with other features. Case insensitivity is an example I gave of one such feature that has advantages at some times, and disadvantages at others. If there's a large project, knowing how to take advantage of Perl's features gives me an edge over someone who does not know how to take advantage of those features. So if the large project is something like a system administration front-end that is heavy on the regular expression parsing (see the Cobalt RaQ's backend system), Perl would indeed be a good choice. If the large project is very performance intensive, then Perl would probably not be. It's all about choosing the right tool for the job; I will never blindly advocate that one language is the best for all purposes.

This is a fair judgement. My experiences have been mixed: I've had to debug C programs written to control PLC-enabled conveyor systems while talking to an Informix database. Problem ended up being a bug in the linked list structure that the previous programmer (now long gone) had rolled. In my business (basically an employed software consultant), I get to talk to a *lot* of software development houses, and I almost always end up wondering how in the world these people stay afloat with their limited knowledge. I would not be so quick to trust their code with any language.

If you're having problems with people not reading and following coding standards in a professional environment, something's not right. This is one of the easier things for the coders to grasp; all they need to do is consult a list.

Just to make sure that you're not arguing for this: Language designers, to an extent, should not be responsible for these problems. They arise mostly from user-error; to remove it would be like removing 'dd' from unix systems because it's possible to destroy the hard drive with it. There are certain things they could do to reduce the desirability of goto, such as using named breaks to take care of the issues that shadowfyr raised, and these are things that language designers rightly should be concerned with.

As languages get higher and higher level, and people are able to express more and more constructs in them, it will indeed be difficult for programmers to learn the subtleties of an entire language. But I don't see this as a bad thing; if one absolutely requires that there be no subtleties at all, one should then use a language with no subtleties. But if one wants to make use of higher-level features such as closures and polymorphism, one will have to accept this complexity. Complexity at the language level here leads to simplicity at the algorithmic level. The right tool for the job is what should be chosen. We don't communicate with grunts and gestures, even though they would be totally unambiguous, with absolutely no side-effects, than the higher-level languages that we all speak.

Yes, I do believe that will work. This is what humanity has been spiraling towards ever since the concept of 'specialization' has been discovered. To understand the complexities of nature one has used abstraction and specialization. I see nothing wrong with it, and if today's generation of programmers can't handle it (but they can ;)), then the next generation will replace them. Designing to the least-common-denominator is a sure-fire way to encourage mediocrity rather than excellence.

However you may define 'cleaner', it has already been shown (and gone uncontested) that C++ is cleaner than C in some cases. It would be more correct to say, "I'm using a simpler language that is cleaner than C++ in some cases". Remember that absolutes are absolutely horrid things; their scope is so grand that they are nearly impossible to prove, but they are ridiculously simple to disprove.
Yui Unifex is offline   Reply With Quote
Old 03-26-2003, 08:29 PM   #23
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
Yui:
Sure, but what about features that are just hard to read, even when they're easy to write? I mention Perl specifically because it gets such a reputation as a write-only language. It gets this reputation because of things like its regular expression syntax (very difficult to read, and very small subtleties can change the meaning a *lot*) and the fact that a tremendously wide variety of inputs can parse to *something*.

One reason I'll call a language "clean" is if no two valid inputs in the language look very similar to each other. That is to say, if any two valid inputs in the language are reasonably easy to disambiguate from each other, especially two inputs which are basically dissimilar.
And by "disambiguate", I mean only if you're reading it. A parser, of course, won't have much trouble either way.

If you're *writing*, as opposed to reading or modifying, I agree with this statement.

Actually, Perl's remarkably fast. It's not quite up with static compiled languages like C or Pascal, and certainly not Fortran. On the other hand, it compares very favorably to anything interpreted and most things that are compiled.
That's mainly because they have a really good optimizer, though, and the fact that the whole language is designed with that in mind.
Anyway. Sorry. Off-topic.

Because good people are extremely rare. Software houses that employ a very small number of very good people will essentially never go out of business. They will also very, very rarely get really big. Most markets require a lot of customer service, and a lot of very large software to be built. Therefore, any approach that requires a very high average level of brilliance, or that allows brilliant people to be easily sabotaged by idiots they're working with, won't grow to fill the niche. It will instead be overtaken by a small army of strongly competent fellows who are, collectively, more brilliant than the five incredibly savvy guys at the other company.

That's just one of the many reasons that languages that allow good modularity are so popular.

And you're successfully making coders do that, even though no two can agree on a good coding standard, how? The only correct answer is "enforcement". The only common answer is "optimism". Where have you worked, that you haven't had problems with this? My experience with free projects is that carefully-written, carefully-posted and carefully-followed coding standards are all well and good, but free contributors simply will not follow them unless you enforce rigidly.

The same is essentially true at a professional software house, and nobody wants their job to be enforcing coding standards. Well, okay, John did, but we laid him off and he left for Norway. It's a shame, he was good at it.


Very much like that, yes. Ever notice how on modern Linux systems, root logins come configured by default to alias "rm" to "rm -i"? So instead of deleting files automatically, it'll ask to make sure you typed what you meant.

One could imagine a similar scenario where "dd" was aliased to always prompt when you used it on a hardware device (rather than just a file), so it would make you specifically say "yes" before doing something potentially stupid. The DOS "Format" command already does/did that.

I consider all of those to be basically good things. Should language designers avoid easily-abusable features in favor of features that tend to produce better code on average? Absolutely. Unquestionably. Should they remove features (like pointers) that can sabotage other people's work silently and without them specifically opting into it? Where possible, yes. Pointers specifically are a great example of a feature which can't be removed without a speed hit. I still try to use languages without them, where possible and appropriate.

Would any given lanuage be better if we added a bunch of new features? Maybe. CommonLISP plus pointers, for instance, or Java plus pointers, would be a step back. SML plus pointers would be an abomination -- like C++, it would have sabotaged its greatest asset, though for different reasons.

"Sabotaged its greatest asset?" Yeah. Being object-oriented is C++'s greatest asset. That means a real type system. The basis of data protection in a type system (private, protected, static, etc) is enforcement. Private fields aren't private as long as C++ has pointers.

Anyway. Sorry. That's a different anti-C++ tirade, and it's not like C has a real type system either -- it just doesn't pretend to.

Yui:
Thank you. This is a very concise restatement of what I said earlier about "hard to debug" and "other people's code".
Incidentally, there *are* new languages that focus on having fewer features rather than more, and some of them are very much improved by it. SCHEME is easily embeddable because of it. SML/NJ is possible because of it -- full static type analysis is essentially impossible on most imperative programming languages, and you wouldn't want it anyway. Java is cleaner because of it, having removed some nastiness that C++ added.

Sort of. You're saying here "to use closure and polymorphism, you must use a language with enough subtleties that nobody will properly understand the language". My counterexamples are Scheme, CommonLISP, Dylan and SML (for closures) and CommonLISP, Dylan, SML, LPC, SmallTalk (for polymorphism). Note that there are a decent number of languages even in the intersection of the two.

Beyond a certain number of simultaneous features, you're right, you have to have a language that's too complicated to understand. Speaking of which, if C++ has closures then we mean two very different things by "closures" or C++ has added a feature I'm not familiar with. I'm used to closures requiring lambda functions or something like them.

Actually, grunts have no established meaning and are entirely ambiguous. And complexity at the language level adds to simplicity at the algorithmic level only if you can match a language primitive with the task at hand. Near-misses on language primitives are usually as bad as not having anything at all (such as using code inheritance for physical MUD objects, as we discussed earlier, or using C++ inheritance for a system with dynamic inheritance).

For common structures (such as lists and hash tables), though, I agree -- complexity at the language level leads to simplicity at the algorithmic level. Though the stuff we were discussing earlier was all simplicity at the syntactic level, which I consider to be a separate issue.

More specifically, complexity at the standard library level tends to lead to simplicity at the algorithmic level. Complexity at the language level tends to lead to simplicity at the syntactic level.

So you feel that the potter's wheel was designed to allow more variation than shaping clay with your hands? Nope. *Less*. There are *fewer* shapes that can be manufactured with a potter's wheel, and those shapes can be created with less effort for each one. By *restricting* the expressiveness of the medium, the total labor can be reduced.
Specialization *restricts* the vocabulary of an individual, and even of a socity -- you see practically nobody that works in clay/glass hybrid objects because those are considered separate specializations so there's little overlap. That wasn't always true.

But by restricting the expressiveness of the media involved, we get everything with less labor. Old fabrics, done by hand on a loom made of strings and a rock were more complex than the most impressive stuff we can do on our big modern computer-controlled looms -- and yet our modern stuff produces it at a tiny fraction of the cost, so we're wearing simpler fabrics and not worrying about it.

By *restricting* expressiveness, we've reduced total labor.

And in the same way, the fact that I use C means I'll never have to debug a code submission that requires me to understand all the stuff that can go wrong with C++ code templates. I've saved myself a couple of months of my life that way, and I'm happy about it.

Yup. Garbage collection is argued against for the same reason -- it doesn't require you to track everything, and so it'll be overrun by higher-performance languages where you have to track all the allocations by your lonesome. The results are better, even if they're more error-prone and require more intelligent programmers.

And Perl, Python and Java overtake C and C++ while we stand in denial, because there are fifty times more people who can be perfectly adequate programmers than can be brilliant programmers, and fifty adequate guys is worth at least two brilliant guys. More on some problems. Only two? Sure. But that's still twice what the brilliant guy can do.

Of course, you could also make sure that the language the only-adequate people use is sufficiently "expressive", and then none of them can debug it. Lamentably, that's why something as awful as Visual Basic is also overtaking C and C++.

Well, except absolutes like "A and B implies A", or "not not not A implies not A", and absolutes like "this car is painted red". Which would prove your point nicely if it didn't also disprove your point.

But yes, C++ is cleaner for some specific things. The things you proved it was cleaner for were specific C++ language features (C sucks for operator overloading, I'll grant you), and ones that I feel still shouldn't be used. But in the same way that APL or Fortran absolutely rocks if you need to take the inverse transpose of the product of a 9x7 with a 7x15 matrix, C++ rocks for operator overloading.

Incidentally, APL is another long-forgotten example of a write-only language in a very specific domain. It does array processing (thus the name). It has operators for, like, everything you can do to an array. But since nobody remembers what the operators do when they read them, it doesn't matter -- the code's simply not maintainable. Rather like the way some parts of the Perl regexp system work, or some of the finer points of C++ RTTI and typecasting stuff.
angelbob is offline   Reply With Quote
Old 03-26-2003, 08:33 PM   #24
karlan
Member
 
Join Date: Apr 2002
Location: Brisbane Australia
Posts: 74
karlan is on a distinguished road
Unhappy

A lot of the arguments being used seem to me to be more about how people use it. If a company has standards that people should be using they should use it. Ihave worked for a couple of companies with different coding standards, and when people have followed the standard it is often simple to maintain/modify other peoples code, the exceptions to this were the "prima donna" programmers who felt they were indispensible and so didn't have to follow the standards, and they produced hard to understand, and difficult to follow code. This is not a problem with the language but with the programmer.

If nothing else a little bit of concise commenting can simplify maintenace a whole lot.

just my 2c
karlan is offline   Reply With Quote
Old 03-27-2003, 05:01 PM   #25
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
Karlan:
Well, yes. Assembly language can be used quite well, commented well, macros added, et cetera. Nonetheless, if somebody was to ask me "should people use C or assembly?" I would immediately answer "C, if possible".

Even though assembly is capable of things that C is not. Even though using C instead of assembly is compensating for programmers being less brilliant rather than making them work for their good code. Even though the maximum quality of the code is less than for assembly. Even though the arguments for using C are all about how people use assembly, not whether it can be done well.

Despite all of those things, I'd still recommend C over assembly. Ditto for C++. And the Future Crew, who did wonderful demos in assembly language, can laugh at me all they like.
angelbob is offline   Reply With Quote
Old 03-27-2003, 08:16 PM   #26
karlan
Member
 
Join Date: Apr 2002
Location: Brisbane Australia
Posts: 74
karlan is on a distinguished road
Are you saying you feel C++ is a step forwards or backwards from C?
karlan is offline   Reply With Quote
Old 03-27-2003, 08:30 PM   #27
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Yes, even those features.

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. I was able to extend the Cobalt RaQ's Perl administration application with little difficulty, and I've barely written 200 lines of Perl. Either I'm a genius or the program was easy to modify, and I don't think it's the former.

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. I should not have to mentally switch between X number of styles when I go to maintain the code in the project. If your coleagues have problems with this, I do suggest "enforcement". But honestly, most people I've worked with don't need to be told about something so basic. It's only the interns and prima donnas (as karlan mentioned) that seem to have problems with it.

First of all, C++ is a multi-paradigm language, and this is its greatest asset, IMO. Its type system is "real"; it's called "strong typing". If you have to cast something, you'll very often get undefined behavior. And no, pointers do not have anything to do with the privacy of a field, because only the class can decide whether to allow a pointer to a private field to exist. This is the exact same with Java and references. This sabotage is completely non-existant.

*grunt* now means "pizza". Now grunts have established meaning and we can continue with our regularly scheduled programming. Honestly, no language has an established meaning other than what the users of that language assign to it. To get back to the point, if one were to have complete simplicity with absolutely no abstraction nor any "subtleties", that is the linguistic equivalent of assembly. But to everyone's chagrin, we now use languages that can express higher levels of abstraction: C has more than asm, C++ has more than C, Python more than C++, Common LISP more than Python.

No. A language primitive need only match a neighboring part of the construction of the task to increase simplicity at the algorithmic level.

By using a wheel a potter is not restricting what he can create! Using a wheel does not preclude the potter from shaping with his hands once the general shape has been achieved. It is just a tool; the equivalent of a subset of a language, not the language itself.

Not even close. Name one speciality that *restricts* your vocabulary rather than merely drilling down into the complexity of a subject.

The most ironic thing is that these are all arguments for why C++ should be encouraged:
The modern textile factory is vastly more complex than the looms of old. It has higher-level constructs (machines, assembly-line) as a whole, even if the role of the individual is lessened in the Big Picture. So I agree with your argument here. C++ in some cases will allow you to produce stuff at a tiny fraction of the cost, because there are more higher-level constructs that one can make use of.

You've completely missed the point. If garbage collection were an *optional* feature, it could be used in cases where it was beneficial and avoided where it was not. Designing to the least-common-denominator is only an argument against garbage collection when that feature is forced upon the users. You should understand by now that I am arguing the exact opposite of this.

*cheers*

To enumerate the covered advantages of C++ (vs. C) in our debate:
1) When you want generic code such that a user of your library can call functions with both user-defined and built-in types.
2) When you want to change the return value of a function used in I/O without having to go back and change all users of that return value.
3) When you want an error-handling system that is not coupled to the return type of functions.
4) When you want natural math operations with user-defined types.
5) When you don't want to write Yet Another Linked List, or Yet Another String Handling System.
6) When you want to use strings with pass-by-value semantics.

And for C:
1) When you don't want to deal with other people doing something you don't understand or don't like.

(Edit: Added 'or don't like' to C's advantage.)
Yui Unifex is offline   Reply With Quote
Old 03-28-2003, 12:12 AM   #28
Lindahl
New Member
 
Join Date: Feb 2003
Location: California, US
Posts: 5
Lindahl is on a distinguished road
Lindahl is offline   Reply With Quote
Old 03-28-2003, 03:05 PM   #29
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
Karlan:
I'm arguing it's backwards. Yui is arguing that it's forwards. That's our basic disagreement.

His argument is: C plus more features must be better than C. My argument: C plus features that are frequently misused is generally worse than C.

Beyond that, we're just hashing through whether C++'s features are generally a good or bad thing. His argument: the potential upside is greater since you don't have to use bad stuff, or use stuff badly. My argument: this stuff is generally used badly.

There's a lot more detail, but you can read through at your leisure, this stuff's probably on the 'net forever.
angelbob is offline   Reply With Quote
Old 03-28-2003, 04:18 PM   #30
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
angelbob is offline   Reply With Quote
Old 03-28-2003, 06:38 PM   #31
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

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.

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.

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.

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.

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

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.

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.

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

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.

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 is offline   Reply With Quote
Old 03-28-2003, 11:02 PM   #32
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

Almost forgot this gem:
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.
Yui Unifex is offline   Reply With Quote
Old 03-30-2003, 07:06 PM   #33
Lindahl
New Member
 
Join Date: Feb 2003
Location: California, US
Posts: 5
Lindahl is on a distinguished road
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.
Lindahl is offline   Reply With Quote
Old 03-31-2003, 04:54 PM   #34
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
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.

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.

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.

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

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

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

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?

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.

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 is offline   Reply With Quote
Old 03-31-2003, 05:02 PM   #35
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
angelbob is offline   Reply With Quote
Old 03-31-2003, 07:17 PM   #36
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
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 is offline   Reply With Quote
Old 03-31-2003, 07:28 PM   #37
angelbob
Member
 
Join Date: Feb 2003
Location: Bay Area, CA, USA
Posts: 39
angelbob is on a distinguished road
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?
angelbob is offline   Reply With Quote
Old 03-31-2003, 07:33 PM   #38
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

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.

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.

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.

That is incorrect. I said that they were not the same as each other. I don't know where you came up with this.
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.

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

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?

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

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.

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.

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 is offline   Reply With Quote
Old 03-31-2003, 07:42 PM   #39
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

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 is offline   Reply With Quote
Old 03-31-2003, 08:03 PM   #40
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

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.
Yui Unifex is offline   Reply With Quote
Reply


Thread Tools


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

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

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

All times are GMT -4. The time now is 08:55 AM.


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