Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

On TMTOWTDIness

by blazar (Canon)
on May 16, 2007 at 10:44 UTC ( #615737=perlmeditation: print w/replies, xml ) Need Help??

This is a mini-meditation I often felt the need to make, and I probably touched upon the subject several times. Actually, this is taken from a clpmisc post of mine (link @ GG) the relevat portion of which I'm reporting here.

Somebody, in an earlier post, wrote:

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.

My reply is as follows:

Well, you're right. However there's a remark I always feel like making when speaking of Perl's TMTOWTDIness: it's true that there's more than one way to do it. But it's also true that for common situations there is often a preferred way to do it. Or a few preferred ways, with different advantages in different respects. So, if you have e.g. to iterate over a range of numbers "the" WTDI is

for ($MIN..$MAX) { # ...

and if you have to iterate over a handle, then "the" WTDI is

while (<$fh>) { # ...

Please take all this with a grain of salt, of course.

Perl 6 aims at being even more multiparadigmatic than 5, and to stay at the same time consistent. So thanks to lazy evaluation, you will e.g. both

.say for 1..6; # and .say for =$fh;

Further comments:

  • Charlton Wilbur's - More concisely: TMTOWTDI, but some ways are better than others.
  • Tad McClellan's - More humorously: There are 9 ways to do the same thing in Perl, and 8 of them are no good!

Replies are listed 'Best First'.
Re: On TMTOWTDIness
by shmem (Chancellor) on May 16, 2007 at 12:25 UTC
    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...

    --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}
      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}
Re: On TMTOWTDIness
by syphilis (Bishop) on May 16, 2007 at 11:33 UTC
    It might be stating the obvious, but I've always been keenly aware that, without TMTOWTDIness, we would never have to ponder the question "Is there a better way to do it ?"

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

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

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

Re: On TMTOWTDIness
by samizdat (Vicar) on May 16, 2007 at 14:29 UTC
    Marvelous and inspiring thread, blazar :)

    I don't think there's any language except perhaps C which is as flexible, and I'd get a lot of agreement that C doesn't come close. Perl syntax is incredibly loose and allows some really elegant ways of expressing algorithms that just aren't available in other languages. To me, it's amazing how flexible this bear is as she dances so gracefully!

    One reason I've always stayed away from C++ is that it seeems to me that there are several distinct paradigms for C++ programming, and mixing them gets you into more trouble than you can generally handle. In Perl, by contrast, mixing and matching seems much more encouraged. To be more specific, I'm referring to STL-oriented C++ versus OO C++ versus C-like C++. Perhaps it's my own hesitancy that's my enemy. =8*O

    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. I'm not very courageous in my expressive idioms -- my code isn't as bad as BASIC, but it does show assembler roots -- but I sure find lots of encouragement here to push my envelope further each and every time I build a new script.

    Don Wilde
    "There's more than one level to any answer."
      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."
Re: On TMTOWTDIness
by jdporter (Canon) on May 16, 2007 at 14:24 UTC
    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.

    A word spoken in Mind will reach its own level, in the objective world, by its own weight
      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! ;-)

Re: On TMTOWTDIness
by ruoso (Curate) on May 17, 2007 at 11:44 UTC

    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?

    daniel

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://615737]
Approved by jettero
Front-paged by TStanley
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (3)
As of 2019-08-22 05:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?