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.
  • 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 ID

    • I'm all for it to treat perl5 as a different language than perl6, but all we've seen from perl5 the last 4 years are maintainance releases. We only have had one major release of perl5 since the perl6 project started, and that was in July 2002 with the release of 5.8.

      I also encounter people that wonder what's happening with Perl - but those are people that use a large toolbelt, of which Perl is one of the tools. They're aware of perl6, but they don't really care about that. They do wonder about the slow pa

  • So he says (I'm paraphrasing from memory), "At my shop (a medium-sized investment bank) the amount of Perl that people are writing is really going down. People are writing a lot of JRuby and JPython because the Java libraries have gotten so much better and Perl 6 hasn't come out."

    I tend to think of FUD as malicious. This guy was just giving you the scoop from where he sits, sounds like it might have been a soliticited comment.

    Not every opinion we might find troubling is FUD.

    In your defense, you later said

  • Perl5 is doing great. The regex engine just got a major overhaul, fixing long-standing bugs. It's very stable and very widely ported. It's very fast (unlike Ruby). People have built great libraries for it to do all those enterprisey things like object-relational mapping. It runs the whole front-end for amazon.com, and large parts of the Yahoo backend, among others. In short, I don't see any reason to worry about when Perl6 might arrive, since Perl5 compares so favorably with the other options discuss
  • "Yes, I hear that people are hearing that Perl is dead.

    It's a little odd because the same number of new commercial projects seem to be happening, it's just that there's less good people around now.

    Which is great for me as a Perl programmer, since the rampant demand for Perl programmers means that salaries are amazingly good at the moment.

    That's a bit of a long term problem, but it means good times for Perl coders."