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.

How Do You Cope with Anti-Perl FUD? 8 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • First off, I don't let it actually bother me. I don't take it as an emotional issue. It's only a programming language. To trolls who don't bother with anything more than "I hear Perl is dead", all they really deserve is an "I assure you it's not." As far as "Java libraries have gotten so much better and Perl 6 hasn't come out," there's not much to argue there. Yes, Java progresses, and Perl 6 hasn't come out. It's great that you jumped into Parrot at the hackathon because Perl 6 needs all the help we
    --

    --
    xoa

    • Are Java libraries to any extent open-source creations or are they entirely commercial products?

      With proprietary commercial products, unless you've been invited to be a beta-tester, you are entirely at the mercy of the software's producer as to when the next upgrade will come out. E.g., MS Vista. An individual developer working at company X has no control over that software's release date. At best, he can pester management to purchase it once it does appear. For all practical purposes, the developer h

      • There are massive quantities of free-as-in-speech Java libraries, at least as much stuff as there is on CPAN. The Apache Software Foundation is home to a lot of very popular projects. However, overall, Java does not have a central repository, and the cultural conventions of free Java code are not quite as coherent as those of CPAN stuff.

        Perl remains king with CPAN, but Java is not a bad choice in that area.

        • The difference I've found with Java is not that the code isn't out there. It's finding it. Google helps, but not in the way that search.cpan.org does. And, as you say, there's little-to-no coherency in file layouts, build scripts and all that sort of thing. It's a shame, as there is some really good code out there.

          • I agree with finding the code, There are a few known quantities (jakarta, codehaus) and some well-known places to look for links. But there's no CPAN, and certainly nothing like the infrastructure that's built up around it.

            But I disagree about the build. Nearly all projects have an Ant build script (build.xml) or, less commonly, a Maven build (project.xml). Not all of them have the same targets, but it's there and sufficiently readable to use.

            There is some consistency with file layouts, but a number of

            • I agree with finding the code, There are a few known quantities (jakarta, codehaus) and some well-known places to look for links. But there's no CPAN, and certainly nothing like the infrastructure that's built up around it.

              Yep, they are a couple of well known places (and usually pretty good). But it's still not as integrated as CPAN.

              But I disagree about the build. Nearly all projects have an Ant build script (build.xml) or, less commonly, a Maven build (project.xml). Not all of them have the sam

              • Having been down that road, I know why people do it at least. The number of things (like you, log4j) that expect to find their configuration files in the root of the CLASSPATH means it's much easier to just throw things in with your source and copy them into the build tree...

                Yeah, I know why they do it too, but I still don't like it. It's just as easy (and IMO less confusing) to create a 'conf' directory and put that on the classpath. But that's a minor quibble.

                • Having been down that road, I know why people do it at least. The number of things (like you, log4j) that expect to find their configuration files in the root of the CLASSPATH means it's much easier to just throw things in with your source and copy them into the build tree...

                  Yeah, I know why they do it too, but I still don't like it. It's just as easy (and IMO less confusing) to create a 'conf' directory and put that on the classpath. But that's a minor quibble.

                  Ah, but if you're using an IDE like Eclipse, it automatically copies stuff from src to bin. And so the rot sets in. "It works", why change it...

                  -Dom

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.