in reply to Perl and London Broil: The future of computing magic?

Several issues here. Fedora? Ok, Fedora. I run it myself, but! Perl is not the language of choice of them Fedora people. They'd rather weed out perl completely and replace it with python. I don't care, as long as the rest of the distro does what I want. I'm still able to compile and use old stuff with minor tweaks.

For perl modules, I use RPM::Specfile. I have hacked the (included) cpanflute2 to build packages optionally and get dependencies right, and all my perl modules are rpm packages. Which means that I have source and binary (or noarch) packages of them, which means ease of rebuilding. Of course I check every time the existence of a perl package in the Fedora repo, because I'm a lazy boor. And that's just the reason I didn't hack into it the 'follow' mimic of cpan... but then, that's the most time consuming lack-of-features. I guess I should implement that 'follow option', if it hasn't been done already - to just type in cpanflute2 Module-Foo.tgz or cpanflute Module::Foo and get a cup of coffee while it is installing the whole bunch of deps.

Next, PHP vs. Perl. That has long been discussed, and the only bit I'll add to it is the following observation: perl is multipurpose, while PHP isn't. It is easy to stuff functions addressing all kinds of needs of a one-domain-language into one binary; it is hard for a multi-domain language to compete here on the grounds of that specific domain. And why should it specialize, anyways?

PHP is to perl what orcs are to elves.


update: corrected last statement

Replies are listed 'Best First'.
Re^2: Perl and London Broil: The future of computing magic?
by zerohero (Monk) on Feb 03, 2009 at 18:36 UTC

    >> For perl modules, I use RPM::Specfile. I have hacked the (included) cpanflute2 to build packages optionally and get dependencies right, and all my perl modules are rpm packages. Which means that I have source and binary (or noarch) packages of them, which means ease of rebuilding. Of course I check every time the existence of a perl package in the Fedora repo, because I'm a lazy boor. And that's just the reason I didn't hack into it the 'follow' mimic of cpan... but then, that's the most time consuming lack-of-features. I guess I should implement that 'follow option', if it hasn't been done already - to just type in cpanflute2 Module-Foo.tgz or cpanflute Module::Foo and get a cup of coffee while it is installing the whole bunch of deps.

    Interesting, I'm going to have to do a little spelunking and noodling on this. I definitely need a more robust deployment system

    >> Next, PHP vs. Perl. That has long been discussed, and the only bit I'll add to it is the following observation: perl is multipurpose, while PHP isn't. It is easy to stuff functions addressing all kinds of needs of a one-domain-language into one binary; it is hard for a multi-domain language to compete here on the grounds of that specific domain. And why should it specialize, anyways?

    Completely agree, except for the one niggling issue that I think Perl + Mason (or add your favorite template/web technology here) actually does trounce PHP, without trying too hard. The adoption problem seems to be just getting things up and running (examples: new Macbook, hosted environment). The problem seems to be simple choice and packaging. Perhaps this is something people will eventually just figure out themselves and we are seeing a short-term phenomena. But the difficulty in the setup just stops people dead. On the other hand some might argue that this keeps the unwashed masses far from the Monastery Gates.

    >> PHP is to perl what orcs are to elves.

    The funniest thing I've seen today. I'm going to start propagating this meme...
[reply]
      On the other hand some might argue that this keeps the unwashed masses far from the Monastery Gates.

      I don't mind unwashed masses, as long as they spend time in the sudatorium before they drop into the refectorium...

[reply]

In Section Meditations