Talk:Principle of least astonishment
|This is the talk page for discussing improvements to the Principle of least astonishment article.
This is not a forum for general discussion of the article's subject.
|WikiProject Computing||(Rated Start-class, Low-importance)|
|WikiProject Philosophy||(Rated Start-class, Low-importance)|
I'm curious about the reasoning behind reverting my examples . I know they weren't great, but the article needed more examples (as has been pointed out on this page), and I hoped they could at least be refined (cut down in length, made more to the point, more coherent, etc.) rather than deleted entirely. If there were severe factual inaccuracies or misunderstandings then could someone please tell me where I went wrong or suggest ways to improve my understanding of the topic? Also, the edit reason included the term "fmt", which I can't find any meaning for. Is it some kind of wikipedia-specific shorthand? EDIT: forgot to sign in. Psudomorph (talk) 18:22, 10 December 2008 (UTC)
Almost every single reference I have seen to this principle calls it the "Principle of Least Surprise". In particular, Ruby internals developers, ESR, and the Pragmatic Programmers spring to mind as examples of relatively well known examples of people who know what they're talking about that use the POLS variation. So -- is there some specific reason that this article is the "Principle of Least Astonishment", rather than the "Principle of Least Surprise"? If there is an original formulation that uses that name, thus making it the more formally "correct" term, I'd like to know it.
Perhaps the article should make mention of why POLA is the preferred term in Wikipedia, as opposed to POLS, despite what appears to be a greater frequency of use for POLS.
additional edit: Sorry, I forgot to sign this when I first wrote it. -- Apotheon 06:24, 22 November 2006 (UTC)
- I've never heard it called anything but POLA in my nearly 40 years in the computer business, so I suspect (but cannot prove) that POLA was the first usage. BWB91380 (talk) 03:17, 10 April 2008 (UTC)
- why the lucky stiff created a video series called "The Least Surprised" which is a nod to the Principle of Least Surprise. POLS may be a variant of the term only used in the Ruby community, but as a hardcore Rubyist I can assure you it's the only term a Rubyist would use. No Rubyist says "principle of least astonishment". Tarcieri (talk) 23:27, 27 October 2010 (UTC)
- Well that's an excellent argument for calling it "The Principle of Least Astonishment". Ruby on Rails and its community may be opinionated, but that doesn't mean that all of their opinions are correct. And the Ruby community has a terrible reputation of being full of sexist Brogrammers, so I don't really don't care what terms most Rubyists would use, since so many of them haven't been programming for very long, and Ruby is their first and only programming language. Xardox (talk) 11:14, 29 January 2015 (UTC)
- I've seldom heard it called anything but the Principle of Least Surprise in my nearly 30 years in the computer business (and I've never been involved in the Ruby community). I'd be curious to know if this is a regional thing. BTW, my first experience with the word would have been around 1985 or so, and it was associated entirely with programming-language design. At that time, most people had never seen a graphical user interface. User:Dave Gudeman —Preceding undated comment added 21:30, 17 May 2011 (UTC).
30 years in Computer Science and I've always heard it called POLA, not POLS. I believe my first exposure to it came from the Unix "fortune" program which I'd say is pretty authoritative :-). For a somewhat objective measure, Google gives over twice as many hits for POLA as it does for POLS (both phrases quoted) -- 74900 vs 35600, respectively -- so POLA clearly seems like a better choice for the master article. All that aside, the biggest point in my mind is that this is supposed to be a funny statement of principle (though the current article unfortunately drains the humor from it) -- and POLA is a hell of a lot funnier. 126.96.36.199 (talk) 18:09, 30 July 2012 (UTC)
I thought POLA most commonly referred to the Principle of Least Authority.   Here is a reference from the fortune program.  % Rule of Least Surprise: In interface design, always do the least surprising thing. (aka Principle of Least Astonishment) --esr, The Art of Unix Programming % — Preceding unsigned comment added by 188.8.131.52 (talk) 16:56, 12 September 2016 (UTC)
Removing this note from the article:
TODO: It would be really helpful if there were multiple examples. I'd add, but I don't know any more (which is why I'm asking for them...) MikeSchinkel 04:34, 20 October 2006 (UTC)
Because it clearly belongs here rather than in the article. It doesnt make him less right, though.
Maximum Boredom ??
As far as I can tell, the statement that this is "also known as the principle of maximum boredom", is false. No one calls it that.
The phrase seemed odd, so I googled it, and got zero links outside of wikipedia and its clones. [google search]. Tracing the page histories, it seems to come from the Modified Newtonian Dynamics. The earliest edit on that page (17:20, 20 Nov 2001 Gareth Owen (DON'T use an abbreviation without definition ...)) includes the phrase, although the comment indicates there was probably an earlier version.
Was this an attempt by someone to popularize their pet name for the theory? Is the phrase "Principle of Maximum Boredom" a wikipedia coinage? --Key45 21:55, 15 Nov 2004 (UTC)
I removed "George Polya - How to Solve it - a great wonderful book on heuristics" for being Point-of-View, and also having no link whatsoever for people to see for themselves if it's great and wonderful or not at all ;) --Hooloovoo 02:26, 10 Apr 2005 (UTC)
- This book is well covered in its own article, and as far as I can tell, has nothing to do with this article anyway. --Spalding 02:34, Apr 10, 2005 (UTC)
I am removing this paragraph:
- "In science, the informal principle of least astonishment states that the explanation which is the least astonishing is usually the right one. This can be thought of as an amalgam of Occam's razor and a presumption in favour of current theories."
- The idea that "the explanation which is the least astonishing is usually the right one" is untrue and unscientific. Science is full of counterintuitive discoveries: for example, homeopathy shows that medicine can be made stronger by diluting it, and hormesis shows that an organism can be made healthier by giving it small amounts of certain toxins.
- Even ideas as fundamental as Spherical Earth and centripetal force were astonishing when first discovered. Scientific truths have nothing to do with whether anyone finds them astonishing or not. --Brian Kendig 21:27, 21 Jun 2005 (UTC)
- If you're going to insist that the "principle of least astonishment" is a concept used in science, or that it's also called the "principle of maximum boredom", then please provide some links to places which use it in this context. I still hold that no good scientist would discredit a theory just because it's astonishing; the greatest advances in science have been made by astonishing theories. The quote you gave (a given observation is evidence for a hypothesis if that observation is ... expected ... and an observation is evidence against a hypothesis if that observation would be ... unexpected) is a fundamental part of the scientific method; "astonishment" has nothing to do with it. --Brian Kendig 00:19, 22 Jun 2005 (UTC)
HAHA nice example
This article .. well the example given in it made me laugh out loud..
Programmer in the example is actually put to the question: I can program this macro recording in a way that is desired or a way that is undesired and result in a macro not being recorded... hmmmm which one will astonish the user the least?.....stupid..Is there not a more relavant example ?--Alex 11:43, 30 December 2005 (UTC)
- Best example I can give is from interface design. I've been using word processing programs in GUIs since the late 80's on a Commodore 64 in GeoWorks, and the 2007 redesign of Word for Vista caught me completely by surprise. Instead of a nice set of text menus telling me what options were available, I got a bunch of icons clustered together in conceptual groups, on tabs; that's three levels of organization just to get to a Font Style window.
- This would have simply been about learning new concepts, except that the first time I've had to use the new Word was a challenge exam to earn credit for Intro To Computers (so I wouldn't have to pay tuition and textbook for a class that would teach me stuff I already knew). I spent half my allotted time on Word trying to find the correct shade of green and how to change certain indentation characteristics, then ran out of time on the surprisingly easier portions, Excel and Access, later.
- Long story short, this astonishment / surprise may cost me $200; I don't have the results back yet. --BlueNight (talk) 19:58, 16 December 2010 (UTC)
- How do you know what is desired? You just assume that anyone who presses Ctrl-Q during the recording of a macro wants to record the keystroke. What if someone wants to abort the recording and close down the program, and that is the reason why they are pressing Ctrl-Q? —Preceding unsigned comment added by 184.108.40.206 (talk) 05:20, 11 January 2011 (UTC)
The article does not explain the origin of this phrase or idea. A bit of Googling does not come up with any real explanation. Does anyone know the real story about this? Polpo 17:17, 18 October 2006 (UTC)
- Although I can't explain the origin, I can provide a data point. The first time I heard POLA used was by a computer science instructor at Caltech in c. 1969, which certainly predates Google, the Web, and the Internet (and ties ARPANET). BWB91380 (talk) 03:19, 10 April 2008 (UTC)
So am I the only one who thinks this is an entirely bogus "principle"? What surprises one person is often perfectly expected to another one. In the second example, I'd be quite surprised if I issued a shutdown and the system stayed up (because someone else issued a shutdown concurrently to me and then later canceled it). In this situation there is no behaviour that will not surprise one of the two users.
I'd go so far as to assert that every single example of a true violation of this "principle" (i.e. a situation in which it can be unambiguously established which of two different behaviours is more or less surprising) is simply a bug in the underlying program.
Can anybody name any such situation where we're NOT just talking about a bug? Iron Condor 01:55, 22 May 2007 (UTC)
- I guess I'm not sure what you're saying. A violation of this principle would not usually be a bug as such, as "bug" generally means that the program is not doing what it was intended to do. A violation of the principle would be a program performing faithfully to its design, but providing a confusing interface.
- My favorite example is a convention which I believe was introduced as a feature in early Microsoft Windows, where the spacebar was a keyboard shortcut meaning "repeat the last GUI action". So, if you thought your keyboard focus was in a text window/field but it was not, and you started typing away, the first time you hit space, a seemingly arbitrary, certainly unexpected, and thus astonishing, action would take place.
- (In general, I believe any interface where an unmodified alphanumeric key performs any action other than inserting the character associated with that key is a textbook violation of this principle. And I say that as a decades-long vi user.)--NapoliRoma 05:55, 22 May 2007 (UTC)
- In my experience, the usage of POLA is as NapoliRoma states. It's usually related to design flaws (almost invariablly related to user interfaces) rather than program bugs. In the shutdown case, POLA would dictate that the user who would otherwise be surprised should be notified (i.e., if the design was to shutdown, the user who canceled should be told that another user had a concurrent shutdown request that would be honored; if the design was not to shutdown, the user who didn't cancel should be notified that the shutdown request would not be honored because another user had a concurrent shutdown request that was canceled). BWB91380 (talk) 03:31, 10 April 2008 (UTC)
In the POP system we use at work, you are required to change the status of an order to "issued" before it is paid. There are no clues in the user interface as to how to do this. I've just discovered that you do it by emailing the order to yourself. ...Well, I was damn well astonished. 220.127.116.11 (talk) 11:30, 14 February 2008 (UTC)
You can't just say that one of two actions is more likely to surprise the user. It depends on what it actually is the user wants to do. Also think of the consequences if you (as a programmer) chooses the other alternative.
In the example with recording the Ctrl-Q keystroke in a macro, you could just as well have a user who wants to quit the program while they are halfways through recording a macro (something requires them to close down whatever they are doing). They would then be surprised when they pressed Ctrl-Q (like they are used to) and nothing happens.
In my opinion there is another and way better reason for selecting to record the closedown instead of actually doing a closedown, and that is that the alternative would be cumbersome for the user. It would require anyone who wants to record a closedown action in a macro to enter some editor after having recorded the macro, and then type in whatever command causes the program to close down. With the other alternative both options are available without any additional knowledge. Personally I would always select to record the closedown because of this. I would never even look at which option surprises more users, because to me this is simply the right way of doing it.
[Reply to the above unsigned poster begins here:]
Yes, an interesting paradox... As a technical writer (and thus a professional idiot), here's what I'd suggest:
1. The user, recording a macro, presses Ctrl+Q.
2. A dialog box appears: "You just pressed Ctrl+Q, which usually exits [app name]. What do you want to do?:"
[o] Add Ctrl+Q to the macro. (When you run your macro, it will cause [app name] to exit.)
[o] Ignore Ctrl+Q and continue recording.
[o] Cancel recording and exit [app name].
The first option is selected by default. If the user chooses it, the dialog box appears which prompts the user to save the macro (as the macro can't contain further instructions).
If the user chooses the third option, the app prompts the user to save any unsaved content (as it normally would) before exiting.
And yes, I realize we may be transgressing the scope of this article, but it does concern one of the two examples it cites. Perhaps a more cut-and-dried example would be better? SomeAvailableName (talk) —Preceding undated comment added 19:11, 17 July 2011 (UTC).
You are arguing that this principle is not an absolute. That may be true. However, the phrase is used to express a point of view, even though it may be subject to perspective. In software design this phrase is very common and used to mean 'your design is not simple or does not seem obvious to the uninitiated'. --RobertGary1 (talk) 20:39, 21 May 2012 (UTC)