A month ago I've read from somewhere that growing genetically modified plants without a license is prohibited (somewhere in the world), and, if such plant is found, one has to destroy them immediately.
Let's see whether that will apply to human beings.
> in all but the most complex cases of straight C
> code, C++ requires an extra level of
> indirection.
There are two type of failures that people can get when they see OOP.
I see many tech guys that says OOP is not required in most case, so why bother learning it. Like you, they say that OOP is not required except the most complicated case. They don't realize that how much code have to be made simpler and cater for less cases, or made less reusable than required, so that simple function call is needed. They don't realize that few uses any function pointers in their programs even in places that it would help. Even fewer see the limitations of that little function pointers. They don't see that since so many programmers are trained to do C programming, even in places that is perfectly suitable for polymorphism, they use a simple function call instead, ending up in very ad-hoc code.
There are people doing just the reverse: they think that the world is a whole lot of objects, so model everything as objects. They think that OOP is the only right tool. Every function should be a method, every data should reside in some class. Everything is ugly unless it get a very clean interface. If it breaks abstractions, don't optimize things even if it is in the critical path. Even very simple things end up hidden in piles of abstractions.
Interestingly, the two groups reinforce each other: the first group keep on blaming the second for the lack of efficiency in their code, the second group keep on battering the first for writing ugly, ad-hoc, unreusable code that require rewrite forever.
When will people understand that every programming paradigm has its strength and its weakness, that they have to be selected on a case-by-case basis instead of by a single bold far-reaching statement?
Task switch is bad due to memory overhead if we need a cache flush during task switch. For all I understand, everything after 486 won't require a cache flush for that. Then it boils down to the amount of memory required for both the server and the client in a micro-kernel, and the total amount of memory required for both the kernel and the user in a monolithic kernel. In that case I can't see where a micro-kernel lose to a monolithic one.
But what can't be done with a new name? The only thing that can't be done is to harvest on the good name ssh. I see it like that the company SSH let IETF use their name as the protocol (as suppose to another random name, let's say wasp, Wasp's a secure-shell protocol) so that the public call it ssh instead of wasp, so that their company get advertised. Now that ssh instead of wasp gets the publicity, so they retract what they have given away and say they want IETF to say wasp, so that everybody will think of their product as common, open, standard, etc. Should we really allow a public standard organization to be (ab)used this way?
> 'We can build a better product than Linux,'' he
> [Allchin] said.
> So... why don't they?:P
The word "can" says it all. It means "has the capability to". So let's interpret it this way:
"We can build a better product than Linux, but we don't want to do that, and we don't want to see it. But now Linux is becoming better and better everyday. Obviously it is a threat to us. We are the innovation, so Linux is threatening innovations. Stop this!!"
Or is it probably a good news? It is well known that current Debian-based distributions do not do as well as Debian itself for quite a number of aspects, especially policy compliance and security fixes rate. The fall of Corel and Stormix will pave an easier road for Propency to grasping the small Debian-based market and give it an easier start.
> If the same type appears as an ancestor more
> than once, should all or some of its data
> components be duplicated, or shared? If any are
> duplicated, how are they referenced
> unambiguously?
In pure OO terms, they need to be shared, and having them duplicated is just a performance consideration. But Java in general throw away performance consideration anyway, so it should be an easy choice---were the developers really want MI to be in.
> If the same-named (including same
> parameter/result profile) operation is inherited
> along two paths, how is the ambiguity resolved?
> Can you override each with different code? How
> do you refer to them later?
Why bother? If we have MI, most likely the code is called only from the code below, i.e. from the base class. And if it is called from the above, i.e. from the users of the class, you can easily specify what should happen by overriding the method in the subclass itself.
> I would think so that you could override it if
> you wanted.
Crazy. Should constructors not automatically chained "so that you can override it if you want"?!
> Say I've got a class A with method "doIt" and
> then, a pure virtual class B with method "doIt"
> and suppose then that I want class C to derive A
> and "implement" B...
> C: public A, public B
If you do that in C++, what will happen is that you cannot have C c and then call c.doIt(). But so what? All the invocation of c.doIt() is probably from A and B anyway, and you seldom call c.doIt(). In any case, you can specify to call A::doIt or B::doIt in C++.
Java lovers keep saying that multiple inheritance is too complicated to implement. But just look at their library and see how the lack of multiple inheritance make the input output system a complete piece of crap.
People keep on saying that interface is sufficient. Definitely. After all, you can always have a class and use aggregration, and pass everything to it manually. But then, if that is to be done everytime, why not make it into the language?
The C++ multiple inheritance really got its own share of problem. Namely, the only one who can decide that a base class is virtual actually don't really know whether it should be done that way. I'd be grateful if Java actually try to tackle that problem. They didn't. They just remove multiple inheritance altogether.
Now that Java has the super keyword, I think that's completely unfixable now.:(
Before reading this thread, I'd agree. But now I completely reject this concept.
Suppose somebody writes a library, and the library requires you to supply it an object, and will call it back when needed. Then the library is suddenly forced to know what exception that YOUR method will throw (but of course it doesn't)---or to say that it "throws Exception", or to force you to throw only unchecked exceptions.
Really, horrible design. I can imagine that this has to be done everywhere. Then why talk about checkable exceptions at all?
Because it is the best possible algorithm when the input contains 3 elements, and only 1 comparison off the best algorithm when the inpu contains 4. That cannot be said to, say, quick sort or merge sort.
> You're kidding- Java doesn't have operator
> overloading? I never programmed much in Java
> (ran through a tutorial or two), but I suppose I
> assumed it did. Ouch.
I always think that those advocating Java are really unfair. They say that operators are complicated concepts and so they shouldn't be in the language, but then they are developing it themselves. They say that templates are too complicated concept to support and so they shouldn't be in the language. But they are actively developing the generic keyword.
The words of Stroustrup might have some truth: every language extends to the complexity that the reality requires. Soon nobody can claim that Java is a simpler language than C++.
Yes, I do use Java: in fact, I teach Java. But I'm really tired of hearing completely unfair comments to its ancesters.
"What? You need an illegal player to play all my Japanese DVDs? Then I'd rather go illegal", and leave.
What this clearly show to the sales is that "legal" is NOT the thing that customers WANT. They WANT functionality. They CARE freedom. Legistration simply WON'T work. And we let them propagate this message up.
It really install to/usr/local/bin? Then the distributor of Quake2 is violating FHS. The whole packaging system is not supposed to touch the/usr/local directory!
> (6) LILO.
> To "exploit" this, you'd need physical access, at which point the attacker could
> just as well boot off a floppy. If an attacker has physical access, the game is
> over.
To perform the attack suggested by the article, you only need physical access to anything that can cause a reboot (e.g. power switch, or a keyboard configured to honor the three-finger-salute) plus a keyboard. On the other hand, to adminstrate anything that you, or others who argue on the same line, suggested, you have to get physical access to other hardware like floppy drives (which might well be absent from machines configured for public use), case of machine (probably locked in safe place) and so on. Why is it always said to be "false sense of security, if the change of config file at least allow the keyboard and monitor to be safely exposed to the public?
Except that in Debian, STABLE does not mean programs runs correctly or reliably. Instead it means it won't change regularly, unlike frozen or unstable.
Re:C++ as a teaching language/programming obscure?
on
Who's Afraid Of C++?
·
· Score: 1
No. For a new comer of C++, before he actually touch on OOP, the main difference between C and C++ is that C++ has a bigger library (esp. the part called STL), and the library don't ask you to do a lot of casting before anything work.
Say, how will you teach students to sort an array? Would you ask them to write bubble sort? Sure, you can. But will you ask them to write:
int arr[100]; /* fill arr here */ qsort(arr, 100, sizeof(int), comp);
The C library provide few good functions for such common usage, and when they do they have to provide it is a real obscured way because the language is "simple". How about C++?
sort(arr.begin(), arr.end());
Okay. That's just for sorting. How about an associative array? A linked list? STL give you all, and in C they have to be exercise for the new comers (before they learn a data structure course).
Experienced programmers tends to forget things that were non-trivial for the first time programmers after they are accustomed to it. Even the input/output of C is awkward. Think about:
printf("%d\n", 20);
Why I have to tell printf that what coming after is an integer? Did the compiler already know that? Is it that "20" can be interpreted in some other way? It's plain strange. Compare it with C++:
cout 20 endl;
The compiler knows everything: 20 is an integer, endl should print out a new line. Oh. What's the type of that endl? Who cares?
OOP is an important feature of C++. But it is not that important to new comers. New comers won't make big programs, and the programs of new comers are not reusable anyway because they are so primitive. They want to reuse the code of others much more than writing code which can be reused by someone.
Yes, technology calls for standard, and that's why there is LSB.
But that really don't mean all of us have to use the same distribution, be it Redhat, Debian, SuSE, Slackware or whatever! People do WANT choice. If technology can't give them, who can?
Problem #1: there is only one "true" Qt, not only one "true" KDE. Qt is distributed under QPL which says you cannot fork it. KDE is distributed under GPL which says anyone can fork it.
Problem #2: to have only one "true" Qt, it is much better to call for trademark law. In the current situation, you can't have a qxt derived from qt, although your qxt has no intention to fake a qt.
Problem #3: now there is no legal KDE at all, not even one. Once KDE got more than a few dozens of developers, it is basically impossible for even the KDE main distribution site to ask for permission from each of them.
1. Multiple inheritance is great for design and code reuse, but very bad for speed. Calling a virtual function can have 5-10 times as much overhead as a conventional call. This is because your program has to look up in a "v-table" to find out exactly which function is actually being used.
The v-table is nothing to do with multiple inheritance at all. It only has to do with virtual functions: the v-table tells the C++ program what function to call for the particular type of variable. This is why the "virtual" keyword is there: it get into performance.
On the other hand, multiple inheritance didn't increase the overhead of function calls for most things--until you use virtual base. At that point you'll have another "base-pointer" to traverse whenever you want to call methods or access members of the base object. But of course, you can have virtual base class even if you only use single inheritance, its the "provision" of multiple inheritance that matters, not the use of it in fact. This is just like the virtual keyword.
I have the impression that the aliasing problem happen only on "real" programs, not on benchmarks. Aliasing is usually a problem only if the program contains a number of function which calls each other. At this point there are ways for variables to be aliased. For benchmarks, usually every big things happen in a single function which define everything as local variables, there is no problem of alias at all.
I don't really know, but the original sender might be refering to this:
--- from gcc info --- `-fbranch-probabilities' After running a program compiled with `-fprofile-arcs' (*note Options for Debugging Your Program or `gcc': Debugging Options.), you can compile it a second time using `-fbranch-probabilities', to improve optimizations based on guessing the path a branch might take.
With `-fbranch-probabilities', GCC puts a `REG_EXEC_COUNT' note on the first instruction of each basic block, and a `REG_BR_PROB' note on each `JUMP_INSN' and `CALL_INSN'. These can be used to improve optimization. Currently, they are only used in one place: in `reorg.c', instead of guessing which path a branch is mostly to take, the `REG_BR_PROB' values are used to exactly determine which path is taken more often. --- end quote ---
Of course, it is no dynamic optimization, but at least it is a step closer to it.
Why people continue to get it wrong, and get it wrong badly? It seems to me that the author must be unable to read, or unwilling to read, or unable to reason from what he read.
Nowhere in the hundreds of pages of GNU and FSF literature is there any serious explanation of why it is legitimate, for example, to make a living selling cauliflowers,..., but criminal to peddle software that you have produced by working long hours, sweating your heart out,...
Why?! In the GNU Manifesto:
The reason a good citizen does not use such destructive means to
become wealthier is that, if everyone did so, we would all become poorer from the mutual destructiveness. This is Kantian ethics; or, the Golden Rule. Since I do not like the consequences that result if everyone hoards information, I am required to consider it wrong for one to do so. Specifically, the desire to be rewarded for one's creativity does not justify depriving the world in general of all or part of that creativity.
It clearly answer why proprietary software are bad: it is bad to the society, by not giving to the society what one has to offer to the fullest extend. If everybody keep on doing it, we waste most of our efforts.
The only stated justification for the indictment of commercial software... is that software is different from other wares since it can be reproduced so easily. But this does not stand a minute's scrutiny.
Reproducibility is important to make the judgement that proprietary licenses are bad, but other factors are important to establishing that it is actually harmful to the society. See the following, again from GNU Manifesto:
The case of programs today is very different from that of books a
hundred years ago. The fact that the easiest way to copy a program is from one neighbor to another, the fact that a program has both source code and object code which are distinct, and the fact that a program is used rather than read and enjoyed, combine to create a situation in which a person who enforces a copyright is harming society as a whole both materially and spiritually; in which a person should not do so regardless of whether the law enables him to.
In any case, "cheap to copy" only means that you shouldn't interfere with me copying it, not that you must not sell it.
The GNU and FSF view is that it is OK to sell anything except software.
The fact is, FSF sell software, and proprietary software producers only license them. FSF sell them by putting them into tapes and CD-ROMs and ask for money in it. The following comes from the WHY-FREE document in GNU Emacs:
The Free Software Foundation, a tax-exempt charity for free software development, raises funds by selling CD-ROMs, tapes and manuals (all of which users are free to copy and change), as well as from donations. It now has a staff of five programmers, plus three employees who handle mail orders.
Proprietary software producers never admit that the software is sold. Read the software license agreement you have in any software product (maybe driver software accompanied with hardware product) to be convinced about it.
The GNU license itself reads not like a license but like a manifesto against the evils of proprietary software
What can you do otherwise if you want to use software license to combat with others who use software license to impede the public?
This distortion--the hijacking for private purposes of a word that holds such a sacred aura for most people--is highly unethical.
This may be true from the perspective of Meyer, who clearly demonstrate a strong prejustice against free software. This is not true for most people especially programmers: they does appreciate that they are allowed to use code from others and fix bugs there. It is really a question about freedom, since we are really deprived from such things for proprietary software.
Compare this to the numerous deflections that the software venders put on us, like "software pirates". See who is the one unethical.
Even though the GNU products are often good, the licenses which accompany them are no better...
But who need warranties?! This is only needed for proprietary software because we ourselves have no SINGLE way to solve the problems there. For GNU software, we are entitled, and encouraged, to fix it anyway. For proprietary software, we are forbidden to do it.
There are still much more to say about it, but I really don't want a browser crash to take all these. I can only conclude by saying I'm really sorry for Meyer.
Slashdot Mirror
A month ago I've read from somewhere that growing genetically modified plants without a license is prohibited (somewhere in the world), and, if such plant is found, one has to destroy them immediately.
Let's see whether that will apply to human beings.
Try g++ 3.0 pre-release. It's standard libraries are much more standard compliant.
> in all but the most complex cases of straight C
> code, C++ requires an extra level of
> indirection.
There are two type of failures that people can get when they see OOP.
I see many tech guys that says OOP is not required in most case, so why bother learning it. Like you, they say that OOP is not required except the most complicated case. They don't realize that how much code have to be made simpler and cater for less cases, or made less reusable than required, so that simple function call is needed. They don't realize that few uses any function pointers in their programs even in places that it would help. Even fewer see the limitations of that little function pointers. They don't see that since so many programmers are trained to do C programming, even in places that is perfectly suitable for polymorphism, they use a simple function call instead, ending up in very ad-hoc code.
There are people doing just the reverse: they think that the world is a whole lot of objects, so model everything as objects. They think that OOP is the only right tool. Every function should be a method, every data should reside in some class. Everything is ugly unless it get a very clean interface. If it breaks abstractions, don't optimize things even if it is in the critical path. Even very simple things end up hidden in piles of abstractions.
Interestingly, the two groups reinforce each other: the first group keep on blaming the second for the lack of efficiency in their code, the second group keep on battering the first for writing ugly, ad-hoc, unreusable code that require rewrite forever.
When will people understand that every programming paradigm has its strength and its weakness, that they have to be selected on a case-by-case basis instead of by a single bold far-reaching statement?
Task switch is bad due to memory overhead if we need a cache flush during task switch. For all I understand, everything after 486 won't require a cache flush for that. Then it boils down to the amount of memory required for both the server and the client in a micro-kernel, and the total amount of memory required for both the kernel and the user in a monolithic kernel. In that case I can't see where a micro-kernel lose to a monolithic one.
But what can't be done with a new name? The only thing that can't be done is to harvest on the good name ssh. I see it like that the company SSH let IETF use their name as the protocol (as suppose to another random name, let's say wasp, Wasp's a secure-shell protocol) so that the public call it ssh instead of wasp, so that their company get advertised. Now that ssh instead of wasp gets the publicity, so they retract what they have given away and say they want IETF to say wasp, so that everybody will think of their product as common, open, standard, etc. Should we really allow a public standard organization to be (ab)used this way?
> 'We can build a better product than Linux,'' he
:P
> [Allchin] said.
> So... why don't they?
The word "can" says it all. It means "has the capability to". So let's interpret it this way:
"We can build a better product than Linux, but we don't want to do that, and we don't want to see it. But now Linux is becoming better and better everyday. Obviously it is a threat to us. We are the innovation, so Linux is threatening innovations. Stop this!!"
Or is it probably a good news? It is well known that current Debian-based distributions do not do as well as Debian itself for quite a number of aspects, especially policy compliance and security fixes rate. The fall of Corel and Stormix will pave an easier road for Propency to grasping the small Debian-based market and give it an easier start.
> If the same type appears as an ancestor more
> than once, should all or some of its data
> components be duplicated, or shared? If any are
> duplicated, how are they referenced
> unambiguously?
In pure OO terms, they need to be shared, and having them duplicated is just a performance consideration. But Java in general throw away performance consideration anyway, so it should be an easy choice---were the developers really want MI to be in.
> If the same-named (including same
> parameter/result profile) operation is inherited
> along two paths, how is the ambiguity resolved?
> Can you override each with different code? How
> do you refer to them later?
Why bother? If we have MI, most likely the code is called only from the code below, i.e. from the base class. And if it is called from the above, i.e. from the users of the class, you can easily specify what should happen by overriding the method in the subclass itself.
> I would think so that you could override it if
> you wanted.
Crazy. Should constructors not automatically chained "so that you can override it if you want"?!
> Say I've got a class A with method "doIt" and
> then, a pure virtual class B with method "doIt"
> and suppose then that I want class C to derive A
> and "implement" B...
> C: public A, public B
If you do that in C++, what will happen is that you cannot have C c and then call c.doIt(). But so what? All the invocation of c.doIt() is probably from A and B anyway, and you seldom call c.doIt(). In any case, you can specify to call A::doIt or B::doIt in C++.
Java lovers keep saying that multiple inheritance is too complicated to implement. But just look at their library and see how the lack of multiple inheritance make the input output system a complete piece of crap.
:(
People keep on saying that interface is sufficient. Definitely. After all, you can always have a class and use aggregration, and pass everything to it manually. But then, if that is to be done everytime, why not make it into the language?
The C++ multiple inheritance really got its own share of problem. Namely, the only one who can decide that a base class is virtual actually don't really know whether it should be done that way. I'd be grateful if Java actually try to tackle that problem. They didn't. They just remove multiple inheritance altogether.
Now that Java has the super keyword, I think that's completely unfixable now.
Before reading this thread, I'd agree. But now I completely reject this concept.
Suppose somebody writes a library, and the library requires you to supply it an object, and will call it back when needed. Then the library is suddenly forced to know what exception that YOUR method will throw (but of course it doesn't)---or to say that it "throws Exception", or to force you to throw only unchecked exceptions.
Really, horrible design. I can imagine that this has to be done everywhere. Then why talk about checkable exceptions at all?
Because it is the best possible algorithm when the input contains 3 elements, and only 1 comparison off the best algorithm when the inpu contains 4. That cannot be said to, say, quick sort or merge sort.
> You're kidding- Java doesn't have operator
> overloading? I never programmed much in Java
> (ran through a tutorial or two), but I suppose I
> assumed it did. Ouch.
I always think that those advocating Java are really unfair. They say that operators are complicated concepts and so they shouldn't be in the language, but then they are developing it themselves. They say that templates are too complicated concept to support and so they shouldn't be in the language. But they are actively developing the generic keyword.
The words of Stroustrup might have some truth: every language extends to the complexity that the reality requires. Soon nobody can claim that Java is a simpler language than C++.
Yes, I do use Java: in fact, I teach Java. But I'm really tired of hearing completely unfair comments to its ancesters.
I'd definite answer him this way...
"What? You need an illegal player to play all my Japanese DVDs? Then I'd rather go illegal", and leave.
What this clearly show to the sales is that "legal" is NOT the thing that customers WANT. They WANT functionality. They CARE freedom. Legistration simply WON'T work. And we let them propagate this message up.
It really install to /usr/local/bin? Then the distributor of Quake2 is violating FHS. The whole packaging system is not supposed to touch the /usr/local directory!
Agreed with most, except this...
> (6) LILO.
> To "exploit" this, you'd need physical access, at which point the attacker could
> just as well boot off a floppy. If an attacker has physical access, the game is
> over.
To perform the attack suggested by the article, you only need physical access to anything that can cause a reboot (e.g. power switch, or a keyboard configured to honor the three-finger-salute) plus a keyboard. On the other hand, to adminstrate anything that you, or others who argue on the same line, suggested, you have to get physical access to other hardware like floppy drives (which might well be absent from machines configured for public use), case of machine (probably locked in safe place) and so on. Why is it always said to be "false sense of security, if the change of config file at least allow the keyboard and monitor to be safely exposed to the public?
Except that in Debian, STABLE does not mean programs runs correctly or reliably. Instead it means it won't change regularly, unlike frozen or unstable.
No. For a new comer of C++, before he actually touch on OOP, the main difference between C and C++ is that C++ has a bigger library (esp. the part called STL), and the library don't ask you to do a lot of casting before anything work.
/* fill arr here */
Say, how will you teach students to sort an array? Would you ask them to write bubble sort? Sure, you can. But will you ask them to write:
int comp(void *a, void *b) {
return *(int *)a-*(int *)b;
}
int arr[100];
qsort(arr, 100, sizeof(int), comp);
The C library provide few good functions for such common usage, and when they do they have to provide it is a real obscured way because the language is "simple". How about C++?
sort(arr.begin(), arr.end());
Okay. That's just for sorting. How about an associative array? A linked list? STL give you all, and in C they have to be exercise for the new comers (before they learn a data structure course).
Experienced programmers tends to forget things that were non-trivial for the first time programmers after they are accustomed to it. Even the input/output of C is awkward. Think about:
printf("%d\n", 20);
Why I have to tell printf that what coming after is an integer? Did the compiler already know that? Is it that "20" can be interpreted in some other way? It's plain strange. Compare it with C++:
cout 20 endl;
The compiler knows everything: 20 is an integer, endl should print out a new line. Oh. What's the type of that endl? Who cares?
OOP is an important feature of C++. But it is not that important to new comers. New comers won't make big programs, and the programs of new comers are not reusable anyway because they are so primitive. They want to reuse the code of others much more than writing code which can be reused by someone.
Yes, technology calls for standard, and that's why there is LSB.
But that really don't mean all of us have to use the same distribution, be it Redhat, Debian, SuSE, Slackware or whatever! People do WANT choice. If technology can't give them, who can?
Problem #1: there is only one "true" Qt, not only one "true" KDE. Qt is distributed under QPL which says you cannot fork it. KDE is distributed under GPL which says anyone can fork it.
Problem #2: to have only one "true" Qt, it is much better to call for trademark law. In the current situation, you can't have a qxt derived from qt, although your qxt has no intention to fake a qt.
Problem #3: now there is no legal KDE at all, not even one. Once KDE got more than a few dozens of developers, it is basically impossible for even the KDE main distribution site to ask for permission from each of them.
That Redhat and SuSE decided to ignore the law and distribute KDE anyway do not mean that it is not their problem. They just ignored the problem.
The v-table is nothing to do with multiple inheritance at all. It only has to do with virtual functions: the v-table tells the C++ program what function to call for the particular type of variable. This is why the "virtual" keyword is there: it get into performance.
On the other hand, multiple inheritance didn't increase the overhead of function calls for most things--until you use virtual base. At that point you'll have another "base-pointer" to traverse whenever you want to call methods or access members of the base object. But of course, you can have virtual base class even if you only use single inheritance, its the "provision" of multiple inheritance that matters, not the use of it in fact. This is just like the virtual keyword.
I have the impression that the aliasing problem happen only on "real" programs, not on benchmarks. Aliasing is usually a problem only if the program contains a number of function which calls each other. At this point there are ways for variables to be aliased. For benchmarks, usually every big things happen in a single function which define everything as local variables, there is no problem of alias at all.
I don't really know, but the original sender might be refering to this:
--- from gcc info ---
`-fbranch-probabilities'
After running a program compiled with `-fprofile-arcs' (*note
Options for Debugging Your Program or `gcc': Debugging Options.),
you can compile it a second time using `-fbranch-probabilities',
to improve optimizations based on guessing the path a branch might
take.
With `-fbranch-probabilities', GCC puts a `REG_EXEC_COUNT' note on
the first instruction of each basic block, and a `REG_BR_PROB'
note on each `JUMP_INSN' and `CALL_INSN'. These can be used to
improve optimization. Currently, they are only used in one place:
in `reorg.c', instead of guessing which path a branch is mostly to
take, the `REG_BR_PROB' values are used to exactly determine which
path is taken more often.
--- end quote ---
Of course, it is no dynamic optimization, but at least it is a step closer to it.
Why?! In the GNU Manifesto:
It clearly answer why proprietary software are bad: it is bad to the society, by not giving to the society what one has to offer to the fullest extend. If everybody keep on doing it, we waste most of our efforts.
Reproducibility is important to make the judgement that proprietary licenses are bad, but other factors are important to establishing that it is actually harmful to the society. See the following, again from GNU Manifesto:
In any case, "cheap to copy" only means that you shouldn't interfere with me copying it, not that you must not sell it.
The fact is, FSF sell software, and proprietary software producers only license them. FSF sell them by putting them into tapes and CD-ROMs and ask for money in it. The following comes from the WHY-FREE document in GNU Emacs:
Proprietary software producers never admit that the software is sold. Read the software license agreement you have in any software product (maybe driver software accompanied with hardware product) to be convinced about it.
What can you do otherwise if you want to use software license to combat with others who use software license to impede the public?
This may be true from the perspective of Meyer, who clearly demonstrate a strong prejustice against free software. This is not true for most people especially programmers: they does appreciate that they are allowed to use code from others and fix bugs there. It is really a question about freedom, since we are really deprived from such things for proprietary software.
Compare this to the numerous deflections that the software venders put on us, like "software pirates". See who is the one unethical.
But who need warranties?! This is only needed for proprietary software because we ourselves have no SINGLE way to solve the problems there. For GNU software, we are entitled, and encouraged, to fix it anyway. For proprietary software, we are forbidden to do it.
There are still much more to say about it, but I really don't want a browser crash to take all these. I can only conclude by saying I'm really sorry for Meyer.