Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • all the joy of installing ImageMagick on Irix while getting a root canal without anesthetic.

    Few people either care about or are skilled enough for fine web performance tuning. Who gives a fuck if PHP is slow and ugly, the apps are there, easy to install and most importantly, they work. Well, most of the time.

    For years Perl people laughed when I thought that geriatric software for grandparents was an untapped market for perl since, if gran can install it, anyone can. Sadly, it was declared unmanly to ha

    • And, getting mod_perl and mod_php to live together on a single apache server is nigh impossible. I had to choose and I chose mod_php.

      Depending on the truth of this (may just be your particular experience here, and not everyones .. anecdotal evidence...), this itself may be the single largest reason for the lack of adoption. If getting both functioning on the same server is rather a bear to accomplish, which one do you think they are more likely to use?

      Also there is a major amount of perception that mo

      • I wasn't the first to experience this even though Solaris isn't linux, but Jarkko has said the same thing so I feel reasonably certain that it's either an obvious triviality that we all missed or it really is a major PITA/impossibility. I spent 4 days with a square peg, a round hole and a hammer and all I got was a crashy crashy pile of shite that liked neither perl nor php. Installing mod_php by itself took 15 minutes and I had an app running a few minutes later without having to download half of CPAN. I

        • mod_perl is debugged in the same way as any other perl app: with logging or the debugger. There's no big trick to it. Also, the answer to your CPAN complaints is to bundle the dependencies with your distribution. PHP doesn't have this problem yet because it essentially has no code reuse.
          • I don't think you understood what I was saying. I said 'esoteric' bug which means something very unusual which can be very difficult and very frustrating to locate and solve. It's not for the average user.

            My CPAN complaints come from my own as well as plenty of other people who share the pain of CPAN dependency chains. It was a big topic as last years CPAN meeting as it's a problem. Clearly, you don't understand what I'm talking about as it's not about bundling dependencies. When one module hoovers in 1

            • So an "esoteric" bug is easier to solve in PHP? Every language has tricky bugs of some kind.

              My interpretation of your dependency issues is that you're saying some modules use lots of other modules for small things, and maybe they don't need to. However, if you bundle all of the needed modules for your app with the app itself, there is no need to go to CPAN at all when installing it, so it's a moot point. See the Krang distributions [sf.net] for example. All needed modules are included.

              • I figure when Doug McEchern had no idea how to fix a particular problem I found a while back, I thick it goes beyond tricky.

                They aren't /MY/ dependency issues, it's something I hear a lot of people bitch about and I'm not terribly fond of a module, literally, hoovering in 115 modules from CPAN, bundled or not. Especially when module versions and perl versions are moving targets wrt to those. Again, I don't think you fully understand the problem.