Versalitily isn't always a good thing. This might be stretching the realms of funky Perl code, but consider the following two programs that will add two numbers.

Adding two numbers is a silly example to discuss the benefits and drawbacks of TIMTOWTDIness, as can be seen in the highly silly thread Adding 2 + 2. There are not many ways to raise from bed, and I guess there are some that are highly dangerous and even lethal. But that's not the point, TIMTOWTDI isn't so much about atomic operations, it is rather about routes through a problem domain.

A metaphor might serve - let's take WTDI as ways to get to B from A.

The way from the city hall to the main station might be always the same One Best, if the hall and station are at the same straight road suitable equally for pedestrians, skateboarders, cyclists, car drivers, those riding a bus and disabled people, be any of them a local or a foreigner. But with a somewhat interesting city plan, those ways are different, and what is best for one might be unsuitable for the other.

The fastest way may be unorthogonal, with many twists and bendings through the medieval town, hard to describe and hard to remember, but for a local pedestrian it's the obvious one. A foreigner might be told to follow the signposts, or just to "take the bus" (use a CPAN Module).

Perl provides walking sticks, skate boards, bycicles, cars, buses, and different maps for different purposes. Oh, and there are some very good cab drivers around :-) The drawback is - you have to learn by experience which vehicle does what, and what map is appropriate for each.

So there's no best way, but rather multiple ways, each suitable for a different skill and constraint set; but the best about TIMTOWTDI is - at every stage there are more ways to discover, even for locals.

updated several times, tweaked wording, formatting, speling etc...

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Adding two numbers is a silly example to discuss the benefits and drawbacks of TIMTOWTDIness, as can be seen in the highly silly thread Adding 2 + 2. There are not many ways to raise from bed, and I guess there are some that are highly dangerous and even lethal.

Yep, this is certainly so. I just pointed out that particular idea of mine in the context of that discussion, but it may have sprung out quite about anywhere.

But that's not the point, TIMTOWTDI isn't so much about atomic operations, it is rather about routes through a problem domain.

Interesting point: thank you for your contribution, since this is exactly the kind of feedback I expected for this thread. However I think that TIMTOWTDIness manifests itself at all levels and scales in Perl. For example one should compare with the other language, the one which follows exactly the opposite philosophy, and notice that there -I have been told- some specific bits of syntax and semantics were removed because they provided alternative WTDI! Of course on this I'd like to hear His TimToadyness himself, but I suppose he has better things to do...

Perl provides walking sticks, skate boards, bycicles, cars, buses, and different maps for different purposes.

Oh no! I'm quite confident there's only one map. ;-)

First, I must confess - my metaphor was qw(inspired stolen)[rand 2] by/from Larry, out of an interview he gave, where he said something about orthogonality and travel. The "raising from bed" picture is mine :-)

That aside, of course at all levels and scales. But! One reason to whack perl has been the TIMTOWTDIness at low level IMHO, which is why I said "not so much". People that like to bash perl (pun intended) often pick such examples of TIMTOWTDIness that are slightly silly if isolated out of context (but there's more about expressiveness of a language than the pronounciation of "a" in its various dialects (in fact, even in a single dialect, there are many meanings; I can think of at least nine different of "a" in the dialect spoken here in south-west germany (but that varies even from town to town))) - and they tend to stay nitpicking there.

"Okay", I say, "fact is, you can speak, as your tongue is grown. Let's look at the bigger picture."

Then they skip the level I've spoken of in my previous post, and begin with "enterprise readiness", "industrial standards", "SLAs", "wholesale support" and that crap... *sigh*. I'll better stop here.

</rant>

On His TimToadyness commenting - you've done a good job to warrant that, sticking a key word in the title... ;-)

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Just think of all the time that would be saved ;-)

Yep! But then how 'bout the fun?!? ;-)

I don't think there's any language except perhaps C which is as flexible
...
I think there's a lot to be said for looking at other code, and the Monastery provides an entertaining gateway into the insights of others that no other community website brings forth.

You name it. Since you have assembler roots, you will surely have heard of FORTH, a language that seems forgotten but is still very alive and kicking :-)

It allows mixing of interpretation and compilation state, it is interactive as well as compiled, implemented both in software and in hardware - it is arguably more flexible than C.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Indeed I have, and waaaay back in '86 I worked with a visual inspection platform whose recognizer was built in FORTH. Awesome stuff.

FORTH's flexibility is of a different kind, though. Its flexibility coms from its ease of extensibility, not from syntax flexibility. FORTH and LISP have much in common in that respect, but that's a different thread entirely. I would argue that both of those languages are very rigid in their syntax but also very minimal in syntactic requirements. In other words, there's only one way to write them, but lots of ways to extend them. Lots of ways to implement them, too, which is the flexibility you're pointing to.

Don Wilde
"There's more than one level to any answer."

for common situations there is often a preferred way to do it

That is the gist of There's Only One Way To Do It.

That is the gist of There's Only One Way To Do It.

Not feeling like pushing it up to that point, but... interesting reading! "Only One Way through TMTOWTDI", a sorta zen thing! ;-)

I think the entire point on TMTOWTDI is that we couldn't know which is a Best Practice without knowing the possibilities. Perl is a human language in this sense, with different accents, dialets...

The big thing here is that even if from the 9 ways of doing something, 8 of them are no good, this means that this was a cultural learning about ourselves more than about the language itself.

Consider object orientation. How many dialets are in that field in CPAN? Is this good? Well, some of them become more standard, some of them just is almost never used, some of them become the Bast Practice (as of DBI, DBIx::Class, TT).

Just to think about: Could "Perl Best Practices" be written without TMTOWTDI? Could Perl be better than the today's known Best Practices without the cultural evaluation of the choices?