From: Steve C on
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
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
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