Talk:Wirth's law

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Wirth's law article.

Article policies

Contents

[edit] Origin of the law

In the article on Niklaus Wirth, it says:

In 1995, he popularized the adage now known as Wirth's law: "Software gets slower faster than hardware gets faster", although in his 1995 paper A Plea for Lean Software he attributes it to Martin Reiser.[1]

  1. ^ Niklaus Wirth (February 1995). "A Plea for Lean Software". Computer 28 (2): pp. 64-68. 

Should this citation be in this article as well? --Dennette 19:48, 13 January 2007 (UTC)

[edit] I serious doubt this is not POVed or sophismatic

programmers are further and further divorced from the machine and closer and closer to the software user's needs
The software bloat comes from providing a ready solution for every conceivable problem that a computer operator might need solved
This implies that our society is becoming more integrated and able to take advantage of technology, increasing efficiency and productivity in the global economy. Thus Wirth's law being true, does not necessarily indicate that value has been mysteriously lost in modern software. It does indicate that there is room for improvement.


signed: KSM-2501ZX, IP address:= 200.155.188.7 15:34, 5 August 2007 (UTC)

[edit] Societal implications?

"This implies that our society is becoming more integrated and able to take advantage of technology, increasing efficiency and productivity in the global economy. Thus Wirth's law being true does not necessarily indicate that value has been mysteriously lost in modern software. It does indicate that there is room for improvement."

I'm not sure there's any implication period, let alone one about the "integratedness of society". But the second part about some other value (application integration, inter-software communication overhead, &c.) being unrepresented in the Law's focus on "speed" is important. jsled 03:49, 19 September 2007 (UTC)

[edit] references

I've replaced several fact tags in this article. This article is completely unreferenced; the single reference provided (The School Of Niklaus Wirth, which I'll call "TSoNW") has no index, though I've thumbed through my copy searching for any statement of this "law". The book isn't written by Wirth; it is a collection of papers about Wirth and his works. One of the papers (about 10 of the book's 260 pages) was written by Wirth himself.

I'm directly questioning the validity of the article, as I can't find anything to substantiate that Wirth put any of this together. Further, I don't think we can call this a "law"; it's obviously just an observation and not a law in any legal or scientific sense. Further, there are several assertions in the article which are unreferenced. I had marked these with {{fact}} tags, but they were removed with the comment that "a citation on Wirth having said this will be sufficient". I disagree with this comment factually and semantically. The article states that "sometimes programmers even rely on Moore's law to justify writing slow code", but it presents this as an unconditional fact; it does not say that Wirth said it, or used it as a supposition in developing his so-called "law". If these statements are what Wirth said, then they should be attributed to him as quotes, not provided in the article as global truths.

It's not too hard to find attributions in literature referencing this "law", but I can find nothing which tells us that Wirth said it, or explains his basis for calling it a law. -- Mikeblas (talk) 23:09, 13 April 2008 (UTC)

It is called a law because it is commonly referred to as such, in the same sense that Moore's law, or Murphy's law. I have added a couple of citations. The matter of writing slow code is an unconditional fact, though may be mentioned in the article. High level languages, garbage collection, P-Code, etc. all cut execution efficiency to reduce programming effort. A commonplace observation, but citations could undoubtedly be found. Zodon (talk) 01:26, 18 April 2008 (UTC)