Why does perl allow so many different ways of doing essentially thesame thing?

Discussion in 'Perl Misc' started by Peng Yu, Jun 9, 2010.

  1. Peng Yu

    Peng Yu Guest

    The following thread shows many ways of reading a given number of
    lines.

    http://groups.google.com/group/comp...819866cb?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?

    Regards,
    Peng
     
    Peng Yu, Jun 9, 2010
    #1
    1. Advertising

  2. Peng Yu

    John Bokma Guest

    Re: Why does perl allow so many different ways of doing essentially the same thing?

    Peng Yu <> 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.


    Even if a language has a limited number of keywords and ways to do
    things there are still a huge number of ways to implement an
    algorithm. If in doubt, check out Python. Or better, repost the "how to
    read the first 3 lines of a file" question in comp.lang.python, grab
    some popcorn, sit back, and watch the drama unfold :).

    --
    John Bokma j3b

    Hacking & Hiking in Mexico - http://johnbokma.com/
    http://castleamber.com/ - Perl & Python Development
     
    John Bokma, Jun 9, 2010
    #2
    1. Advertising

  3. Re: Why does perl allow so many different ways of doing essentially the same thing?

    >>>>> "PY" == Peng Yu <> writes:

    PY> But I doubt that having multiple ways of doing the same thing
    PY> really give us any advantages over other languages.

    The culture in which Perl has developed for the past couple of decades
    embraces "TIMTOWTDI" - "there is more than one way to do it." See the
    entry in the glossary of Programming Perl, 3rd ed., on page 1005.

    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.

    Charlton


    --
    Charlton Wilbur
     
    Charlton Wilbur, Jun 9, 2010
    #3
  4. Peng Yu

    ccc31807 Guest

    Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    On Jun 9, 11:42 am, Peng Yu <> wrote:

    > Is there any study with concrete data demonstrates how this multiple-
    > way-of-doing-the-same-thing philosophy actually can help programmer
    > improve productivity?


    Why ask, 'Why?'

    Why does Python (supposedly) allow only one way to do something? Why
    does C use explicit pointers? Why does Lisp use the same syntax for
    both data and code? Why does Erlang forbid reassignable variables? Why
    does Erlang not provide for shared objects but insist that you only
    use message passing? Why does Java insists that you encapsulate
    everything in a class, even going so far as to insist on a static
    class if all you want to do is write a simple, stand alone script?

    Why are different languages different? Why aren't all languages the
    same?

    Here's my answer, really a meta-answer. Have you ever noticed that
    different tools are different? We have hammers for nails, screw
    drivers for screws, wrenches for nuts and bolts, etc. Why? We have
    Fortran for number crunching, JavaScript for browser apps, COBOL for
    business logic, C for bit-twiddling, PL/SQL for databases, bash for
    shells, and so on. Why?

    Because different tools are optimized for different tasks. Yes, you
    can use a hammer to drive and remove screws, and I've done that. You
    can use a screw driver to drive and remove nails, and I've done that
    as well. But generally, you are better served by using the right tool
    for the job.

    Erlang is optimized for telecom systems, systems that handle large
    amounts of data, are very process intense, that have to be extremely
    reliable, and that can have no downtime. Erlang doesn't have a string
    data type. Imagine that -- a computer language without a string data
    type!

    Perl is optimized for particular kinds of jobs. I'm a database guy and
    I manipulate data for a living. Turns out that Perl is pretty much
    perfect for that, and I've tried several other languages for the same
    thing, so I'm speaking from experience. Part of that optimization is
    allowing different ways of doing stuff. If you munge data for a
    living, you will know what I mean.

    You don't have to use Perl. In fact, if your job isn't suited for
    Perl, you SHOULDN'T use Perl, but something else. However, if you use
    Perl for it's intended purpose, and have used other languages for
    different kinds of jobs, you understand that TIMTOWTDI is part of
    Perl's optimization, without which it wouldn't be Perl, but Python or
    maybe Lisp or some other language.

    CC.
     
    ccc31807, Jun 9, 2010
    #4
  5. Peng Yu

    Steve C Guest

    Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    Peng Yu wrote:
    > The following thread shows many ways of reading a given number of
    > lines.
    >
    > http://groups.google.com/group/comp...819866cb?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.
     
    Steve C, Jun 9, 2010
    #5
  6. Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    Peng Yu wrote:
    > The following thread shows many ways of reading a given number of
    > lines.
    >
    > http://groups.google.com/group/comp...819866cb?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
     
    Xho Jingleheimerschmidt, Jun 10, 2010
    #6
  7. Peng Yu

    Peng Yu Guest

    Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    On Jun 9, 12:18 pm, Charlton Wilbur <> wrote:
    > >>>>> "PY" == Peng Yu <> writes:

    >
    >     PY> But I doubt that having multiple ways of doing the same thing
    >     PY> really give us any advantages over other languages.
    >
    > The culture in which Perl has developed for the past couple of decades
    > embraces "TIMTOWTDI" - "there is more than one way to do it."  See the
    > entry in the glossary of Programming Perl, 3rd ed., on page 1005.
    >
    > 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.

    I think that any code can be encapsulated in a subroutine or a class.
    To the end user, the actually implementation doesn't matter. It is the
    interface that matters. There should be just one unique interface to
    do the same task.

    In this sense, there were a subroutine that can read multiple lines
    from a file. There is no need that the users should understand the
    different ways of reading muliple lines as discussed in other thread
    mentioned the original post.

    To me, if there were enough encapsulate in perl, there is no need of
    TIMTOWTDI at least i the interface level.
     
    Peng Yu, Jun 10, 2010
    #7
  8. Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    Peng Yu wrote:
    > On Jun 9, 12:18 pm, Charlton Wilbur <> wrote:
    >>>>>>> "PY" == Peng Yu <> writes:

    >> PY> But I doubt that having multiple ways of doing the same thing
    >> PY> really give us any advantages over other languages.
    >>
    >> The culture in which Perl has developed for the past couple of decades
    >> embraces "TIMTOWTDI" - "there is more than one way to do it." See the
    >> entry in the glossary of Programming Perl, 3rd ed., on page 1005.
    >>
    >> 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.
    >
    > I think that any code can be encapsulated in a subroutine or a class.
    > To the end user, the actually implementation doesn't matter. It is the
    > interface that matters. There should be just one unique interface to
    > do the same task.


    Weren't you recently complaining that you needed to encapsulate your own
    selection without replacement, and Perl should just do it for you
    automatically?

    Xho
     
    Xho Jingleheimerschmidt, Jun 10, 2010
    #8
  9. Peng Yu

    Chris Nehren Guest

    Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    On 2010-06-10, Peng Yu scribbled these
    curious markings:
    > On Jun 9, 12:18 pm, Charlton Wilbur <> 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
     
    Chris Nehren, Jun 10, 2010
    #9
  10. Peng Yu

    Ted Zlatanov Guest

    Re: Why does perl allow so many different ways of doing essentially the same thing?

    On Wed, 09 Jun 2010 12:15:18 -0500 John Bokma <> wrote:

    JB> Peng Yu <> 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.

    But deciding what will be in the API is a very hard task, and
    implementing it will be no easier.

    Ted
     
    Ted Zlatanov, Jun 10, 2010
    #10
  11. Re: Why does perl allow so many different ways of doing essentially the same thing?

    >>>>> "PY" == Peng Yu <> 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.

    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
     
    Charlton Wilbur, Jun 10, 2010
    #11
  12. Peng Yu

    John Bokma Guest

    Re: Why does perl allow so many different ways of doing essentially the same thing?

    Ted Zlatanov <> writes:

    > On Wed, 09 Jun 2010 12:15:18 -0500 John Bokma <> wrote:
    >
    > JB> Peng Yu <> 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).


    My favourite Jurassic Park quote is "Life will find a way". I am
    learning Python and follow comp.lang.python and there are countless
    discussions on how to do this or that in Python. While the cult strives
    for "there should be one - preferably only one - obvious way to do it"
    they also call code pythonic (or not) :) making at least to me clear
    that it's not that easy. Python has also several ways to do certain things.

    > 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.


    Yup, and IMO makes learning it less easy. And there are many ways to do
    things :). I recently used HTML::Template and for most of what I wanted
    to do it was good enough. For other things I had to do some
    preprocessing in the code itself which with TT I could've done in
    TT. But what's better? Logic in two places or in one? I have often the
    feeling that dumbing down a template language results in reinventing
    HTML and making it smarter and smarter results in the reinventing of PHP
    (but better :-D ).

    > But deciding what will be in the API is a very hard task, and
    > implementing it will be no easier.


    Agreed.

    IMO: Perl has a strong focus on not breaking things, while Python has a
    strong focus on cleaning up the language / extending the language in a
    clean way (if it makes it more Pythonic). I still don't know what's
    better. I wish that Perl by now had real OO support and real
    exceptions. OTHO, I manage and I do like how flexible Perl can be. And
    its (relative) speed.

    --
    John Bokma j3b

    Hacking & Hiking in Mexico - http://johnbokma.com/
    http://castleamber.com/ - Perl & Python Development
     
    John Bokma, Jun 10, 2010
    #12
  13. Peng Yu

    Peng Yu Guest

    Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    On Jun 10, 10:14 am, Charlton Wilbur <> wrote:
    > >>>>> "PY" == Peng Yu <> 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
    >
     
    Peng Yu, Jun 11, 2010
    #13
  14. Peng Yu

    Peng Yu Guest

    Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    On Jun 10, 8:32 am, Ted Zlatanov <> wrote:
    > On Wed, 09 Jun 2010 12:15:18 -0500 John Bokma <> wrote:
    >
    > JB> Peng Yu <> 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.
     
    Peng Yu, Jun 11, 2010
    #14
  15. Peng Yu

    ccc31807 Guest

    Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    On Jun 11, 5:55 am, Peng Yu <> 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
     
    ccc31807, Jun 11, 2010
    #15
  16. Peng Yu

    Peng Yu Guest

    Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    On Jun 11, 7:53 am, ccc31807 <> wrote:
    > On Jun 11, 5:55 am, Peng Yu <> 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) }
     
    Peng Yu, Jun 11, 2010
    #16
  17. Peng Yu

    Ted Zlatanov Guest

    Re: Why does perl allow so many different ways of doing essentially the same thing?

    On Fri, 11 Jun 2010 03:11:36 -0700 (PDT) Peng Yu <> wrote:

    PY> On Jun 10, 8:32 am, Ted Zlatanov <> wrote:

    >> 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.


    PY> Yes. Essentially this is what I'm asking.

    Well, can you list the functions you think Simple::perl should provide?
    What would you expect from it, and what wouldn't belong in it?

    PY> I think this is a more important problem than figuring out how many
    PY> ways of programming there are and choosing the best one out of them,
    PY> in the sense that once such choice has been figured out in a given
    PY> context, then just package it into an API then people don't have to
    PY> worry about it in the future.

    I disagree about this, but as I said it could be useful to beginners.
    I'd suggest you investigate Lisp (especially the syntax tree and the
    macros), Google's Guava project, and the Template Toolkit to understand
    the concepts of metaprogramming and why a simple API may not be the best
    approach. Guava is probably closest to your ideal.

    On Thu, 10 Jun 2010 13:23:39 -0500 John Bokma <> wrote:

    JB> But what's better? Logic in two places or in one? I have often the
    JB> feeling that dumbing down a template language results in reinventing
    JB> HTML and making it smarter and smarter results in the reinventing of
    JB> PHP (but better :-D ).

    There's quite a few opinions on this balance (which I'd say is one of
    the fundamental elements of programming) in the terrific "Coders at
    Work" interviews by Peter Seibel; L Peter Deutsch in particular comments
    on how frustrating it is that today's software has essentially made no
    progress since the late 60's to abstract logic and constraints out of
    the code. I think Lisp macros are the best answer to your question so far.

    JB> IMO: Perl has a strong focus on not breaking things, while Python has a
    JB> strong focus on cleaning up the language / extending the language in a
    JB> clean way (if it makes it more Pythonic). I still don't know what's
    JB> better. I wish that Perl by now had real OO support and real
    JB> exceptions. OTHO, I manage and I do like how flexible Perl can be. And
    JB> its (relative) speed.

    I simply don't enjoy the dry Python syntax. Java is similarly boring
    (though it has become livelier with generics and now the upcoming Java 7
    features). Perl and Lisp (and Ruby, their mutant child, which I kind of
    like) are much more fun to write and so I do. IMHO every programmer has
    these likes and dislikes and we simply layer excuses on top :)

    Ted
     
    Ted Zlatanov, Jun 11, 2010
    #17
  18. Peng Yu

    ccc31807 Guest

    Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    On Jun 11, 10:54 am, Peng Yu <> wrote:
    > 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).


    In a recent thread, 'to RG - Lisp lunacy and Perl psychosis', we have
    these examples.

    Example 1, by me:
    if ($sec{$k}{'xlist'} !~ /\d/)
    { $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
    elsif ($sec{$k}{'xlist'} eq $sec{$k}{'crs_id'})
    { $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
    else
    { $fac{$sec{$k}{'id1'}}{'location'} = $sec{$sec{$k}{'xlist'}}
    {'site'}; }

    Example 2, by Ben Morrow
    my $seck = $sec{$k};
    my $xlist = $seck->{xlist};
    my $id1 = $seck->{id1};
    my $fack = $fac{$id1};

    if ($xlist !~ /\d/) {
    $fack->{location} = $seck->{site};
    }
    elsif ($xlist eq $seck->{crs_id}) {
    $fack->{location} = $seck->{site};
    }
    else {
    $fack->{location} = $xlist;
    }

    I write the kind of stuff in Example 1 every day, I'm comfortable with
    it, I can read it, and (to me) it's clear and unambiguous. To Ben
    Morrow, it's 'unreadable'.

    Question: do you get clearer, more readable code by allowing
    developers to work within their comfort zone, or by forcing all
    developers to use arbitrary standards with which they not be
    temperamentally suited?

    People have different learning styles, some are visual learners, some
    are auditory learners, some are haptic learners, and so on. When we
    teach, we take all learning styles into account and we don't force one
    style on every student.

    More to the point, Perl is an open technology, which everyone is free
    to use as he sees fit. Damian Conway, in his book 'Perl Best
    Practices', make the point that there is no one right way to do
    something, only ways that have proven useful and other ways that
    aren't so useful.

    I think you're beating a dead horse. Perlistas tend to be
    individualistic, like the language, and you can't convince them to be
    communitarian. If you like to dictate policy, learn and use Java.

    CC.
     
    ccc31807, Jun 11, 2010
    #18
  19. Re: Why does perl allow so many different ways of doing essentially the same thing?

    >>>>> "PY" == Peng Yu <> writes:

    PY> Rather than being hypothetically saying there are different ways
    PY> of coding for different parameter values. I'd like to see what
    PY> the best code is for reading three lines and what is the best
    PY> code is for reading 10000 lines?

    PY> And I would like to know how much time and effort it would
    PY> require to know the different between the different code and how
    PY> much actually difference (say in performance or whatever
    PY> metrics) can be gained by careful choosing different ways.

    You're a programmer, and programming is as much empirical art as
    theoretical science. Try it and see, and learn something.

    Charlton



    --
    Charlton Wilbur
     
    Charlton Wilbur, Jun 11, 2010
    #19
  20. Peng Yu

    Dr.Ruud Guest

    Re: Why does perl allow so many different ways of doing essentiallythe same thing?

    Peng Yu wrote:

    > The following thread shows many ways of reading a given number of
    > lines.
    >
    > http://groups.google.com/group/comp...819866cb?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
     
    Dr.Ruud, Jun 12, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rob R. Ainscough

    Are ASP.NET user interfaces essentially dead now?

    Rob R. Ainscough, Dec 8, 2005, in forum: ASP .Net
    Replies:
    24
    Views:
    970
    Brendan Reynolds
    Dec 11, 2005
  2. Michael Sparks
    Replies:
    3
    Views:
    332
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,010
    Smokey Grindel
    Dec 2, 2006
  4. Replies:
    3
    Views:
    935
    Roedy Green
    Jan 28, 2008
  5. John Reye
    Replies:
    28
    Views:
    1,377
    Tim Rentsch
    May 8, 2012
Loading...

Share This Page