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

[Peng Yu]

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

 

[John Bokma]

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 .

 

[Charlton Wilbur]

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

 

[ccc31807]

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.

 

[Steve C]

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.

 

[Xho Jingleheimerschmidt]

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

 

[Peng Yu]

    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.

 

[Xho Jingleheimerschmidt]

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

 

[Chris Nehren]

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.

 

[Ted Zlatanov]

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:erl (analogous to
Modern:erl) 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

 

[Charlton Wilbur]

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

 

[John Bokma]

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:erl (analogous to
Modern:erl) 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.

 

[Peng Yu]

    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.

 

[Peng Yu]

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:erl (analogous to
Modern:erl) 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.

 

[ccc31807]

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:arseWord 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

 

[Peng Yu]

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:arseWord 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) }

 

[Ted Zlatanov]

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

Well, can you list the functions you think Simple:erl 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.


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

 

[ccc31807]

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.

 

[Charlton Wilbur]

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

 

[Dr.Ruud]

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.