| This is the
talk page for discussing improvements to the
Software entropy redirect. This is not a forum for general discussion of the article's subject. |
Article policies
|
| Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
 | This redirect does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||
| ||||||||
There are plenty of quotes that refer to the term software entropy in professional books
https://www.google.com/search?tbs=bks:1&q=%22Software+entropy%22 — Preceding unsigned comment added by 146.90.69.148 ( talk) 17:19, 8 January 2014 (UTC)
The article does well to point out that the 2nd law of thermodynamics applies to a system that is closed.
It then states: "This law also seems plausible for software systems; as a system is modified, its disorder, or entropy, always increases".
Since it is possible to modify a software system by removing functionality and at the same time reduce its complexity, it is false to state that the disorder (or entropy) of a software system "always increases".
Example: One can modify a C-program, so that only main() and a return statement remains. For any non-trivial C-program, this modification will not increase the disorder (or entropy).
So in order to meaningfully compare to thermodynamical entropy, the article needs to explain under what conditions the software system can be considered closed.
Hopefully, this is clear from the cited sources. Lklundin ( talk) 06:40, 13 January 2016 (UTC)
Therefore "software entropy" must be at least indirectly related to Entropy (information theory).
The concept of software entropy has been poorly defined in this article and elsewhere. It contains a number of half/un-truths. aphorisms make for poor axioms. Statements like "a computer program that is used will be modified" do not add any value to this page, and "when a program is modified, its complexity will increase, provided that one does not actively work against this" is simply not true. Refactorings and deletions may in fact reduce complexity and there is no relationship between complexity and entropy.
If this topic bears any relationship to the [second law of thermal dynamics], then it logically MUST be derived from [information theory]. Jacobson et al, were not rigorous in their definition of software entropy and should not be quoted here for the purpose of defining software entropy. Referenced perhaps, for the purpose of establishing that the trade has used the term, at at least loosely, as far back as 1992.
I think software rot/decay is more like what we mean by entropy, wrt to software. That article is also better written and would be improved if it did not link to this awful definition of software entropy.
| This is the
talk page for discussing improvements to the
Software entropy redirect. This is not a forum for general discussion of the article's subject. |
Article policies
|
| Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
|
| This redirect does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||
| ||||||||
There are plenty of quotes that refer to the term software entropy in professional books
https://www.google.com/search?tbs=bks:1&q=%22Software+entropy%22 — Preceding unsigned comment added by 146.90.69.148 ( talk) 17:19, 8 January 2014 (UTC)
The article does well to point out that the 2nd law of thermodynamics applies to a system that is closed.
It then states: "This law also seems plausible for software systems; as a system is modified, its disorder, or entropy, always increases".
Since it is possible to modify a software system by removing functionality and at the same time reduce its complexity, it is false to state that the disorder (or entropy) of a software system "always increases".
Example: One can modify a C-program, so that only main() and a return statement remains. For any non-trivial C-program, this modification will not increase the disorder (or entropy).
So in order to meaningfully compare to thermodynamical entropy, the article needs to explain under what conditions the software system can be considered closed.
Hopefully, this is clear from the cited sources. Lklundin ( talk) 06:40, 13 January 2016 (UTC)
Therefore "software entropy" must be at least indirectly related to Entropy (information theory).
The concept of software entropy has been poorly defined in this article and elsewhere. It contains a number of half/un-truths. aphorisms make for poor axioms. Statements like "a computer program that is used will be modified" do not add any value to this page, and "when a program is modified, its complexity will increase, provided that one does not actively work against this" is simply not true. Refactorings and deletions may in fact reduce complexity and there is no relationship between complexity and entropy.
If this topic bears any relationship to the [second law of thermal dynamics], then it logically MUST be derived from [information theory]. Jacobson et al, were not rigorous in their definition of software entropy and should not be quoted here for the purpose of defining software entropy. Referenced perhaps, for the purpose of establishing that the trade has used the term, at at least loosely, as far back as 1992.
I think software rot/decay is more like what we mean by entropy, wrt to software. That article is also better written and would be improved if it did not link to this awful definition of software entropy.