Why does perl allow so many different ways of doing essentially the same thing?
in [Perl]
|
Prev: FAQ 6.16 How can I do approximate matching?
Next: FAQ 4.4 Does Perl have a round() function? What about ceil() and floor()? Trig functions?
From: Chris Nehren on 10 Jun 2010 06:00 On 2010-06-10, Peng Yu scribbled these curious markings: > On Jun 9, 12:18 pm, Charlton Wilbur <cwil...(a)chromatico.net> wrote: >> Other languages' cultures prefer that there be one correct way to do >> things; if that's what you prefer, then you'll probably be happier with >> another language. > > According to Programming Perl, more than one way may not always be > better. But I just don't see more than one way is better at all. Indeed, the multitude of ways to do things can be--like anything else in life--problematic as well as beneficial (imagine that!). To that end, the EPO (Enlightened Perl Organization: http://enlightened.perl.org)'s Extended Core movement has adopted the phrase TIMTOWTDIBSCINABTE (pronounced 'Tim Toady Bicarbonate') There Is More Than One Way To Do It, But Sometimes Consistency Is Not A Bad Thing Either. See http://www.dev411.com/blog/2009/01/24/can-epo-or-tpf-tame-timtowtdi and irc.perl.org/#epo for more info. -- Thanks and best regards, Chris Nehren
From: Peng Yu on 11 Jun 2010 05:55 On Jun 10, 10:14 am, Charlton Wilbur <cwil...(a)chromatico.net> wrote: > >>>>> "PY" == Peng Yu <pengyu...(a)gmail.com> writes: > > PY> According to Programming Perl, more than one way may not always > PY> be better. But I just don't see more than one way is better at > PY> all. > > comp.lang.python is over there; comp.lang.java is down the hall; > comp.lang.ruby is between the two of them; and comp.lang.c++ is on the > other side. > > PY> In this sense, there were a subroutine that can read multiple > PY> lines from a file. There is no need that the users should > PY> understand the different ways of reading muliple lines as > PY> discussed in other thread mentioned the original post. > > Ah, but the reason there are multiple ways to do things is because the > choice of which way to do things depends on the context. > > The best way to read *three* lines from a file is not the best way to > read *ten thousand* lines from a file. Instead of mandating one way, > the Perl philosophy is to assume that you're a competent programmer who > can judge the quality of various solutions for yourself. Rather than being hypothetically saying there are different ways of coding for different parameter values. I'd like to see what the best code is for reading three lines and what is the best code is for reading 10000 lines? And I would like to know how much time and effort it would require to know the different between the different code and how much actually difference (say in performance or whatever metrics) can be gained by careful choosing different ways. > If you're a competent programmer, this is a benefit, because *you* get > to decide what the best solution is. If you're an incompetent > programmer, this is a burden, because it requires you to think > critically about what you're doing, and (as the hypothetical "you" is > incompetent) you'll probably get it wrong anyway. > > And if you find that that last bit is too much of a burden, well, if you > found Perl, you can find Python, C++, Ruby, or Java. > > Charlton > > -- > Charlton Wilbur > cwil...(a)chromatico.net
From: Peng Yu on 11 Jun 2010 06:11 On Jun 10, 8:32 am, Ted Zlatanov <t...(a)lifelogs.com> wrote: > On Wed, 09 Jun 2010 12:15:18 -0500 John Bokma <j...(a)castleamber.com> wrote: > > JB> Peng Yu <pengyu...(a)gmail.com> writes: > > >> I know some justification that people could choose whatever style they > >> want if there are multiple ways of doing the same thing. But this > >> justification is not convincing to me, considering that it may cause > >> the code not readable and cause many maintenance issues. > > JB> Even if a language has a limited number of keywords and ways to do > JB> things there are still a huge number of ways to implement an > JB> algorithm. If in doubt, check out Python. Or better, repost the "how to > JB> read the first 3 lines of a file" question in comp.lang.python, grab > JB> some popcorn, sit back, and watch the drama unfold :-). > > I think Peng Yu is asking for something like List::Utils but more > general. It's not a terrible idea; Simple::Perl (analogous to > Modern::Perl) could be useful to beginners and could even be a way to > teach efficient Perl (through an option to show the generated code). It > would certainly be better than a DSL. Another parallel is the Template > Toolkit, which has lots of primitives that make writing raw Perl less > necessary. Yes. Essentially this is what I'm asking. > But deciding what will be in the API is a very hard task, and > implementing it will be no easier. Agreed. I think this is a more important problem than figuring out how many ways of programming there are and choosing the best one out of them, in the sense that once such choice has been figured out in a given context, then just package it into an API then people don't have to worry about it in the future.
From: ccc31807 on 11 Jun 2010 08:53 On Jun 11, 5:55 am, Peng Yu <pengyu...(a)gmail.com> wrote: > And I would like to know how much time and effort it would require to > know the different between the different code and how much actually > difference (say in performance or whatever metrics) can be gained by > careful choosing different ways. Let's suppose you need to extract some values from a string. Off the top of my head, I can think of four ways that I have used this week. Other will undoubtedly know other ways. - C programmers would naturally tend to use substr(). - Perlistas would probably tend to use a regular expression. - parse_line() from Text::ParseWord is very handy - split() is also good Which of these is 'best' depends on the particular job you want to do. For example, if you want the first four characters of the string, use substr(); if you want to break the line on a tokes (such as a space), use split(); if it's a delimited string, use parse_line(); and if you have to extract values based on arbitrary delimiters, a RE will serve you well. Now, as a competent programmer, you would know how these work, when to use them, and the benefits and costs of each. Do you really think this is a waste of time and effort? If you wanted to decompose your tasks into many, similar categories, and propose a tool for each different category, you could do that, it it strikes me that doing so would have greater costs and fewer benefits than learning several tools and when to use them. To get to my workplace, I can take a divided, limited access road which has few stops and a higher speed limit, but which tends to be gridlocked at particular times. Or, I can take back streets, which have lots of stops and turns and lower speed limits, but very little traffic. Which one I take largely depends on the time of day I'm going to work or coming home -- I generally choose the faster way. Do you really think it a waste of time and effort to explore the different routes to my work place? Why should I be compelled to pick one 'best' way and forgo all the others? CC
From: Peng Yu on 11 Jun 2010 10:54
On Jun 11, 7:53 am, ccc31807 <carte...(a)gmail.com> wrote: > On Jun 11, 5:55 am, Peng Yu <pengyu...(a)gmail.com> wrote: > > > And I would like to know how much time and effort it would require to > > know the different between the different code and how much actually > > difference (say in performance or whatever metrics) can be gained by > > careful choosing different ways. > > Let's suppose you need to extract some values from a string. Off the > top of my head, I can think of four ways that I have used this week. > Other will undoubtedly know other ways. > - C programmers would naturally tend to use substr(). > - Perlistas would probably tend to use a regular expression. > - parse_line() from Text::ParseWord is very handy > - split() is also good > > Which of these is 'best' depends on the particular job you want to do. > For example, if you want the first four characters of the string, use > substr(); if you want to break the line on a tokes (such as a space), > use split(); if it's a delimited string, use parse_line(); and if you > have to extract values based on arbitrary delimiters, a RE will serve > you well. > > Now, as a competent programmer, you would know how these work, when to > use them, and the benefits and costs of each. Do you really think this > is a waste of time and effort? If you wanted to decompose your tasks > into many, similar categories, and propose a tool for each different > category, you could do that, it it strikes me that doing so would have > greater costs and fewer benefits than learning several tools and when > to use them. > > To get to my workplace, I can take a divided, limited access road > which has few stops and a higher speed limit, but which tends to be > gridlocked at particular times. Or, I can take back streets, which > have lots of stops and turns and lower speed limits, but very little > traffic. Which one I take largely depends on the time of day I'm going > to work or coming home -- I generally choose the faster way. > > Do you really think it a waste of time and effort to explore the > different routes to my work place? Why should I be compelled to pick > one 'best' way and forgo all the others? I think that we are talking pass each other. The examples that you raise all can be encapsulated into different subroutines. I have no problem that all the possible ways that you mentioned should be known, because they are different things in terms of what they do. To be clear what I mean, let's take some examples from the read a few line thread. These different code essentially does the something (i.e, read line by line). The difference is how the same thing (read line by line) is expressed. Is really important to be able to expression the same thing in different ways? Is there any big performance difference (or anything at all) between different code? One drawback of having different way of expression to do the same thing like this is that it make the source code hard to be analyzed (suppose, e.g., people want to study source to discover some redundant code and do re-factoring). my @lines; my $limit = 3; for my $line(0..$limit-1) { $lines[$line] = <IN> } ####or my @lines; push @lines, <IN> for 0..2; #####or my @lines = map <IN>, 0..2; ###or for (my $i = 0; $i < 3; $i++) { push @lines, <IN>; } ####or my @lines; while (<>) { push @lines,$_ if($.<4) } |