in reply to Where do Perls come from, Mommy?

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.

Replies are listed 'Best First'.
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]
      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.

In Section Meditations