in reply to Re: Perl 6 gets some press
in thread Perl 6 gets some press

Maybe intimidating isn't the right word, but more than one way to do it can be problematic when you have a lot of perl code. In languages with only one way to do it, there are no discussions between developers as they try to convince each other to do it their way. There is no code sprinkled through the code base doing the same thing 5 different ways.

I've been in these discussions many times and they are difficult because everyone can have good reasons for their approach.

However, once you decide on how you're going to do it 90% of the time, you are set. And with Perl, you still have the flexibility to consciously decide to do it different 10% of the time to handle a strange corner case. If there is only one way to do it, you don't have this flexibility.

I believe Perl 6 will address this nicely. I think they will provide one recommended way to do things, but still leave in the other ways to do it.

So for environments without good structure and standards, Perl can be challenging because it will highlight the lack of management. But as merlyn says, this isn't Perl's fault, it's a problem with the environment.

Replies are listed 'Best First'.
Re^3: Perl 6 gets some press
by chromatic (Archbishop) on Mar 09, 2006 at 18:52 UTC
    In languages with only one way to do it...

    I've programmed non-trivial code in about 10 languages in the last eighteen months (and read code in a few others). Which languages provide only one way to do something?

      Turn that around and ask what thing can only be done one way (if at all) in some languages, but one or more ways in Perl. Classes/objects come to mind immediately. Functional programming is another.

      For other things, while there may not be only one way to do it in other languages, Perl offers many more options. For that, loops and loop control comes to mind, particularly postfix modifiers and next, last, map, grep, etc. All the array modifiers might be in that camp, too.

      In a more abstract sense, subroutine argument passing and argument type validation is something that gets done lots of different ways in Perl, where in some other languages that is never even a question the programmer has to consider.

      Some of these are exactly the kinds of things that Perl 6 is trying to define in a more standard way.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      Objects was the main area I was thinking of based on some recent experience. I think many languages that support OO have just one way to do it, but with Perl there is an amazing array of choices. You can store your object data various ways, handle inheritance various ways, and now you can even build them inside-out. :)

      But you're correct that I'm waving my hands a bit there. I spend most of my coding time with Perl, so it's been a while since I played with Java, C++, or others.

        I think many languages that support OO have just one way to do it, but with Perl there is an amazing array of choices.

        Well there are other languages that have a flexible approach to OO. Lisp and Ruby both spring to mind.

        The other thing is that with Perl's OO a lot of the TIMTOWTDI comes from there not being one 'good' way of doing it. This hurts rather than helps Perl's OO system because the various different ways of doing it don't always play well together.