Talk:David Parnas

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Biography / Science and Academia (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Biography, a collaborative effort to create, develop and organize Wikipedia's articles about people. All interested editors are invited to join the project and contribute to the discussion. For instructions on how to use this banner, please refer to the documentation.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
Taskforce icon
This article is supported by the science and academia work group (marked as Low-importance).
WikiProject Ireland (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Ireland, a collaborative effort to improve the coverage of Ireland on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.

Technical Realism[edit]

Would anyone be so kind as to explain what "technical realism" means in this instance?

Cohesion and Coupling[edit]

Parnas is often credited with introducing these concepts, but I've just gone back to the classic 1972 ACM and these concepts, while implicit, are not explicitly mentioned.--RichardVeryard 09:53, 28 September 2006 (UTC)

A review of the ACM Digital Library uncovers a single instance in all of Parnas's writing [Parnas, Schouwen, and Kwan. "Evaluation of safety-critical software," CACM, 33 (6), June 1990] where he used the terms coupling or cohesion--in that instance without attribution. If he is "often credited" where and by whom?Stirrer (talk) 18:18, 18 November 2007 (UTC)

The metrics of coupling and cohesion were originally proposed by Larry Constantine as correctly referred in Coupling_(computer_science). David Parnas did not contribute directly or indirectly to these metrics. The original reference is the seminal 1974 IBM Systems Journal paper Structured Design, which describes nearly 10 years of pioneering research by Larry Constantine. The ideas behind Coupling and Cohesion were initially published in "Segmentation and Design Strategies for Modular Programming." In Barnett and Constantine (eds.), Modular Programming: Proceedings of a National Symposium. Cambridge, MA: Information & Systems Press, 1968 and “The Programming Profession, Programming Theory, and Programming Education,” Computers and Automation 17, 2 (Feb. 1968) pp. 14-19. —Preceding unsigned comment added by (talk) 08:40, 19 November 2007 (UTC)

Information Hiding not being mentioned by Parnas[edit]

Contrary to what is stated in the references section, Parnas mentions information hiding in his 1972 ACM article on page 1056 (bottom left) and he refers to himself: Parnas, D. L. Information distribution aspects of design methodology. Tech. Rept., Depart. Computer Science, Carnegie-Mellon U., Pittsburgh, Pa., 1971. Also Presented at the IFIP Congress 1971, Ljubljana, Yugoslavia. - However, I was not able to obtain a copy of that article, but nevertheless, information hiding is mentioned by Parnas in his 1972 ACM article. —Preceding unsigned comment added by (talk) 13:36, 27 March 2009 (UTC)

Software Cost Reduction Project[edit]

I think this entry should say something about Parnas's participation in the U.S. Navy's Software Cost Reduction project. I actually came here to look for a reference to an example of the SCR's diagrams for specifying requirements. (See Heitmeyer (2007) "Formal Methods for Specifying, Validating, and Verifying Requirements".) (talk) 14:52, 24 May 2011 (UTC) --RLV

Quotations out of context are not a good idea in any article.[edit]

David Parnas is an important researcher, one part of this wikipedia entry, refers to flow-charts against structured programming, because a confusion common in those days.

Structured programming was wrongly taken by many people as programming without GOTOs, because an anecdote about the change of title of the GOTO considered harmful written by E.W.Dijstra, but renamed by N.Wirth (the author of Pascal,Modula, Step wise refinement, programs=data structures + algorithms, etc.)

Structured programming is basically programming by composing (reusable) parts on the basis of a mathematical structure. Data types are mathematical structures, programming structures too. Like deriving theorems from axioms.

Data-flow diagrams do not encourage an structured thinking, the introduction of "structured languages", (i.e. languages with assignment, if-then-else, while, for-next, repeat-until, and subroutines, making much more less use of GOTOs). Did not automatically solved the problem, take into account that the predominant languages of those days used floats, integers, characters, strings, arrays and records in some languages like COBOL. (this before Pascal, Algol existed but was not very known to business applications programmers)

Artificial intelligence on those days was very experimental and the quotation based on cite 4 where Parnas said that Turing Machines and Gödel theorems where irrelevant, could be because many people on those days argued that IA research where looking for impossible goals due to the incompleteness theorem. I could not download the document, the date of the original publication is also omitted.

Turing Machines originated by an engineering thought on how an human computer worked at those days, using the minimal elements. The Universal Turing Machine was the basis for the stored program computer. John Von Neumann new Turing. The famous Gödel theorems are related to arithmetic, and Recursive Functions (a class of functions, mathematical systems, not the simple use of the word to denote a program that calls it self) Seen in that way, I do not believe that Parnas ignored that. But the quotation based on citation 4 seems to be out of context, mixing a his opinion on the AI research with Software Engineering.

For that reason, I think that the quotations are out of context, and should be removed.