Prev: FAQ 4.4 Does Perl have a round() function? What about ceil() and floor()? Trig functions?
Next: FAQ 9.2 My CGI script runs from the command line but not the browser. (500 Server Error)
From: Steve C on 9 Jun 2010 15:54 Peng Yu wrote: > The following thread shows many ways of reading a given number of > lines. > > http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/478db847f15ce016/fe47580f819866cb?lnk=gst&q=pengyu.ut#fe47580f819866cb > > But I doubt that having multiple ways of doing the same thing really > give us any advantages over other languages. Essentially this can be > encapsulate in a subroutine, which is easy for refactoring and code > transformation. > > Although, there might be advantages in other scenario to have multiple > ways of doing the same thing. But I don't think it is the case for the > particular question. > > 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. > > Is there any study with concrete data demonstrates how this multiple- > way-of-doing-the-same-thing philosophy actually can help programmer > improve productivity? > Suppose in one case you need to read exactly four lines, and in a different case you need to read 100 million lines. Would you want to use a language that required you to do both the same way? There are multiple ways to do any interesting programming task in every language. It's not a weakness and it isn't just about productivity. It's more about flexibility.
From: Xho Jingleheimerschmidt on 9 Jun 2010 22:54 Peng Yu wrote: > The following thread shows many ways of reading a given number of > lines. > > http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/478db847f15ce016/fe47580f819866cb?lnk=gst&q=pengyu.ut#fe47580f819866cb > > But I doubt that having multiple ways of doing the same thing really > give us any advantages over other languages. You seem to be implying that other languages don't have multiple ways of doing the same thing. > Essentially this can be > encapsulate in a subroutine, which is easy for refactoring and code > transformation. Sure. We can make a subroutine read_3_lines, and use that subroutine whenever we need to read three lines. But now, one of the places that used that subroutine now needs to read 4 lines. Do we change the subroutine read_3_lines so that it now reads 4 lines, or do we create a new subroutine named read_4_lines? Should we also have subroutines names add_1, add_2, add_3, multiple_by_2, multiply_by_3, etc.? > Although, there might be advantages in other scenario to have multiple > ways of doing the same thing. But I don't think it is the case for the > particular question. Well then do don't use do it in multiple ways for that particular question. Geez. > 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. Perhaps you aren't cut out for Perl. > Is there any study with concrete data demonstrates how this multiple- > way-of-doing-the-same-thing philosophy actually can help programmer > improve productivity? No, we are far too busy being productive to bother with wankery like that. Xho
From: Dr.Ruud on 11 Jun 2010 20:36
Peng Yu wrote: > The following thread shows many ways of reading a given number of > lines. > > http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/478db847f15ce016/fe47580f819866cb?lnk=gst&q=pengyu.ut#fe47580f819866cb > > But I doubt that having multiple ways of doing the same thing really > give us any advantages over other languages. Who is your "us"? > Essentially this can be > encapsulate in a subroutine, which is easy for refactoring and code > transformation. Indeed, and in Perl, such subroutines are easy to write. Many of them are already written, see CPAN. > Is there any study with concrete data demonstrates how this multiple- > way-of-doing-the-same-thing philosophy actually can help programmer > improve productivity? I have no idea what you try to mean by that. Most reasonable people tend to reuse and follow what others already did, and build on from there. -- Ruud |