in reply to Re^4: What is best for the future.
in thread What is best for the future.

Two ways of using a 'if' is perfectly alright. But what if there are a dozen synonyms for if?

So where is your threshold? How many ways to say the same thing are OK, and at how many it's one too much?

But more to the point, the different OO modules don't do all the same stuff. Using Moose and declaring an attribute doesn't give you the same thing as Class::Accessor::Fast does. (For example Moose also gives you lazy default values and introspection for the attributes).

So there are dozens of ways to write similar but slightly different things, which we have in perl too: 

while ($x > 0) {
   say $x;
   last;
}

say $x unless $x <= 0;

$x > 0 && say $x;

# I'm sure you can come up with dozens of examples
# that achieve the same result, but are still
# slightly different.

[download]
Now this is just a 'if' example, if this thing gets replicated everywhere don't you think its not the right way forward.

I agree that there's no point in introducing exact synonyms just for the sake of perceived diversity. But that doesn't compare to all the OO modules, which don't all do the same things.

Perl 6 - links to (nearly) everything that is Perl 6.

Replies are listed 'Best First'.
Re^6: What is best for the future.
by Anonymous Monk on Aug 25, 2010 at 07:59 UTC
    So where is your threshold? How many ways to say the same thing are OK, and at how many it's one too much?

    I think the current syntax defaults for stuff like if, while etc is OK. But going a bit higher onto things like multi methods, signatures, overloading, grammars have to have some standard or default way of doing. Else the syntax combinations will run into permutations and combinations. And there will far too much complexity to deal with. And since most of them offer same semantic capabilities, the competition will be more on which one has more syntactic sugar.

    For a moment keep 'OO' aside, Imagine what would happen if in a single program three different 'if' synonyms, 'switch' synonyms etc Start appearing in a huge code base and one is asked to maintain such code in the DarkPAN. Perl starts to suffer from same decade old 'unmaintainable' infamy.

    I'm not telling people must stop experimenting this kind of stuff, in fact we must continue. Neither am I suggesting we must halt at one way of declaring something, that would obviously be wrong. Since once a particular way is chosen and taken and then fears of breaking backward compatibility stops us from correcting past mistakes and those mistakes carry on over time.

    We must surely keep new things coming on CPAN. As you suggested pushing things into the core is not a good idea. But the alternate to that is "new syntax through CPAN".However a proper guide/policy is needed as to indicate what is saner/safer to use. Before a lot of code comes out.

[reply]
      For a moment keep 'OO' aside, Imagine what would happen if in a single program three different 'if' synonyms, 'switch' synonyms etc

      The project manager would fire the programmer. But that's still beside the point, because that's not what happens in those syntax experiments.

      You keep repeating the same thing, so I'll try one last time to explain the difference to you:

      'if' is a simple, well-understood concept that exists already in the Perl programming language, is well integrated with all other features in the programming language, and is very short. There's not much you can add to an if-statement to enhance its value (at least I haven't seen any experiment that demonstrates added value).

      Most syntax experiments (signatures, OO, overloading, grammars) explore complex concepts that are not yet present in the language in they way envisioned by the authors, and often try to provide concise ways to express things that are already possible, though not as easy or convenient.

      (If you're not convinced that those things are indeed complex, and need thorough exploring before they can be done right, I suggest you take a look at the excellent talk "Perl 6 Signatures The Full Story" by Jonathan Worthington: video, slides)

      SO I can't understand why you keep comparing things that are so wildly different that they can't be compared in a meaningful way.

      However a proper guide/policy is needed as to indicate what is saner/safer to use

      I agree that we need a better way to collect the knowledge of the perl community about which module to use for what task, and to make that knowledge available to the casual perl programmer who doesn't actively participate in the community discussions.

      Perl 6 - links to (nearly) everything that is Perl 6.
[reply]

        I don't if its the lack of communication skills that I'm unable to convey the message here.

        Nobody can stop people from writing whatever(bad or good) programs they want to write. If the environment enables novices to that easily that will become more than sufficient grounds for bad PR. My point is that in order to do something like function signatures(Which by the way is nothing extra, and is just catching with other languages in Perl's class) if you have to import nearly 2 modules and for each every such equivalent you need to keep importing such modules. And after all that you are confused which modules to choose from CPAN. It becomes a bad manifestation of TIMTOWDI. Its freedom, but its far too much pain to assemble an environment from scratch. And even more bigger pain to maintain it. Its like those early linux systems, you could assemble them from scratch but that was the only reason most people didn't use it. Until a standard way of distribution came along where packaging and distribution was a lot more saner and better managed. Now it finds rapid adaption in enterprises and desktops. At the same time, other experiments on Kernel and other utils continue. This whole thing is about deciding on a proper distro.

        Also I completely agree with your complexity argument.

        It helps the language environment to have good set of defaults or at the least a good standard, Even if we don't agree on defaults. In post renaissance stage of Perl's era I think we ought to look at things that troubled us earlier and at least fix a part of that. Things like unmaintainable code can manifest with excessive use of bad modules. We don't want those night mares to haunt us back again.

[reply]

        Ok, as I was browsing the Internet I came across Extended core and Perl5i so people are working on a distro kind of approach.

        And I feel thats a lot better as the core can go on its own,CPAN can produce modules and ultimately distros can decide the whats best for them. Surely this is more on the Linux distro model and it will help bringing consistency.

[reply]
        'if' is a simple, well-understood concept that exists already in the Perl programming language, is well integrated with all other features in the programming language, and is very short. There's not much you can add to an if-statement to enhance its value (at least I haven't seen any experiment that demonstrates added value).
        The same can be said for 'for'. Yet 'foreach' exists.

        Oh, and for the 'if' case, there's an 'unless' which is just a long way of writing 'if!'.

[reply]

In Section Seekers of Perl Wisdom