Rolf Howarth commented:
| That's true of course. But templates (and even worse, operator
| overloading - uuggghh!) make it that much easier to write poorly
| designed code, and to write code which is difficult to understand.
I replied:
| No argument there. With power comes responsibility, and C++ gives you
| a lot of power, assuming that the programmer has the discipline and
| knowledge to use it properly.
Sean Luke wrote:
| This misses the point, I think.
I think that's for Rolf Howarth to say.
| There is a good reason why decent
| languages have to be, too some degree, restrictive of your "power".
And just what that degree is, is a matter of preference. If there were anything like universal agreement, this discussion wouldn't be taking place.
| Because although flexibility might be useful for some, it is usually a
| bad bad thing in general.
Others believe that rigidity might be useful for some, but is a bad bad thing in general. Here, too, where the line is drawn is a matter of preference. Perl programmers, for instance, seem to take outright pride in the sheer number of ways you can do any given task. C++ programmers at least acknowledge that there generally are only one or two *good* ways to do something.
| Because as coders we don't live in a void
| --- we have to interoperate with other coders, most of whom have, I am
| sad to say, atrocious coding style. Sure C++ gives you more ways to do
| X. But as a result you have to deal with coders who all decided to do
| X the wrong way.
Well, in *different* ways. Not necessarily *wrong*.
| Now you have to store ALL ways, good and bad, to do
| X, in your head.
Why? I worry about the "wrong" ways only when I actually need to deal with them. The rest of the time, I stay as blissfully ignorant of them as possible. (For that matter, just how many "wrong" ways are we talking about? One? Two? Fifty? Ten thousand? And do you *really* need to stay conversant with each and every one?)
Sorry, but you'll have the same problem in any language. There will *always* be more "wrong" ways than "right" ways to do any but the most trivial of tasks. I'm inclined to think that education--teaching those people how to do it right--is a better solution than forcing everyone to do it the same way. Enforcing a One True Way of doing something may well prevent incompetence. Unfortunately, it prevents brilliance as well. I, for one, don't care to make that sacrifice.
Back when procedural programming was the norm, the very attitude you express would have argued against object-oriented programming, because, after all, it's a different way to do things, and is just one more thing to clutter up your brain with, when procedural style gets the job done. Before that, there was the "structured programming" movement; before that were high-level languages. Each one disrupted the previous standard methods of doing things, and, by your argument, should not have been done. The same can be said of user interfaces: why fill your head with all the wrong ways to do GUIs when command-line--or even menu-driven--interfaces work perfectly well?
Encouraging standardization is a fine and wonderful thing; it has all the benefits you claim for it. Shoving it down people's throats is quite another thing. All innovation, by definition, is non-standard. Eliminate all non-standard behavior, and you eliminate all innovation. Progress inevitably involves making mistakes, discovering that what seemed like a good idea at the time turned out not to be so good.[1] And that experimentation has to be done *somewhere*. If C++ weren't allowing itself to be a "language feature testbed", some other language would get the job. Would you prefer that Java be that language?
Glen Fisher
[1] There are people who believe that Java's own exception specifications are such an idea. Java programmers coming to C++ tend to argue that C++ needs them, while C++ programmers respond that they add needless complexity to code that will function correctly--whether or not an exception is thrown--without having any knowledge of the thrown exceptions.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
