in reply to Re^2: Unexpected Python News
in thread Unexpected Python News

Hi Rolf,

it's an interesting discussion how to cope with progress in a programming language and backward compatibility. IMHO there is not a white or black to that problem.

E.g. when Python introduced version 3 it was a key issue to help the people to tranform their programs to 3.x. Whether this was so successful is another question. It was made worse with performance problems in 3.0 which didn't make a transition attractive. Python also faced the problem that the Linux distribution packages remained on 2.x as basis for the upcomming system tools (This is a really interesting question: Why were more and more system support or administration tools which is traditionally the domain of Perl made in Python?). This is the same with Perl. E.g. on RHEL 6.x which is common on enterprise environments the current version is 5.10.1.

So now, what are the solutions to the problem when you want or need additional modules or to be more up to date with your Perl runtime environment?

So, what do you all out there use as your path out of this problem?

How should a newcomer cope with this issue? I'm sure he or she isn't even aware of that problem domain.

And now my personal key issue with newcomers (and oldcomers): How should they know what the current state of the art in programming Perl is (answering TIMTOWTDI to them is not a solution). How do they pick CPAN modules to solve their problems? How should a newcomer know what is good? And to that question Python provides IMHO a (kind of) solution: It comes with a library included matching many use cases ("battery included"). Not that it is not possible to find the same or better solutions on CPAN, but someone could get the feeling that this library can't be too bad if someone decided to include especially these modules to the core distribution. Why not using this library? And the whole process around changing and adding to that library is worth a look. I'm pretty sure that this aspect of "batteries included" is an advantage to the beginner and average programmer.

Just wanted to write "...this is my 2 cent...", but looking at the length of my post I have to say 76 cent. ;-)

I like Perl, I dislike programming language battles, but I also like to look around and learn from others and I want to be free to have the opinion that an aspect of a programming language may be solved better in a different language (look at Plack as a copy of WSGI). And if I get the feeling that Perl is loosing more and more people I want to have the right to ask "Why?".

McA

Replies are listed 'Best First'.
Re^4: Unexpected Python News
by liz (Monsignor) on Mar 21, 2014 at 21:05 UTC
    So now, what are the solutions to the problem when you want or need additional modules or to be more up to date with your Perl runtime environment?
    The real important difference between Perl 5 and Perl 6, is the way use works. In Perl 5, use is global. In Perl 6, use is lexical.

    This means that only in the lexical scope where a use command is executed, will you be able to "see" the module having been loaded. In other words: each lexical scope has its own "universe" of code. Only if you need to have two different versions of the same module(name) in the same lexical scope, do you need to provide an alias for one of them (in that scope only, of course).

    This also means that installed modules of different authors and different versions, will be installed side-by-side: there is no possibility of collision in the installation of modules.

    So, if you have a piece of code that you know works with version 1.20 of module Foo, you probably should specify that:

    use Foo:ver<1.20>;
    If this is part of your own module in a distribution, you should make sure that the META6.json file in that distribution, so indicates the dependency on that version of the distribution in which that module lives. An installer will then install the necessary files side-by-side with any other module Foo that is installed (if it isn't installed already).

    In conclusion: the problems that Perl 5 has with versioning of installed modules and dependencies, simply do not (have to) exist in Perl 6: if you are clear in what you need, the system will provide it to you without interfering with anything else.

    For more information, see s22 as it is currently evolving.

      The real important difference between Perl 5 and Perl 6 is that one is a programming language with an usable implementation and the other is Perl 6. But I'm sure Perl 6 will be incredible and contain everything anyone ever conceived. It's gonna be finished in about a year from whenever you read this post. You can come back to it any time and Perl 6 will still be ready in about a year.

      Jenda
      Enoch was right!
      Enjoy the last years of Rome.

        »»» This comment mentions Perl 6. Perl 6 is immature, especially in comparison to the rock solid Perl 5 «««

        Dear reader,

        The Rakudo Perl 6 compiler is a usable implementation. It's not remotely where P6ers would like it to be and there are only a handful of users but folk are using it today to get $dayjob stuff done.


        Dear monks,

        liz, who posted the comment Jenda replied to, is highly respected in the Perl community for her contributions. (She just won a White Camel award.) This was her fist post here at the monastery in a couple years. You can contribute to the Perl 6 project by simply responding to her -- via substantive constructive engagement, or even just encouragement, either here or on #perl6.

Re^4: Unexpected Python News
by LanX (Saint) on Mar 19, 2014 at 12:11 UTC
    > Just wanted to write "...this is my 2 cent...", but looking at the length of my post I have to say 76 cent. ;-)

    Even 2 € :-)

    Probably the best post in this thread so far and there are so many things to discuss.

    Unfortunately I'm very busy ATM preparing the GPW¹, if we don't meet there I'll reply afterwards.

    Cheers Rolf

    ( addicted to the Perl Programming Language)

    update

    ¹) i.e. my talk - not the conference :)

Re^4: Unexpected Python News
by raiph (Deacon) on Mar 21, 2014 at 01:14 UTC
      2001 called, Ralph. It has your relevance.

      If you manage to get it back, please don't spend the next decade killing Perl again. Some of us liked it before your weird cultie experiment wrecked things.

        You see ... if it was labeled experiment from the very beginning it could have had a big and positive impact on versions 7 and 8 of the Perl language. The language not-yet-fully-designed within the project would be just as incomplete, but some of the experience gained in the process could have affected both Perl modules and the language. A bit like it did, but probably more. More importantly it would not have hurt the name of Perl and the community and would not have caused so much bad blood.

        Jenda
        Enoch was right!
        Enjoy the last years of Rome.

        Hi,

        this sounds like you being a little bit upset about things in the past. I never dived into Perl 6 and the long history of that project including the highs and lows. Probably intersting stuff. :-)

        McA