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
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.