Where do Perls come from, Mommy?

(as a personal policy I am going to be refraining from replying directly to nodes posted Anonymously. It is so easy to set up a user account on Perl Monks that I see little justification for anonymous postings here)

An Anonymous Monk wrote over there:

[...] (OSX Panther & Fedora Core 1) so I can't see how I have a non- standard Perl on either of them.

There have been a lot of good replies in that thread so far, but I have my own take on things, so I'll offer a few more opinions. I am seldom running short on those ;-). But I specifically want to reply to this node (sort of, while starting a new topic, which is likely to get me into trouble -- again -- with some folks) because I am not one of the Perl users here who says "I've never had any trouble with installing any CPAN modules." My Monknick is "Intrepid" because I have an uncanny knack for finding trouble -- er, finding real challenging problems to untangle. Since I've had plenty of knock-down drag-out battles with installing perl or extentions on various platforms (I come from MSWindows and its positive symbiont Cygwin), I care a lot about these issues and focus a lot of my personal Perl development time and energy in researching them.

The distribution of Perl, like that of many other "core" open standards technologies, is a multitiered effort that is undertaken by numerous volunteers working in different places and different times. On one level there are the maintainers of Perl itself, and there are people on that level who are very concerned about the viability of the modularized software model Perl has espoused, and very significant efforts are made to ensure that the greatest number of users possible will be able to use most modules from CPAN without having to go through such tribulations. Michael Schwern, Perl's Kwality Kontrol Pumpking, is one such individual (not to slight the many others, past and present). The "pieces" of Perl software that are at the heart of installing modules from CPAN, like ExtUtils::MakeMaker and Module::Build, are under active development most of the time. This represents the Perl community (Perl volunteers) doing its best to be responsive to the needs of users, and it is important to be aware of the efforts (often largely unsung) that are being made behind-the-scenes so that it all "works better".

There is another group of people entirely (well, rather, a different focus, people can and do wear various hats) who are very important in bringing Perl to the machine you are using. Neither you yourself nor any other thread participants mentioned anything about this group, so I think it is especially important for me to point this out. "These people" are the packagers who make whatever configurations (and for Perl, that can be a lot) and alterations necessary, for Perl to be built and run properly on a specific OS/Platform (like "Panther" or "Fedora"). In the case of a RedHat OS, those people may be paid employees of that company, while in the case of something like Debian (which is not a business corporation) they are unpaid volunteers. Whichever they are, they do those things so that you won't have to -- create the build configuration, run the compilation cycle, look for failed tests, build failures, bugs and whatnot. They then create a distribution archive in some format or other that can be downloaded by a sys admin who will install from it to the system in question.

This is the stage of the process where major differences in OS/Platform combinations begin to assert themselves. As a (related) tangential point, note that "all {GNU/}Linux is just linux". All Linuces are running the linux kernel, or else they are not {GNU/}Linux. What differs greatly is the strategic architecture of the package management system. All package management systems or strategies are not created equal. I am a vocal partisan of Debian GNU/Linux because I've been through Dependency Hell many times before, and its package management system (based on a tool called APT and one called dpkg) shows its stuff when the going gets tough. Tremendous amounts of software have been "ported" to APT .deb format distribution archives. I've laughed at Monks in the CB who say things like "a more business-oriented distribution like RedHat" because these are people who have been completely hoodwinked by marketing ploys and wrapping paper and laminated cardboard. They've been raised in culture that teaches people to look at the superficial appearence rather than the substance of things. I laugh sadly.

Whether it is the package management system deployed as part of *BSD or *GNU/Linux or any other platform, there is also the major question of how well the package maintainer does her/his job. Just as all package management strategies are not created equal, neither are package maintainers. Some go the extra distance to to get the most out of whatever package management system their platform employs, while others are sloppy. Since so many packagers - porters - maintainers (whatever you want to call them) are volunteers, like the "upstream" maintainers of Perl itself, their "actual" lives can also interfere with the undertakings they are doing with Perl. By having to rush a release, or having no time for addressing bug reports, or for whatever other reason, many cannot always do quite the job of it they wished to do when they started.

It seems only rational to propose, then, that one wants to make one's self as knowledgeable as possible about the process by which Perl gets onto one's system. Know who the Perl maintainer is for the pre-built, packaged Perl that comes automatically with your OS/Platform. I know who the Debian Perl maintainer is -- Brendan O'Dea (and a fine job he does, too). As a really radical thought, even consider raising your own capability level so that you can support the Perl package maintainer for your OS/Platform -- or even becoming one yourself. You chose the platform you run Perl on; instead of assuming that it is someone else's responsibility to make sure that Perl runs well on it ("running well" includes being able to extend or update by installing CPAN modules), take some responsibility yourself. At least ask questions of your vendor, and if you don't feel that they are as responsive as they should be, consider making a change in your own computing platform.

My intent is not to justify specific finger-pointing for the troubles you've had with installing many CPAN-registered modules, but to introduce you to the knowledge that "Perl" didn't come straight to you from Larry Wall or Jarkko Hietaniemi or whomever. It came through the hands of other levels of personnel (either paid or volunteer, either part of a fairly cohesive, standards-enforcing community like Debian, or a worker doing that project largely in solitude .. and either for love, or just because someone told her/him they "have to" do it). Know and recognize this. And when assigning even vague culpability for what you see as Perl's shortcomings, at least have all the relevent facts in mind before painting with a broad brush.

Best regards.

Soren A / somian / perlspinr / Intrepid
P.S. Don't forget: I am expecting all the people the people who say I am posting to Perlmonks for the XP to automatically downvote this posting w/o explanation, thanks.

-- 
Try my n.y.p.m.blue Perl Monks CSS Theme
(edit "On-Site CSS Markup" in your User Settings)

Comment on Where do Perls come from, Mommy?

Replies are listed 'Best First'.
Re: Where do Perls come from, Mommy? by Anonymous Monk on Apr 01, 2004 at 06:52 UTC
I think you missed the point. Perl is always going to have had a tremendous amount of work put into it; and anyone who experiences problems as a "newbie" is almost bound to have missed some obvious solution, or have things slightly wrong. I don't think that's an offence to Perl, disrespectful to the people who put effort into Perl, and I'm not totally convinced that people need to have an in-depth knowledge of how Perl works before they can comment on what is good and bad about Perl. Modules that use XS links to C are a good case in point. They are often difficult to install, with or without CPAN, and no amount of testing is going to get rid of all the difficulties, it's just a hairy system. Many other languages have the capability to dlopen() C libraries and make arbitrary calls against them; I wish Perl were able to do that. If it could, many of the uses of XS could be avoided, which would definitely help - PurePerl modules are very rarely difficult to install in my experience. You say "when assigning even vague culpability for what you see as Perl's shortcomings, at least have all the relevent facts in mind before painting with a broad brush.". Yet, you have a good go at RedHat (and implicitly RPM), even though it seems you don't have a good grasp of the relevant facts. apt has nothing to do with .deb; dpkg is the program that deals with them. Even when you use apt to get stuff, it's dpkg doing the work to install. dpkg demands dependencies, apt goes and gets them. They're a team. Implying that rpm is somehow "dependency hell" just shows how little you know about RedHat/Fedora; dpkg is equally "dependency hell" on that basis. I don't think it's wrong that people expect their platform to work for them. I think it's probably wrong if they come here to complain about it in the first instance, but the Monk in question had tried two completely different platforms and failed to get either to work. Bringing in external modules is a known problem anyway; people have been discussing this for years. That's why there are solutions like PAR out there - we already know it's not necessarily easy. I would prefer Monks to come here and respect the work of others because they understand the time and effort put in, not because people get arsey when they show "disrespect". It's verging on communal egotism. Tell people who lack clue where they're wrong and move on.	[reply]
Re: Re: Where do Perls come from, Mommy? by eserte (Deacon) on Apr 01, 2004 at 09:51 UTC
Modules that use XS links to C are a good case in point. They are often difficult to install, with or without CPAN, and no amount of testing is going to get rid of all the difficulties, it's just a hairy system. Many other languages have the capability to dlopen() C libraries and make arbitrary calls against them; I wish Perl were able to do that. If it could, many of the uses of XS could be avoided, which would definitely help - PurePerl modules are very rarely difficult to install in my experience. You mean something like C::DynaLib? Well, there's a big warning on top of the README of that module: ********************************************************* * THIS CODE CONTAINS SYSTEM DEPENDENCIES. * * IT WILL NOT WORK ON ALL COMPILERS, MACHINES, OR * * OPERATING SYSTEMS. USE AT YOUR OWN RISK. * ******************************************************* ******************************************************* * A BETTER WAY TO INTERFACE TO C CODE IS WITH XS. * * PLEASE READ THE "perlxs" DOCUMENTATION BEFORE * * MAKING EXTENSIVE USE OF THIS MODULE. * ********************************************************* [download] Please also note that there may be still systems without dynamic loading.	[reply] [d/l]
Re: Re: Re: Where do Perls come from, Mommy? by flyingmoose (Priest) on Apr 01, 2004 at 22:21 UTC
dllopen (calling functions by name from libraries) is really a PITA when you need something other than a function name, such as those horrid cases where some dolt that you work with coded their library in C++ and you need an OO interface :) Been there, tried that, got the T-shirt. But yeah, if you are doing a plugin interface and it's a bunch of C-libs it's kinda cool. So do that dllopen inside your C code and XS into THAT! Yep, Fedora Core can be a BEAST with weird dev packages, such is the nature of Fedora -- I'm stuck with it since I have an obscure laptop and it makes trying to get Debian up a little 'fun'. But this is Fedora's problem, not Perl, and yes, unfortunately (as much as I would like it) dev packages change and CPAN modules can't work with every version. But with Fedora doing the gruntwork in testing SELinux and GNOME 2.6, they are going to be stable and great, so maybe they deserve a bit more credit! I appreciate them. So far I have trouble with SDL, Zinc, some Audio stuff, what else? Quite a darn bit. But overall, it runs on my evil laptop, I have apt support, and that's all well and good. dllopen won't prevent you from a changing interface, anyway. They're a team. Implying that rpm is somehow "dependency hell" just shows how little you know about RedHat/Fedora; dpkg is equally "dependency hell" on that basis. apt, my man, use apt -- and with freshrpms sources.	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Where do Perls come from, Mommy? by flyingmoose (Priest) on Apr 01, 2004 at 22:29 UTC
(as a personal policy I am going to be refraining from replying directly to nodes posted Anonymously. It is so easy to set up a user account on Perl Monks that I see little justification for anonymous postings here) Kinda unfair to the new folks that might just have one question. I know I posted as anonymonk once or twice before I registered, and being rude to new users keeps folks from joining. I should also add I am less likely to join sites if they don't allow anonymous users, as they are more apt to turn into cliques. There are some exceptions, but it's nice to keep things open until there are spam issues. I do disagree with the idea of using anonymonk to whine in PerlMonks discussion though, but hey that's a small deal. Live a little. Maybe, just maybe, that anonymonk has a ton to contribute in the community and just didn't register yet. Wanna slap them down? I don't think we do. They are our friends. Awwwwww ......	[reply]
Re: Re: Where do Perls come from, Mommy? by gunzip (Pilgrim) on Apr 02, 2004 at 23:27 UTC
OK, I posted the original post and have a username now. To extend my original point, the problem with treating module compilation failures as user skill deficiency is that it assumes that all Perl users are going to be seasoned sysadmins who have time to futz with their OS all day. My fear, as someone who came to Perl for the elegance of its syntax, is that when faced with real world problems, largely in the web-development field, I would like to use Perl but I do not have the time to go into the intricacies of why a CPAN module fails to compile on, say, Linux or OSX. I am competent enough to get these OS's installed and learn programming languages but I have work to do and need tools which are supposed to work to do just that. I don't blame the sincere efforts of package maintainers it's just that every failed Perl module compilation is another gallon of petrol in the tank of PHP's engine, which is racing ahead of Perl in uptake by new-to-intermediate level web developers. Alright, alright. I know Perl is used for much more than developing websites and that many Perl users don't use it for this but it should be of concern that the new kid on the block - PHP - is leaping ahead despite being an inferior language overall (design etc.). It concerns me because I am under pressure to use PHP instead of Perl in many situations, often as a result of how incomplete a Perl ISPs offer. I can only suggest that module compilation complications MAY play a part in this. I know many of you couldn't care less about Netcraft comparisons of mod_perl and PHP but it is important if new web developers are missing the chance to learn Perl for server-side work because PHP is becoming the standard for small-to-medium sites. It matters to me and a start could be made with Perl6 by bundling at least one templating module with the core installation. Then even if extra modules prove problematic we would have something to compete with PHP on every Perl installation. Perl + mod_perl + Apache::Session + HTML::Mason is just too many bits 'n pieces to get the same level of performance offered by PHP. One very competent sysadmin I know, who runs his own ISP, will not offer mod_perl because he tells me the memory management in a shared sever environment is too precarious compared with PHP. Maybe parrot will help solve some of these problems. Who knows? The question for me is whether the Perl community cares.	[reply]
Re: Re: Where do Perls come from, Mommy? by ysth (Canon) on Apr 04, 2004 at 13:21 UTC
There's no requirement to register to contribute a ton or even more.	[reply]
Re: Where do Perls come from, Mommy? by Anonymous Monk on Apr 02, 2004 at 03:20 UTC
(as a personal policy I am going to be refraining from replying directly to nodes posted by Intrepid. It is so easy to set up a user account on Perl Monks that I see little justification for morons here My pseudonym could beat up your pseudonym :-P	[reply]