"When the customer demends bug-free software he gets it."
I think it more often the case that a customer who demands _and is willing to pay for_ bug-free software gets it. I've come across lots of people who loudly insist on bug-free software until they see how much extra it's going to cost them.
"Firefox and openoffice are continous works in progress, as opposed to a project with a firm set of goals."
Each release has a firm set of goals though, so that release could be significantly less buggy than is currently the case.
"I doubt Praxis could make the same offer if customers changes the requirements, and feature list all the time."
Neither OO or Firefox have any customers, though: they are free software, and not therefore subject to the financial and competitive pressures that can and do result in buggy commercial projects. Who actually decides what features to add? The development team. Who sets deadlines for implementing these features?The development team. Who decides when they are coded to sufficient quality for public release? The development team. Who therefore is to blame when that code ends up being sub-par? The development team.
"Praxis also has certian requirements about the enviroment in which they work."
All software has specific operating environment requirements.
"If I took a Solaris 9.0 project, and tried to run it on linux 1.0, I don't think Praxis would be liable for the bugs that would occur."
How is this in any way relevant to the fact that both Firefox and OO are buggy? Such bugs manifest themselves on systems that both claim to support, and are not restricted to people who try and put them on (for example) an XBox-360.
Or "We can have three guys fresh out of college with really impressive degrees for the same price as this other person who is older, and therefore less likely to know about modern computing topics. We will therefore hire the three college graduates, who will then do three times as much useful work."
"IMO, this isn't a golden rule or even a good rule. Quite the contrary, I think code (OO or otherwise) should be designed and written for a particular purpose. If that purpose is to be derived from, good and well. If it's not, throwing in something to halfheartedly support derivation anyway is a poor idea."
I agree that it boils down to design, and that code should be designed for a specific purpose. However, OO in particular is primarily intended to support re-use by derivation -- without that, there is no real point in using it at all, especially in C++, which offers so many other mechanisms for expressing solutions to problems. I would thus argue that the very act of using OO to write code that does not support re-use is an indication that the programmer(s) did not design and write their code for a particular purpose, but were instead trying to force certain types of problems into a paradigm that is ill-suited to them.
"Going further and fully supporting derivation makes a bad situation still worse. You're still doing extra work, and probably introducing extra bugs, to make the code do something it's not really supposed to do."
See above. If this is the case, then OO is a non-optimal solution anyway.
"This is one area I agree with the people who advocate testing-oriented development -- you should define what the code really needs to do, and then write the simplest code you can that does it. Any extra capabilities, features, etc., beyond what it's really supposed to do is a bad thing."
I fully agree. But I would suggest that in a multi-paradigm language such as C++, trying to lever solutions into one of them that would be better expressed in another violates the "simplest possible" rule anyway. One of the things that makes C++ worth learning and using despite its complexity is its ability to express solutions to problems in ways that fit them naturally, unlike for example Java which forces all solutions into a single pre-conceived model, irrespective of whether that model is an appropriate one for the problem or not.
"The long and short of it is that teaching C++ well is not necessarily terribly difficult or complex. In fact, I think it's far easier to teach people to write reasonable- to good-quality C++ than even meciocre- to fair-quality C."
Agreed, but I would amplify your point somewhat. C++ can be taught more easily than C and indeed be significantly easier to program in than C if use of the STL is emphasised from the beginning, and "inherited" C features such as fixed-length arrays, "dumb" pointers, etc. are either left out entirely, or in the case of training materials for C programmers, discouraged (naturally with good explanations of why the STL solutions are preferable).
"I honestly don't mean to be sarcastic, but by this rule we should all be using really simple assemblers with no macro capability. At least IME, these are about the only languages sufficiently trivial that most users really do understand them almost completely."
I disagree here. It is perfectly possible to write a general-purpose programming language which is well-suited to both systems programming and applications programming without adding undue complexity. Oberon is a good example of such a language: its entire grammar can be expressed in 20 pages, and it is very easy indeed for any experienced programmer to learn, yet it can be (and indeed has been) used to write everything from operating systems through MVC frameworks to applications. I am not for a moment suggesting that it is better than C++, or that it is an equivalent: it merely serves as an example of something that fulfils many of the C++' stated design goals without being either complex or difficult to learn.
"The problem is that the rules being easy to learn doesn't generally seem to translate to good code, because bugs rarely arise from poor undstanding of arcane rules. Rather, they arise from the tedium of constantly ensuring that even the most trivial rule is followed."
" I can tell you that on review of code to add some new functionality or to tweak some bit of code, bugs and flaws are discovered that (almost) never would have been discovered by users... while not a daily occurence, I suspect that every maintenance coder has found flaws in just this manner..."
I've found flaws in my own code when adding new functionality to it. And few if any of said flaws were found during testing or by end-users.
"I haven't been using any extrodinary definition of the word human, and it should have been fairly obvious from the context."
I know you weren't, but some of the things you were citing (and not necessarily agreeing with) did depend rather heavily on a specific definition of "human" in the context of the citation. For some, it could be simply "that which was created in God's image and imbued with an immortal soul", whereas others require a more complex and / or significantly less mystical definition to make sense.
""Emotional issues" means "issues that tend to stir up people's emotions" but does not mean that a person's stance on the issue depends on their emotional state at the time you ask the question".
I never said otherwise. I distinguish between an emotional response to a situation and a moralistic response solely by the respondent's ability (to paraphrase you) to unambiguously identify the foundation for their assertion that something is "wrong" rather than merely reacting against it "because". Morals (or usually contravention of them) is clearly capable of promoting an emotional response, but not all emotional responses have a corresponding moral foundation.
"For example, in order to support your assertion [actually the OP's] that morals only evolve and are unaffected by religious affiliation, you have attempted to define "moral" as requiring a "general consensus [across all of society], not something that is imposed by one part of society on an equally large but dissident portion"
I fail to see anything in the part of my text that you are quoting which implies or denies any particular source for a society's moral framework. I only state that collective morality must be agreed upon rather than imposed, i.e. that it is a shared belief, not a tyranny which is forced on large numbers of others against their will. This in no way precludes it being derived from a religious foundation if that religion is shared by the majority, neither does it presuppose that religion is the only possible foundation for a collective morality.
"[you are] attempting to use your own artificial re-definition of the word to define out morals influenced by religion on the grounds that members of other religions do not have the same ones."
I have written nothing which implies that religion cannot be the source of a society's shared morality, because many societies have moral codes which are clearly derived from a religious foundation. I do however distinguish between religiously inspired collective morality, and a selective interpretation of that morality which is not universally accepted being forced on everyone. Societies which do that sort of thing are known as theocracies.
You cite some things from the OED (an excellent dictionary):
Firstly, the etymology of a word and information on when it was first published have no relevance to this argument, because meanings of words regularly change over time, hence the fact that good dictionaries such as the OED have several definitions for most of them, including obsolete ones.
Secondly, I fail to see where you think the OED refutes anything I said, as I never claimed that morals and ethics are unrelated (in fact, I said the opposite). I distinguish between them merely in terms of scope: morality establishes a set of agreed behavioural guidelines, and ethics apply these morals to specific situations, some of which may not have existed when the original moral code was established.
NB: It seems that you are rather emotionally bound to this, and are therefore misreading a great deal of what I have said as being some sort of attack on you and your beliefs. I shall therefore terminate this debate by conceding victory to you, as it is only of interest to me from an academic viewpoint.
"While members of the academic community and relevant professionals such as doctors and legislators study these issues as ethics, members of the general populace tend to have fairly unambiguous moral stances on them. People do not tend to study ethics before they express the moral principle that the berieved relative must assent before a loved one's organs are harvested."
Firstly, the study of ethics is entirely separate from whether something is an ethical or moral issue. Secondly, I would argue that the stance most of the general populace takes on any of these issues is neither unambiguous or based on any particular moral position, but is instead usually an emotional response to a particular situation which the responder cannot describe in anything like unambiguous terms, or is based on religious dogma which may actually run contrary to the common moral base of a society.
"Neither do they tend to weigh up purjury even though they may feel that lying in other areas of life is 'ok'."
Perjury is a legal construct, not a moral or ethical one. It is thus quite possible to commit perjury while behaving in a manner that is both moral and ethical, while refusing to do so would be legal, but in some cases neither moral or ethical. Good laws may embody or reflect a society's morality, but they do not define it.
"And while for doctors and legislators the abortion debate is an ethical issue, for the pro-life US Conservatives and the pro-choice feminists it is simply a moral issue."
It is an emotional issue for both sides. Morals are sets of behaviours that are accepted by general consensus, not something that is imposed by one part of society on an equally large but dissident portion -- that is the job of laws, which I have already stated should (but often don't) reflect and even embody a society's morals but do not define them. And both sides of the debate obviously share a common morality which states that killing another human is wrong except under certain extenuating circumstances: what they disagree on is whether an unborn foetus is a human being or a part of its mother, and in many cases the point at which it ceases to be one and becomes the other. And their arguments about this definition all essentially boil down to either raw emotions, religious dogma, or a mixture of both.
"While it's clearly true that using templates with many types can increase the size of your code, I think the problem is overstated."
For most types of applications, I agree. Remember though that the point of mine that you are quoting specifically addresses embedded systems, which are often far more resource-constrained than general-purpose computing devices.
"Sure, if you were using generics where everything was done via RTTI and only a single instance of the code was needed, the output code would be somewhat smaller. However, we should remember that the RTTI itself imposes overheads, and there's far less scope for deep optimisations without the exact type knowledge you have with templates, so the ratio certainly won't be N:1 where N is the number of types over which our template was instantiated."
In the embedded systems I was addressing in the original point, the overhead of RTTI may also be unacceptable. Remember that such code very frequently targets specialist CPUs whose memory is on the chip die itself, so adding more memory is not an option. In these types of highly constrained environments, every byte that is required to support a language feature means one less byte for application logic, so they are commonly programmed in specialist manufacturer-supplied C dialects that directly support certain pieces of the chip's functionality without requiring any libraries (standard ones or otherwise). I am not saying that this is the case for all embedded systems, as there are some that include a full computer with disk drives and an OS such as Linux, but the bulk of embedded system work still targets specialist CPUs that operate in a much more restricted environment.
I am aware of Descartes, as well as the works of subsequent philosophers who quite successfully refute much of what he wrote. However, for the sake of argument, Descartes can indeed be cited as _a_ proof (which is what I asked for), and I shall therefore concede this particular line of argument to you.
"I guess it's how damned sincere you sounded, like you really -meant- what you were saying."
I was sincerely interested in what the definition of "human" was in that particular context. I was not asking for your definition of human or Wikipedia's, but rather the definition that those who base an entire philosophical, religious, or legal framework on humans being somehow special use. I think you will agree that without such a concrete definition, any contrary arguments become extremely difficult to make, because those in the counter-position can simply move the goal-posts whenever they wish to.
"What's done, however, is not a bitwise copy, but a memberwise copy. "
You are of course correct. My bad.
"The cure is to not use raw pointers on a regular basis. I can hardly remember the last time I had to write a copy ctor because I used a raw pointer."
Indeed. However, the fact that C++ is often advertised as a "better C" means that it attracts C programmers in large numbers, and C programmers use pointers as member variables a lot (I know this, because I've had to maintain their code). I think therefore that _all_ C++ books and courses should expound a rule in big, bold letters in a box that says "C++ has a variety of mechanisms that make the use of pointers for dynamically allocated member variables unnecessary. If however you are going to use pointers as member variables, you should provide your class with a copy constructor that initialises them properly when they are assigned to another variable of the same type."
"A class that doesn't have a virtual dtor generally means that class wasn't designed as a base class."
There is a golden rule in OO which says "Do not make any assumptions about the way people will use your classes". If a class isn't designed to be a base class, then there should be a header comment or some other piece of documentation that says so, otherwise people will assume they can inherit from it, and do so. I know this is true, because I have maintained large commercial code bases where this has happened, and has resulted in memory leaks. It's one of the reasons that Java takes the opposite approach of assuming that all classes are base classes unless prefixed with the "final" keyword, which indicates that they can only be instantiated, not inherited from (note that I am not saying this is a desirable solution, only that it is an attempt at a solution in a language that was heavily influenced by C++).
"There is (occassionally) a problem with a class that was intended to be used as a base class, but due to oversight the dtor wasn't made virtual. In this regard, C++ could be improved -- rather than requiring an explicit virtual dtor, it should make the dtor virtual if the class contains any virtual function."
I can assure you that it is more than occasional, but this is not a point that's worth arguing about, as it would eventually boil down to anecdotal evidence that we obviously do not share. However, I don't really think the language needs changing in that way, because it is specifically designed to do what you tell it instead of making assumptions about what you may or may not be doing, and I would argue that this is a major reason for it being so successful, as well as being a major reason for some code bases having many errors in them. Perhaps a good compromise would be for the compiler to issue a warning whenever somebody derives a class from one with a non-virtual destructor, or better still, warn when such a class is used polymorphically (which is after all the only time that this particular problem arises). After all, what may be an error in one person's code could be a deliberate design decision made for a very good reason in someone else's. It is for this reason that I prefer warnings to errors that prevent compilation, and prefer errors to languages that change my code into something else without being told to (a compiler switch or pragma would of course equate to being told to do it).
"IOW, much of the problem really arises from teachers trying to push OO as the answer to everything, and overusing derivation when it's not suitable or useful."
Agreed. However, this is largely due to the fact that C++ owes much of its popularity to the 1990s wave of pushing OO as a silver bullet that would magically solve all of the programming world's problems. A lot of people came to C++ from other languages (usually not OO ones, because experienced OO programmers knew that it wasn't a magic bullet at all) during that wave, and are pretty much locked into that mind-set, and they're often the people who are writing books and teaching it in
1. Wikkipedia is not an authority. It is a bunch of stuff that some people felt like putting in there, and therefore carries no more weight than a slashdot post.
2. This is slashdot. Petty squabbles about semantics, spelling, punctuation, definitions, etc., are part and parcel of it, and always have been.
3. This part of the thread revolves around whether being human is a qualitative or quantitative attribute (i.e. whether we are evolved animals, or something more). Such an argument is meaningless unless a concrete definition of what is meant _in this context_ by "human" can be arrived at.
"There are no definitions (for anything) that would both be devoid of circular reasoning and not rely on other, nondefined things."
Proof? This is a bold assertion that requires rather more to back it up than you merely stating that it is so.
"After all, defining a term means describing it in other terms."
Which you did not do. You defined "human" as "human", thereby describing it entirely in terms of itself. Thus, the initial definition is completely based on circular reasoning, not part of a chain that ultimately resolves to unprovable axioms or undefinable references.
"animal moral behaviours do not "closely resemble" our own except for an extraordinarily broad interpretation of "closely resemble". Animals do not have organ-transplants to have morals about whether the family of the donor should have to assent, they do not have courts to have moral beliefs about whether they should present false evidence in them, they do not have abortions to debate how close to term the foetus has to be before it has the same rights as its mother, etc etc."
The above are all examples of ethics, not morals. A moral is "it is wrong to kill another person"; whether an unborn foetus counts as a person (and indeed at what stage of development such "person-ness" appears) is an ethical matter. Morals cover broad issues, ethics are an attempt to reconcile morals with situations where the moral in and of itself cannot be unambiguously applied. We thus have a number of situations where certain types of behaviour cannot be shown to be immoral, but are considered to be unethical.
"perhaps dangerous ideas belonging to hard-science types just don't lend themselves so well to the soundbite format?"
Or maybe because hard-science types might come up with dangerous ideas and then work out how to implement them? Far safer to use squishy science, where the only actual danger from those "dangerous ideas" is of somebody getting a stressful fit of pique while discussing one of them.
Religion claims that there gods. Some individual religions are based around monotheism, but religion is an inclusive word which includes polytheistic ones as well.
"You seemed to have entirely missed my point about writing image processing software. While I was talking about writing one piece of high-performance code (using templates) that can deal with multiple image formats (and gets automatically inlined by the compiler) automatically, you countered with using prefab Java LIBRARIES (what language do you think THOSE are written in?)"
Mostly Java, actually. This wasn't originally the case, but as Java's performance has increased, various parts of its core libraries have been rewritten in itself. The primary reason for this is to make porting it to other platforms easier: the less non-java code there is, the easier the system is to bootstrap with only a Java compiler.
"or Python (that also uses libraries written in C++ for high-performance image processing)."
Most Python libraries are written in C because that is what Python binds to. There are some C++ ones (usually with C "wrappers"), but then there are some written in other compiled languages as well.
"The mission-critical reference I was making was to Objective-C's runtime binding of functions. Without the compile-time checking you get from C++, Objective C lets you write code that calls functions that might not even exist."
You are missing the fact that Objective-C is perfectly capable of using static typing if required. You simply declare a pointer to a type directly as you would in C, e.g. "MyClass *aClass;", and voila! Any attempt to send a message isn't a member of "MyClass" on "aClass" will result in a compile-time warning. Dynamic types are therefore an option that you can use or not use, much like many C++ features. Note also that for those times when one wishes to avoid the overhead of the message dispatch system, Objective-C allows methods to be directly called by address. This is as fast as calling a C function by address (because that it what it is doing).
Sounds more like the sort of innovation one can make when one isn't trying to lock people into running a particular software instalzÒ_on on a single computer.
"Actually these were first defined in the 1994 revision of the C standard (also known as TC1), and then adopted by C++. Try #include in your C program."
Read what I said. This does not make the macro preprocessor aware of them, and they can therefore be changed by including a subsequent header which redefines one or more of them.
"Slightly odd way of writing that; as the C++ behaviour is far more desirable."
I never said otherwise. My point is that they are not the same, not which is preferable.
"it is a stupid idea to deliberately declare an object with external linkage without having an extern definition in a corresponding header file. (Either it will never be used by another TU, in which case it might as well have internal linkage; or the other TU will have to include an extern declaration, which is prone to error). And if there is an extern declaration in a header file then the definition is automatically extern, whether it's explicitly specified or not."
Again, I never made any claim about whether this particular C "feature" is desirable or sensible. I cited a difference between the way C and C++ handle something that could be a source of potential problems when compiling valid C source with a C++ compiler, and said nothing else about it.
Slashdot Mirror
"When the customer demends bug-free software he gets it."
I think it more often the case that a customer who demands _and is willing to pay for_ bug-free software gets it. I've come across lots of people who loudly insist on bug-free software until they see how much extra it's going to cost them.
"Firefox and openoffice are continous works in progress, as opposed to a project with a firm set of goals."
Each release has a firm set of goals though, so that release could be significantly less buggy than is currently the case.
"I doubt Praxis could make the same offer if customers changes the requirements, and feature list all the time."
Neither OO or Firefox have any customers, though: they are free software, and not therefore subject to the financial and competitive pressures that can and do result in buggy commercial projects. Who actually decides what features to add? The development team. Who sets deadlines for implementing these features?The development team. Who decides when they are coded to sufficient quality for public release? The development team. Who therefore is to blame when that code ends up being sub-par? The development team.
"Praxis also has certian requirements about the enviroment in which they work."
All software has specific operating environment requirements.
"If I took a Solaris 9.0 project, and tried to run it on linux 1.0, I don't think Praxis would be liable for the bugs that would occur."
How is this in any way relevant to the fact that both Firefox and OO are buggy? Such bugs manifest themselves on systems that both claim to support, and are not restricted to people who try and put them on (for example) an XBox-360.
Or "We can have three guys fresh out of college with really impressive degrees for the same price as this other person who is older, and therefore less likely to know about modern computing topics. We will therefore hire the three college graduates, who will then do three times as much useful work."
"IMO, this isn't a golden rule or even a good rule. Quite the contrary, I think code (OO or otherwise) should be designed and written for a particular purpose. If that purpose is to be derived from, good and well. If it's not, throwing in something to halfheartedly support derivation anyway is a poor idea."
I agree that it boils down to design, and that code should be designed for a specific purpose. However, OO in particular is primarily intended to support re-use by derivation -- without that, there is no real point in using it at all, especially in C++, which offers so many other mechanisms for expressing solutions to problems. I would thus argue that the very act of using OO to write code that does not support re-use is an indication that the programmer(s) did not design and write their code for a particular purpose, but were instead trying to force certain types of problems into a paradigm that is ill-suited to them.
"Going further and fully supporting derivation makes a bad situation still worse. You're still doing extra work, and probably introducing extra bugs, to make the code do something it's not really supposed to do."
See above. If this is the case, then OO is a non-optimal solution anyway.
"This is one area I agree with the people who advocate testing-oriented development -- you should define what the code really needs to do, and then write the simplest code you can that does it. Any extra capabilities, features, etc., beyond what it's really supposed to do is a bad thing."
I fully agree. But I would suggest that in a multi-paradigm language such as C++, trying to lever solutions into one of them that would be better expressed in another violates the "simplest possible" rule anyway. One of the things that makes C++ worth learning and using despite its complexity is its ability to express solutions to problems in ways that fit them naturally, unlike for example Java which forces all solutions into a single pre-conceived model, irrespective of whether that model is an appropriate one for the problem or not.
"The long and short of it is that teaching C++ well is not necessarily terribly difficult or complex. In fact, I think it's far easier to teach people to write reasonable- to good-quality C++ than even meciocre- to fair-quality C."
Agreed, but I would amplify your point somewhat. C++ can be taught more easily than C and indeed be significantly easier to program in than C if use of the STL is emphasised from the beginning, and "inherited" C features such as fixed-length arrays, "dumb" pointers, etc. are either left out entirely, or in the case of training materials for C programmers, discouraged (naturally with good explanations of why the STL solutions are preferable).
"I honestly don't mean to be sarcastic, but by this rule we should all be using really simple assemblers with no macro capability. At least IME, these are about the only languages sufficiently trivial that most users really do understand them almost completely."
I disagree here. It is perfectly possible to write a general-purpose programming language which is well-suited to both systems programming and applications programming without adding undue complexity. Oberon is a good example of such a language: its entire grammar can be expressed in 20 pages, and it is very easy indeed for any experienced programmer to learn, yet it can be (and indeed has been) used to write everything from operating systems through MVC frameworks to applications. I am not for a moment suggesting that it is better than C++, or that it is an equivalent: it merely serves as an example of something that fulfils many of the C++' stated design goals without being either complex or difficult to learn.
"The problem is that the rules being easy to learn doesn't generally seem to translate to good code, because bugs rarely arise from poor undstanding of arcane rules. Rather, they arise from the tedium of constantly ensuring that even the most trivial rule is followed."
I would not argue with this. H
" I can tell you that on review of code to add some new functionality or to tweak some bit of code, bugs and flaws are discovered that (almost) never would have been discovered by users ... while not a daily occurence, I suspect that every maintenance coder has found flaws in just this manner..."
I've found flaws in my own code when adding new functionality to it. And few if any of said flaws were found during testing or by end-users.
"I haven't been using any extrodinary definition of the word human, and it should have been fairly obvious from the context."
I know you weren't, but some of the things you were citing (and not necessarily agreeing with) did depend rather heavily on a specific definition of "human" in the context of the citation. For some, it could be simply "that which was created in God's image and imbued with an immortal soul", whereas others require a more complex and / or significantly less mystical definition to make sense.
""Emotional issues" means "issues that tend to stir up people's emotions" but does not mean that a person's stance on the issue depends on their emotional state at the time you ask the question".
I never said otherwise. I distinguish between an emotional response to a situation and a moralistic response solely by the respondent's ability (to paraphrase you) to unambiguously identify the foundation for their assertion that something is "wrong" rather than merely reacting against it "because". Morals (or usually contravention of them) is clearly capable of promoting an emotional response, but not all emotional responses have a corresponding moral foundation.
"For example, in order to support your assertion [actually the OP's] that morals only evolve and are unaffected by religious affiliation, you have attempted to define "moral" as requiring a "general consensus [across all of society], not something that is imposed by one part of society on an equally large but dissident portion"
I fail to see anything in the part of my text that you are quoting which implies or denies any particular source for a society's moral framework. I only state that collective morality must be agreed upon rather than imposed, i.e. that it is a shared belief, not a tyranny which is forced on large numbers of others against their will. This in no way precludes it being derived from a religious foundation if that religion is shared by the majority, neither does it presuppose that religion is the only possible foundation for a collective morality.
"[you are] attempting to use your own artificial re-definition of the word to define out morals influenced by religion on the grounds that members of other religions do not have the same ones."
I have written nothing which implies that religion cannot be the source of a society's shared morality, because many societies have moral codes which are clearly derived from a religious foundation. I do however distinguish between religiously inspired collective morality, and a selective interpretation of that morality which is not universally accepted being forced on everyone. Societies which do that sort of thing are known as theocracies.
You cite some things from the OED (an excellent dictionary):
Firstly, the etymology of a word and information on when it was first published have no relevance to this argument, because meanings of words regularly change over time, hence the fact that good dictionaries such as the OED have several definitions for most of them, including obsolete ones.
Secondly, I fail to see where you think the OED refutes anything I said, as I never claimed that morals and ethics are unrelated (in fact, I said the opposite). I distinguish between them merely in terms of scope: morality establishes a set of agreed behavioural guidelines, and ethics apply these morals to specific situations, some of which may not have existed when the original moral code was established.
NB: It seems that you are rather emotionally bound to this, and are therefore misreading a great deal of what I have said as being some sort of attack on you and your beliefs. I shall therefore terminate this debate by conceding victory to you, as it is only of interest to me from an academic viewpoint.
"While members of the academic community and relevant professionals such as doctors and legislators study these issues as ethics, members of the general populace tend to have fairly unambiguous moral stances on them. People do not tend to study ethics before they express the moral principle that the berieved relative must assent before a loved one's organs are harvested."
Firstly, the study of ethics is entirely separate from whether something is an ethical or moral issue. Secondly, I would argue that the stance most of the general populace takes on any of these issues is neither unambiguous or based on any particular moral position, but is instead usually an emotional response to a particular situation which the responder cannot describe in anything like unambiguous terms, or is based on religious dogma which may actually run contrary to the common moral base of a society.
"Neither do they tend to weigh up purjury even though they may feel that lying in other areas of life is 'ok'."
Perjury is a legal construct, not a moral or ethical one. It is thus quite possible to commit perjury while behaving in a manner that is both moral and ethical, while refusing to do so would be legal, but in some cases neither moral or ethical. Good laws may embody or reflect a society's morality, but they do not define it.
"And while for doctors and legislators the abortion debate is an ethical issue, for the pro-life US Conservatives and the pro-choice feminists it is simply a moral issue."
It is an emotional issue for both sides. Morals are sets of behaviours that are accepted by general consensus, not something that is imposed by one part of society on an equally large but dissident portion -- that is the job of laws, which I have already stated should (but often don't) reflect and even embody a society's morals but do not define them. And both sides of the debate obviously share a common morality which states that killing another human is wrong except under certain extenuating circumstances: what they disagree on is whether an unborn foetus is a human being or a part of its mother, and in many cases the point at which it ceases to be one and becomes the other. And their arguments about this definition all essentially boil down to either raw emotions, religious dogma, or a mixture of both.
"While it's clearly true that using templates with many types can increase the size of your code, I think the problem is overstated."
For most types of applications, I agree. Remember though that the point of mine that you are quoting specifically addresses embedded systems, which are often far more resource-constrained than general-purpose computing devices.
"Sure, if you were using generics where everything was done via RTTI and only a single instance of the code was needed, the output code would be somewhat smaller. However, we should remember that the RTTI itself imposes overheads, and there's far less scope for deep optimisations without the exact type knowledge you have with templates, so the ratio certainly won't be N:1 where N is the number of types over which our template was instantiated."
In the embedded systems I was addressing in the original point, the overhead of RTTI may also be unacceptable. Remember that such code very frequently targets specialist CPUs whose memory is on the chip die itself, so adding more memory is not an option. In these types of highly constrained environments, every byte that is required to support a language feature means one less byte for application logic, so they are commonly programmed in specialist manufacturer-supplied C dialects that directly support certain pieces of the chip's functionality without requiring any libraries (standard ones or otherwise). I am not saying that this is the case for all embedded systems, as there are some that include a full computer with disk drives and an OS such as Linux, but the bulk of embedded system work still targets specialist CPUs that operate in a much more restricted environment.
I am aware of Descartes, as well as the works of subsequent philosophers who quite successfully refute much of what he wrote. However, for the sake of argument, Descartes can indeed be cited as _a_ proof (which is what I asked for), and I shall therefore concede this particular line of argument to you.
"I guess it's how damned sincere you sounded, like you really -meant- what you were saying."
I was sincerely interested in what the definition of "human" was in that particular context. I was not asking for your definition of human or Wikipedia's, but rather the definition that those who base an entire philosophical, religious, or legal framework on humans being somehow special use. I think you will agree that without such a concrete definition, any contrary arguments become extremely difficult to make, because those in the counter-position can simply move the goal-posts whenever they wish to.
"What's done, however, is not a bitwise copy, but a memberwise copy. "
You are of course correct. My bad.
"The cure is to not use raw pointers on a regular basis. I can hardly remember the last time I had to write a copy ctor because I used a raw pointer."
Indeed. However, the fact that C++ is often advertised as a "better C" means that it attracts C programmers in large numbers, and C programmers use pointers as member variables a lot (I know this, because I've had to maintain their code). I think therefore that _all_ C++ books and courses should expound a rule in big, bold letters in a box that says "C++ has a variety of mechanisms that make the use of pointers for dynamically allocated member variables unnecessary. If however you are going to use pointers as member variables, you should provide your class with a copy constructor that initialises them properly when they are assigned to another variable of the same type."
"A class that doesn't have a virtual dtor generally means that class wasn't designed as a base class."
There is a golden rule in OO which says "Do not make any assumptions about the way people will use your classes". If a class isn't designed to be a base class, then there should be a header comment or some other piece of documentation that says so, otherwise people will assume they can inherit from it, and do so. I know this is true, because I have maintained large commercial code bases where this has happened, and has resulted in memory leaks. It's one of the reasons that Java takes the opposite approach of assuming that all classes are base classes unless prefixed with the "final" keyword, which indicates that they can only be instantiated, not inherited from (note that I am not saying this is a desirable solution, only that it is an attempt at a solution in a language that was heavily influenced by C++).
"There is (occassionally) a problem with a class that was intended to be used as a base class, but due to oversight the dtor wasn't made virtual. In this regard, C++ could be improved -- rather than requiring an explicit virtual dtor, it should make the dtor virtual if the class contains any virtual function."
I can assure you that it is more than occasional, but this is not a point that's worth arguing about, as it would eventually boil down to anecdotal evidence that we obviously do not share. However, I don't really think the language needs changing in that way, because it is specifically designed to do what you tell it instead of making assumptions about what you may or may not be doing, and I would argue that this is a major reason for it being so successful, as well as being a major reason for some code bases having many errors in them. Perhaps a good compromise would be for the compiler to issue a warning whenever somebody derives a class from one with a non-virtual destructor, or better still, warn when such a class is used polymorphically (which is after all the only time that this particular problem arises). After all, what may be an error in one person's code could be a deliberate design decision made for a very good reason in someone else's. It is for this reason that I prefer warnings to errors that prevent compilation, and prefer errors to languages that change my code into something else without being told to (a compiler switch or pragma would of course equate to being told to do it).
"IOW, much of the problem really arises from teachers trying to push OO as the answer to everything, and overusing derivation when it's not suitable or useful."
Agreed. However, this is largely due to the fact that C++ owes much of its popularity to the 1990s wave of pushing OO as a silver bullet that would magically solve all of the programming world's problems. A lot of people came to C++ from other languages (usually not OO ones, because experienced OO programmers knew that it wasn't a magic bullet at all) during that wave, and are pretty much locked into that mind-set, and they're often the people who are writing books and teaching it in
1. Wikkipedia is not an authority. It is a bunch of stuff that some people felt like putting in there, and therefore carries no more weight than a slashdot post.
2. This is slashdot. Petty squabbles about semantics, spelling, punctuation, definitions, etc., are part and parcel of it, and always have been.
3. This part of the thread revolves around whether being human is a qualitative or quantitative attribute (i.e. whether we are evolved animals, or something more). Such an argument is meaningless unless a concrete definition of what is meant _in this context_ by "human" can be arrived at.
"There are no definitions (for anything) that would both be devoid of circular reasoning and not rely on other, nondefined things."
Proof? This is a bold assertion that requires rather more to back it up than you merely stating that it is so.
"After all, defining a term means describing it in other terms."
Which you did not do. You defined "human" as "human", thereby describing it entirely in terms of itself. Thus, the initial definition is completely based on circular reasoning, not part of a chain that ultimately resolves to unprovable axioms or undefinable references.
It is you who seem to be confused. For example:
"animal moral behaviours do not "closely resemble" our own except for an extraordinarily broad interpretation of "closely resemble". Animals do not have organ-transplants to have morals about whether the family of the donor should have to assent, they do not have courts to have moral beliefs about whether they should present false evidence in them, they do not have abortions to debate how close to term the foetus has to be before it has the same rights as its mother, etc etc."
The above are all examples of ethics, not morals. A moral is "it is wrong to kill another person"; whether an unborn foetus counts as a person (and indeed at what stage of development such "person-ness" appears) is an ethical matter. Morals cover broad issues, ethics are an attempt to reconcile morals with situations where the moral in and of itself cannot be unambiguously applied. We thus have a number of situations where certain types of behaviour cannot be shown to be immoral, but are considered to be unethical.
A quote from from Wikipedia has the same level of authority as the girl at the supermarket checkout's opinion on a topic, i.e. none whatsoever.
"perhaps dangerous ideas belonging to hard-science types just don't lend themselves so well to the soundbite format?"
Or maybe because hard-science types might come up with dangerous ideas and then work out how to implement them? Far safer to use squishy science, where the only actual danger from those "dangerous ideas" is of somebody getting a stressful fit of pique while discussing one of them.
"Religion makes a claim that there is a god."
Religion claims that there gods. Some individual religions are based around monotheism, but religion is an inclusive word which includes polytheistic ones as well.
Without a definition of "human" that does not involve circular reasoning, your prior statement is completely devoid of meaning.
"You seemed to have entirely missed my point about writing image processing software. While I was talking about writing one piece of high-performance code (using templates) that can deal with multiple image formats (and gets automatically inlined by the compiler) automatically, you countered with using prefab Java LIBRARIES (what language do you think THOSE are written in?)"
Mostly Java, actually. This wasn't originally the case, but as Java's performance has increased, various parts of its core libraries have been rewritten in itself. The primary reason for this is to make porting it to other platforms easier: the less non-java code there is, the easier the system is to bootstrap with only a Java compiler.
"or Python (that also uses libraries written in C++ for high-performance image processing)."
Most Python libraries are written in C because that is what Python binds to. There are some C++ ones (usually with C "wrappers"), but then there are some written in other compiled languages as well.
"The mission-critical reference I was making was to Objective-C's runtime binding of functions. Without the compile-time checking you get from C++, Objective C lets you write code that calls functions that might not even exist."
You are missing the fact that Objective-C is perfectly capable of using static typing if required. You simply declare a pointer to a type directly as you would in C, e.g. "MyClass *aClass;", and voila! Any attempt to send a message isn't a member of "MyClass" on "aClass" will result in a compile-time warning. Dynamic types are therefore an option that you can use or not use, much like many C++ features. Note also that for those times when one wishes to avoid the overhead of the message dispatch system, Objective-C allows methods to be directly called by address. This is as fast as calling a C function by address (because that it what it is doing).
"It's a guiding ideal based on the essential quality of being Human"
Which is?
Sod it. Should have previewed! That should read "particular software installation".
Sounds more like the sort of innovation one can make when one isn't trying to lock people into running a particular software instalzÒ_on on a single computer.
"Actually these were first defined in the 1994 revision of the C standard (also known as TC1), and then adopted by C++. Try #include in your C program."
Read what I said. This does not make the macro preprocessor aware of them, and they can therefore be changed by including a subsequent header which redefines one or more of them.
"Slightly odd way of writing that; as the C++ behaviour is far more desirable."
I never said otherwise. My point is that they are not the same, not which is preferable.
"it is a stupid idea to deliberately declare an object with external linkage without having an extern definition in a corresponding header file. (Either it will never be used by another TU, in which case it might as well have internal linkage; or the other TU will have to include an extern declaration, which is prone to error). And if there is an extern declaration in a header file then the definition is automatically extern, whether it's explicitly specified or not."
Again, I never made any claim about whether this particular C "feature" is desirable or sensible. I cited a difference between the way C and C++ handle something that could be a source of potential problems when compiling valid C source with a C++ compiler, and said nothing else about it.
Then the Linux and BSD kernels are obviously of no value, because they will not compile into usable code with a C++ compiler.