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.
  • by Mutant321 (8646) on 2008.12.03 18:15 (#66167)

    Regardless of the problems with TIOBE, I think there is at least something of a downwards trend in Perl in certain envrionments.

    There are a few reasons... not being able to find good Perl programmers is one reason given by my company. Also, wanting to standardise on languages as much as possible, especially for new stuff (where Java wins most of the time).

    While I think the Perl community is one of our strengths, it's also a weakness. As you say, there are some people who refuse to acknowledge what's going on around them, as their way is the "only" way.

    Having been working in Java for the last few months, I've seen a few of the advantages. Not really in the language, but in the tools and standards around it. IDE's are one that everyone focusses on. A lot of Perl people don't see the need for anything beyond vim, but the vast majority of people from a Java background (rightly or wrongly) won't touch anything without one.

    Deployment and dependency management are also streets ahead in the Java world. You can build a .war file with Maven and copy it with all it's dependencies into tomcat, and it'll Just Work. You don't even need to worry about which platform you happen to be deploying to, which can be a big issue for some corps (yes, I know this is because of the JVM, but it's still a missing "feature" in Perl). I've managed to work around some of these problems using the likes of CPANPLUS, some scripting, and some third party build/deployment tools, but it's never going to be as robust.

    Unfortunately, I'm quite pessimstic about this sort of thing ever improving in Perl 5. So big corps will continue to phase it out, and the jobs will continue to dry up. Although it'll be around a while, like you say, for COBOL-esque reasons.

    Perl 6, and just as importantly, Parrot, are our only hopes.

    • Not being able to find good Perl programmers is a huge problem. During the summer everyone I knew in the perl communities around Vancouver and Victoria was actively trying to hire people - with limited success. Things have slowed down a bit right now, but I'm told we'll be hiring perl programmers again in the spring, and that's the same story I'm hearing from most of the other startups around me.

      There's certainly no lack of jobs from where I'm standing, and these are all software product development job

      • Lack of talent is a huge problem. Anyone know of a way to measure how many active job seekers list perl in their skillset. That would seem to be a better indicator than # of job postings with Perl as a requirement.
    • To be honest I think the biggest major difference in perl vs java is not lack of an IDE (komodo is nice) but the fact that a mediocre programmer can generally write relatively clean, readable and maintainable java code. Why ? It forces good practices on you. Perl OTOH not only gives you enough rope to hang yourself, it ties it into a noose before handing it over. It takes someone with godlike levels of self control not to (even occasionally) take advantage of the many shortcuts around good programming prac
      • [A] mediocre programmer can generally write relatively clean, readable and maintainable java code. Why ? It forces good practices on you.

        Precisely which features of Java promote maintainable Java code? Is there some magic JVM command-line switch which forces mediocre coders to choose proper identifiers, factor their entities appropriately, adopt the language of the business domain, respect Liskov, decouple unrelated entities, keep their methods small, and write precise and effective tests?

        [PHP's] Ease o

        • Precisely which features of Java promote maintainable Java code? Is there some magic JVM command-line switch which forces mediocre coders to choose proper identifiers, factor their entities appropriately, adopt the language of the business domain, respect Liskov, decouple unrelated entities, keep their methods small, and write precise and effective tests?
          I didn't say it made them GOOD programmers but Java forces OO and makes you do things explicitly (strict typing, etc..). Perl's shortcuts and the level
          • Java forces OO and makes you do things explicitly (strict typing, etc..).

            You mean manifest typing, but yes, Java does. I believe that has very little to do with maintainability in the face of the other factors I listed. (There's also the counter principle that maintainability has an inverse relationship to the number of lines of code. Verbosity is not on Java's side here.)

            PHP derives its syntax from perl and c/java.

            Quick test: for any of the 1200+ global functions in PHP, tell me if the syntax is

            fi

          • I didn't say it made them GOOD programmers but Java forces OO and makes you do things explicitly (strict typing, etc..). Perl's shortcuts and the level of things you can do implicitly lends itself to alot of cowboy type of code. We have all seen the type of code I'm talking about, and many times are guilty of writing it :-)

            Perl has very strict typing regarding scalar/array/hash. Types for objects are optional, although it is convenient, and I use it. For better perl code use Perl::Critic.

            PHP derives its syntax from perl and c/java. It has I believe largely very clear syntax , functions are called functions and not subs , it has a switch statement, predefined vars are not as ambiguous (I'm looking at you $_ ). PHP has come a long way since stuff like register_globals fiasco. They're OO is real and clearer than Perl's.

            Perl also has switch statement. It is just called given/when. Perl::Critic will also help with $_.

      • The argument that Perl's problem is that it allows too much flexibility is very common. But there has always been something wrong about it.

        Surely, any decent programmer is going to want more flexibility. The more things a language can do the better, surely? Even if you don't use some features 90% of the time, the fact that they can be used 10% of the time can only be a good thing.

        The problems that perl has at the moment seem mostly with mindset. Firstly of marketing - there is not one big high profile p

      • To be honest I think the biggest major difference in perl vs java is not lack of an IDE (komodo is nice) but the fact that a mediocre programmer can generally write relatively clean, readable and maintainable java code.

        I think the perception that this is true is the problem. And I don't know how to fix that. I have read lots (lots, lots, lots) of really poorly written Java code created with various IDEs. The IDEs allow people to discover language features that are hidden or require some research, but since they've been found it doesn't mean they understands how to use the feature (or use it properly without later bugs). I'm sure this is not a good thing for maintainabilty. I'm conflicted about tools, esp. ones that genera

    • Having been working in Java for the last few months, I've seen a few of the advantages. Not really in the language, but in the tools and standards around it. IDE's are one that everyone focusses on. A lot of Perl people don't see the need for anything beyond vim, but the vast majority of people from a Java background (rightly or wrongly) won't touch anything without one.

      Deployment and dependency management are also streets ahead in the Java world. You can build a .war file with Maven and copy it with all it's dependencies into tomcat, and it'll Just Work. You don't even need to worry about which platform you happen to be deploying to, which can be a big issue for some corps (yes, I know this is because of the JVM, but it's still a missing "feature" in Perl). I've managed to work around some of these problems using the likes of CPANPLUS, some scripting, and some third party build/deployment tools, but it's never going to be as robust.

      I don't really see this as the problem. Perl as a language / environment is more than "good enough" for most of the jobs it's been used for. Not everybody needs or wants to drive a Volvo, even if it's a good car.

      For many uses Perl is actually a lot better than Volvo, people here know it, but it's quite a leap of faith for new users. Currently it's not too attractive, but that really is not a language problem. It is "just" marketing.

      Please, we must do something to these '99 sites, and have this discussion ou