-- The schizophrenia between python 2.n and 3.n and 2.n+1 in the various system and deployment scripts and packages causes me nothing but pain when playing sysadmin on my own boxes. As a non-user, if I weren't constantly told how great python is I'd assume it was just as much a mess as PHP.

Perl is stuck to increment subversions cause it's stuck to the decision to assign the number "6" to a language which is effectively a "Perl++".

Observing the problems between different Python versions - not only 2.7 and 3.3 - highlights how "much" Pythonistas really care about code quality and (backwards) compatibility.

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?

• Try to get happy with additional distribution prepackaged CPAN modules. This may work for simpler things and is often backed up by a company system policy.
• Install additional modules from CPAN into the Perl runtime environment. This happens when people start to use cpan without thinking further. If you install something which doesn't pull newer versions of prerequisite modules which already exist as prepackaged distribution modules, you have luck. After that point a big big mess starts up. (I've seen that many times.)
• You start to get aware that installing additional Perl modules from CPAN into system's Perl is not a good idea. Now you think about installing CPAN modules into a "private" directory to be independent from the system's modules. This hurdle was IMHO very high before cpanm and local::lib came up. But even with these two modules (let's pray the authors of these) it's not trivial. (Has anyone a link to a tutorial explaining the bits and pieces of how using a "private" CPAN directory works and must be set up especially with the different flavours of install and builing tools?). With this solution you stick to the distribution's Perl version. If you don't get bitten by a Perl bug or don't need a fancy new feature you may get happy with that (distribution's update service gives you security updates).
• The next step is to use App::perlbrew to create your own Perl runtime environment and let all scripts and programs point to the right Perl version and CPAN modules path. But with this step you have the same as you often see with JAVA. Programs are installed with a full blown runtime environment of a certain version. But what does this last step mean? IMHO in this cases you don't have a backward compatibilty problem any more (yes, I know that you have to pay a price at the other end, e.g. maintaining several module versions per runtime version).

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

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>;
[download]

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.

> 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 :)

Hi McA,

Would you be willing to discuss these issues on the freenode IRC channel #perl6? Such issues are a hot topic right now. If you're willing to read a bit first, check out one or more of the recently updated Computational Units specification (which I think is mostly already implemented), Distributions, Recommendations, Delivery and Installation specification (design and implementation in progress, the thing I'm most encouraging you or others to discuss right now on #perl6) and Perl 6 most wanted (what should a batteries included P6 distro include?).

I would love to see feedback, good or bad, on #perl6. Hope to see you there. :)

---

»ö« ^{. o O ( "the celebrity tell-all of the Perl-6 cult?" )}

For as many problems and migration headaches as you get with Python 3, you might as well consider Perl6 to be on equal ground.

No, perl6 is years behind. If Python can't figure out what people should use after five years of having two credible major versions, when will perl6 get there?