There is more than one way to do it. This phrase is often associated with the PerlLanguage.  Unlike other languages (notably Scheme), Perl intentionally contains many simple expressions that are equivalent in result.  Its inventor, LarryWall, is trained as a linguist.  He has this crazy notion that sometimes phrasing a sentence differently might make its meaning clearer...

See http://www.perl.com/pub/1999/03/pm.html to be confused far enough that you might actually understand. LarryWall's book ''ProgrammingPerl'' says TimTowTdi many many times.

(Is the WikiWikiWeb PostModern?)

Just don't assume that because ThereIsMoreThanOneWayToDoIt that YouShouldDoItEveryWhichWay. There is usually a *good* way to do it, which was the point of creating a language with such power and flexibility as Perl. Larry Wall was ostensibly, from what I have read, hoping that there would always be at least one great way to say anything that needed to be said. Not that programmers would say stuff any old way and become more and more cryptic to the point of not being able to read their own code. -- JeffBay

''Sure, just as in English there is one'' good ''way to say something. Right?''

In English there is one best way to express a particular idea ''to a particular audience''. Since code is aimed at a compiler or interpreter and the "other" audience is the maintainers, the code [idea] may not be expressed in the form they [the maintainers] find best. Oh, well. There's probably a point here, but I've already lost interest in it.
----
Usually abbreviated as TIMTOWTDI, but acronyms don't work well as WikiNames. (Doesn't stop some people from trying, see TimTowTdi.)

TIMTOWTDI is a two-edged sword.  On one hand, to quote Tim Cuffel in news:comp.lang.perl.misc, it "often means there is more than one really bad way to do it."  On the other hand, it increases the chance that there is at least one really good and elegant way too.  -- IlmariKaronen
----
But there's also more than one way to do it in Scheme: a classic example is implementing a pair in scheme, with operations left and right to get the left and right part, respectively.

Cons-cell-based:
 (define pair cons)
 (define left car)
 (define right cdr)

Vector based:
 (define pair vector)
 (define (left x) (vector-ref x 0))
 (define (right x) (vector-ref x 1))

Closure based:
 (define (pair x y) (lambda (c) (if c x y)))
 (define (left p) (p #t))
 (define (right p) (p #f))

And a whole lot of other options (including using an object system and make a pair into an object).

''...and this is different from any of a zillion other languages how?''

Perl (for example) gives you more than one syntax which have similar operations.  Scheme is a language which allows you to define your own syntax.  Python, in contrast, has a pre-defined, minimal syntax.  Perl makes it very easy to "do it more than one way".  Scheme makes it possible to "do it more than one way".  Python gives you minimal ways.  (I am not the author of the above scheme code.  Is my interpretation correct?)
----
''No language in widespread use completely specifies how tasks must be performed. ThereIsMoreThanOneWayToDoIt in all of them, usually it is just not stated explicitly (which makes a difference, since it influences the language's culture). One common example is loops: ''while'', ''until'' and ''for'' are interchangeable most of the time, sometimes with an additional ''if''. ''

''If you want to get pedantic about it, ThereIsMoreThanOneWayToDoIt already if you are allowed to use different variable names.''

True. IMHO most of the time it just comes down to style, which is a matter of taste.  And many languages give you nearly as much freedom as Perl does, including YourFavoriteLanguage.  Think about it: Are you not already faced with the decision of whether to write

	if ( someHideouslyLongMethodCall( arg1, arg2, arg3 ) ) {

	if( someHideouslyLongMethodCall (arg1,arg2,arg3) )
	{

	if ( someHideouslyLongMethodCall( arg1,
					arg2,
					arg3 ) ) {

	if ( someHideouslyLongMethodCall( arg1,
					arg2,
					arg3 )
	) {

	if ( someHideouslyLongMethodCall(
		arg1,
		arg2,
		arg3 )
	) {


	if (
	someHideouslyLongMethodCall(
		arg1,
		arg2,
		arg3
	)
	) {

Etc., etc.?  (If you say you use a language which doesn't even permit the above-illustrated kind of choice to be made, I certainly wouldn't want to use that language, because I certainly don't agree with the language author as to what the best style is. :-)

-- JohnDouglasPorter
----
I don't like ThereIsMoreThanOneWayToDoIt.  In fact, I hate it from the bottom of my heart, and it's my belief that it's the root of all evil.  There should only be one way to do it.  One obvious way, anyway.  I find that having to choose between similar methods just for the sake of choosing is pointless and just takes lots of energy.  You should be allowed to do it differently if you really need to, but those cases are exceptions.  Thus, I propose "timtowtdi" to be added as a new keyword to all but one member of each set of synonymous constructs.  -- DanielBrockman

P.S. Please note that I'm talking in the abstract, and certainly not about Perl. ;-)

''I think the point is to use the '''first''' way that occurs to you. Often this will be the SimplestThingThatCouldPossiblyWork, and any given programmer will probably be fairly consistent. DoNotWasteTimeOnIrrelevantDecisions. -- KarlKnechtel''
----
"There should be one -- and preferably only one -- obvious way to do it." ("Although that way may not be obvious at first unless you're Dutch."). -- TheZenOfPython

''Yah, sure. You betcha.''
----
Check this: http://www.kasei.com/talks/TIMTOWTDI-Nightmare.pdf

"TAFTMWTDI: There are far too many ways to do it"

"TIOORWTDIM: There is only one right way to do it: mine!"

"TIABWTDI: There is a better way to do it!"

and so on...

Some good points:

"Why is it a nightmare? Because it is simultaneously good and bad...

GoodThing TIMTOWTDI:
* encourages creativity
* reduces the learning time
* easy to port from other languages
* solution fits the problem
* solution fits the solver

BadThing TIMTOWTDI:
* encourages creativity
* increases the learning time
** (maintainer needs to learn every way it is done)
* hard to port to other languages
* easy to write rubbish
* may not be the best solution for the problem
* requires the programmer to make meaningless choices
* makes different code look different
* makes ''same'' code look different
** a.k.a. "You don't do it like that, you do it like this ..."

----

I wrote about the "Paradox of choice" created by TIMTOWTDI at http://wiki.dandascalescu.com/essays/paradox-of-choice-in-web-development
-- DanDascalescu

Easy way to see if your WayToDoIt is a good one:
Ask yourself:  Is what my code does more obvious?
If not:  Does it make my code look more human?
Example (in perl)
	if (not flaky_operation()){
	 die;
	}
vs.
	flaky_operation() or die;
vs.
	die unless flaky_operation();

Now, which WTDI looks better?

''Define "better".''

They're all wrong.  It should be
    flaky_operation();
which should throw an exception, instead of returning false, if failing at it is so often a fatal error.
If I had to choose, though, I would put

    flaky_operation() or die "$!" # this style of die() gives me an explicit debug.

because that's the style that I need to use for flaky_operation()s with meaningful return values:

    with (open("File.txt") or die "$!")
It also seems the most clear to me:  die unless flaky_operation() seems to imply that flaky_operation hardly ever succeeds, and if( not flaky_operation) ... is too much typing, but flaky_operation() or die implies all-or-nothing.
-------
It's interesting reading about the strategies of top WWI and WWII air aces. Their techniques vary widely. The trick seems to be to master a given technique that fits one's ability profile. Some pilots used circus-like maneuvers to sneak up and then get away, while some were patient, careful, and accurate.  Some shot at close range, some far, etc.

But that is a different issue; as a fighter pilot you have to outwit your enemies or die. Writing code isn't about outwitting your reader (unless you're in for obfuscated code contest). Fighter pilots would have to vary their combat tactics from time to time and surprise the unexpecting enemy; codes shouldn't be doing anything surprising. 
-----
See also: WhenAreStandardsRestrictive, NonOrthogonalLanguageFeatures