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: Peng Yu on 9 Jun 2010 11:42 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? Regards, Peng
From: ccc31807 on 9 Jun 2010 13:18 On Jun 9, 11:42 am, Peng Yu <pengyu...(a)gmail.com> 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.
From: Peng Yu on 9 Jun 2010 22:59 On Jun 9, 12:18 pm, Charlton Wilbur <cwil...(a)chromatico.net> wrote: > >>>>> "PY" == Peng Yu <pengyu...(a)gmail.com> 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.
From: Xho Jingleheimerschmidt on 10 Jun 2010 00:19 Peng Yu wrote: > On Jun 9, 12:18 pm, Charlton Wilbur <cwil...(a)chromatico.net> wrote: >>>>>>> "PY" == Peng Yu <pengyu...(a)gmail.com> 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
From: Tad McClellan on 10 Jun 2010 01:28
Peng Yu <pengyu.ut(a)gmail.com> wrote: > On Jun 9, 12:18 pm, Charlton Wilbur <cwil...(a)chromatico.net> wrote: >> >>>>> "PY" == Peng Yu <pengyu...(a)gmail.com> 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. If there is Only One Way to say, print a certain number of lines from a file, then you cannot proceed until you have found that One Way. If there are multiple ways, then you only have to find any one of them, and you can then proceed with your real job. Which is better searching for a needle in a haystack or searching for any of a bunch of needles in a haystack? See also: http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/2f1ca39cbbc86cc6/ff1a79653c5564c7?q=#ff1a79653c5564c7 -- Tad McClellan email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/" The above message is a Usenet post. I don't recall having given anyone permission to use it on a Web site. |