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

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.

Replies are listed 'Best First'.
Re^8: What is best for the future.
by Anonymous Monk on Aug 25, 2010 at 08:54 UTC

    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]
Re^8: What is best for the future.
by Anonymous Monk on Aug 25, 2010 at 09:14 UTC

    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]
Re^8: What is best for the future.
by JavaFan (Canon) on Aug 26, 2010 at 12:34 UTC
    '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]
      The same can be said for 'for'

      'for' supports two very different things (the C-style 'for', and iteration over list), so I wouldn't put it in the same category.

      Perl 6 - links to (nearly) everything that is Perl 6.
[reply]
        'for' supports two very different things (the C-style 'for', and iteration over list), so I wouldn't put it in the same category.
        Yet, 'for' and 'foreach' are actual aliases; both can do the same things.

        But here's another example: tr/// and y///. Or do they provide two different things as well? How about $$foo[0] vs. $foo->[0]?

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom