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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday December 01, 2009
09:27 AM

Why Should I Program in $Language?

[ #39967 ]

For the developer evaluating programming languages the question of which languages to learn rarely involves "can this language do what I want it to do?" This is because virtually all programming languages (except ANSI SQL, if you consider it a language) are Turing Complete. Instead, what I see, over and over, is discussions over two things:

  • Can I get a job in this language?
  • Do I like this language?

So consider COBOL. Yes, I can get a job in that language, but do I like it? No. C is the same way for me. There are plenty of jobs out there, but I loathe how close it is to the metal because I like solving problems, not worrying about how to reallocate memory for a resized string. So if I were to assert that either COBOL or C is dead, that might be true ... for me. If I assert they're dead on the basis of job stats, I'd be sorely mistaken.

Naturally, when I hear the old "Perl is dead" saw, I know the job stats and I know they're not referring to them. However, what they invariably refer to is the "buzz" around Perl, measured by TIOBE, Google Trends and other tools. The buzz can be important, but at the end of the day, buzz won't matter if the tool is useful enough. Consider how much people complain about Perl's sigils. Now look at the following code:

$cssClass = "";
if ( $element->isOpen() ) {
    $cssClass = ' class="selected"';
}
if ( !$element->isHiddenInNavigation() ) {
    $filepath = $element->getId() . ".html";
    if ( substr( $element->getFilePath(), 0, 4 ) == 'http' ) {
        $filepath = $element->getFilePath();
    }
    $result .= '<li'
      . $cssClass
      . '><a href="'
      . $filepath . '">'
      . $element->getLabel() . '</a>'
      . $this->generate( $element->getChildren() ) . '</li>';
}

Assuming that has no errors, we know that it looks like Perl, but isn't (look closely if you don't see it). That's PHP code. So though people whine about sigils in Perl, you've got the same issue with PHP, but why has PHP crushed us in the Web space? Well, for one thing, people seem far happier with modphp than mod_perl. It's very easy to develop and deploy apps despite its inconsistencies and lacking many of the useful features that Perl 5 has.

A second issue, however, is the one which will continue to keep Perl 5 sneered at:

public function setHiddenInNavigation($hideInNavigation) {
    return $this->hideInNavigation = $hideInNavigation;
}

That's PHP, too. Until we can make Perl 5 code that clean and simple and in the core[1], we'll continue to be sneered at. It's embarrassing to read through PHP code and, once again, sigh at basic, basic things Perl 5 is missing (yes, PHP is missing many things too, but I'll bet most 9 to 5 programmers would take method signatures over closures any day of the week).

So really, programmers are asking if a language can do what they want it to do; at least on a syntax level. That's because syntax is a large part of the aesthetic appeal of a language.

So in answer to the question "Why Should I Program in $Language?", what the language can do (functionally, not syntax!) isn't really the issue. Nor is the "are there jobs?" because we know there are plenty of Perl jobs out there (not in all areas, though). The real question is "will I like it?" and from the numerous Perl hate posts, this is very much an open question but Perl largely has itself to blame.

1. We have a better object system than you do! Just install Moose (but be aware that it might have backwards-incompatible changes in a few months). Oh, to install it, you just need to configure CPAN. What? You don't have root? Here's how to configure CPAN to install in a local directory. And be aware that Module::Build and ExtUtil::MakeMaker take different arguments, and don't forget that ...


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Why Should I Program in $Language? 24 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Did I hear in my vague readings of p5p that this might be possible in 5.12?

    If so, it'd be SO nice to have:

    class Foo isa Bar {
      method init(%options) {
        $self->{some_key} = $options{some_key} // "default";
        ...
      }
    }

    • FYI, MooseX::Declare provides exactly that already (except you inherit with "extends", not "isa").

      • Yeah I know, but it's very heavyweight (brings in Moose).

        • Plain Perl OO is also very heavy, it brings in perl and entire OS. Are you sure that bringing in Moose is a legitimate concern, or are you just afraid to look at something popular out of fear that it might turn out to be better than complaining?

  • We have a better object system than you do! Just install Moose (but be aware that it might have backwards-incompatible changes in a few months)

    What changes in a few months? I am not aware of such plans. We are generally highly responsible about our backwards incompat changes. Changes happen and sometimes they are hard and ugly, this is the real world after all and they need to happen. But ...

    I suspect your just being sarcastic and playing the devils advocate here. Your right, having a decent object s

    • Yes, I am being a bit sarcastic, but more than once we've not been in a position to update Moose on our BBC project because of Class::MOP (and this has happened with Catalyst, too). The most important Perl projects and the ones we depend on are the ones we have difficulties keeping up with. Even if you rarely change Moose, or Class::MOP, or Catalyst, or [insert favorite module here] with backwards-incompatible changes, then you have to consider the chance of said changes happening in all of them, not just

      • Yeah I know, I still have servers running Moose 0.24, so I am with you. We have been discussing trying to make these things smoother in various ways so that people can upgrade and say, get a performance improvement, but opt out of a feature/API change. Similar to the use feature in 5.10. It is still not perfect, but it might help ease those of us (me included) who have to deal with production environments all the time and for whom upgrading it usually not an option.
    • I'd be happy with a decent object system that is not in core if it didn't require half of CPAN as prerequisites. Here at work, I have yet to be able to resolve all of the dependencies. As soon as I get a minute or two to spare (wishful thinking really), I might actually be able to track down the troublesome module(s).

      • It shouldn't take too long since you only have 16 [cpantesters.org] non-core dependencies to go through. FWIW, I am pretty sure there are more then 32 modules on CPAN now, it has grown a lot in the past few years ;)

        Sorry, couldn't resist. But in all seriousness we would be happy to help with this either on IRC or the Moose mailing list. The biggest problem I have seen when installing Moose on a bare bones system (and yes I have done it many MANY times so I am empathizing and not mocking) is that we require more up to date

        • Stevan, I just don't have the bandwidth to deal with it right now. As soon as things slow down here to only a relatively hectic pace then I'll try it again.

        • I bit the bullet today and finally got Moose installed.

          I installed the prereqs one by one starting from the bottom of the list. Once I thought I had them all installed, I tried to install Moose and it couldn't find about five of the prereqs so I bailed.

          I tried to install each of them again only to be told that four of the five were already installed. Class::MOP just did not want to install... Or so it seemed.

          I traced the problem to the order of my include paths. Once that was fixed, Class::MOP and Moose ins

  • but the answer is simple to me. Because it's alot easier to code in PHP. You just need a standard hosting package somewhere and you'll have PHP. If you need a script being installed, just drop it somewhere in the webspace and tada - it's running. You don't have to put it in special locations like cgi-bin, just drop it somewhere. Yep, it's a sad thing - I'll stick with Perl. Which seems to be something which can't be understood by the PHP people around me....but they are starting to understand..

    • It is simple to configure to run .pl as perl for Apache. But I prefer security of cgi-bin. It means that none will be able to download my non-executable files like templates or data files.

  • sub setHiddenInNavigation {
      my ($this, $hideInNavigation) = @_;
      $this->{hideInNavigation} = $hideInNavigation;
    }

    really isn't any worse than the PHP version. Sure, you gain an extra line, but you 'sub' is shorter than 'function', and you can lose the 'return' and 'public'. So, less typing overall.

    • What happens if you call it with 17 arguments? A signature can guard against that. Second, what happens if you misspell the hash key? You may or may not get an error at that point, but have it happen later on (if at all). PHP's version will have a failure when calling a non-existent method. (I also hope that PHP's syntax allows validation rather than blanket assignment, but I don't know it well enough.)

      • What happens if you call it with 17 arguments? A signature can guard against that.

        You'd expect that to be the case, but it isn't in PHP. PHP actually handles that exactly like my Perl version---it ignores the extra 16 arguments. That's how PHP implements variable numbers of arguments. So, PHP's method signature's have fooled you.

        Second, what happens if you misspell the hash key? You may or may not get an error at that point, but have it happen later on (if at all).

        This is indeed one drawback to the use of hash keys for object variable storage. But... PHP does the same thing. It'll happily create that variable for you on assignment.

        (I also hope that PHP's syntax allows validation rather than blanket assignment, but I don't know it well enough.)

        Not sure if its been added in PHP5, but 4 didn't.

  • Was that all pretty much just saying "we need an object system in core?"

    +1 for sentiment, but we need more than sentiment. We need a plan that p5p supports. (And, probably, a long-term feature branch in the core to prototype, test and get buy-in around.)

    As for the toolchain footnote, you're right, which is why I'm working on things like this [dagolden.com] and this [dagolden.com]. It can get better and it will get better.

    -- dagolden [dagolden.com]

    • Was that all pretty much just saying "we need an object system in core?"

      We need an object system and function/method signatures.

      We need a plan that p5p supports.

      I have no idea how to create this.

      • The function/method signature issue is very problematic because part of that deals with the philosophy of Perl. I, for example, sometimes find that static binding (compile time) of methods would make some problems magically go away, but I doubt that Perl 5 will ever be able to support that. Of course, signatures also might imply multimethods. That's another issue which would give people fits. Should all methods be multimethods or should we have to specify this directly?

        • Here's a secret, though: Perl 5.12 or 5.14 or whatever doesn't have to support all of those features to have useful function/method signatures. Even supporting only required positional parameters is useful for some 80% of extant code.

        • Considering all of this stuff already works in Perl 5 and is limited to a given lexical scope, I am having a really hard time seeing how this is 'impossible'.

  • The 1999 standard added common table expressions, and the 2003 standard added window functions. Those made it Turing complete.

    See http://assets.en.oreilly.com/1/event/27/High%20Performance%20SQL%20with%20Postgr eSQL%20Presentation.pdf [oreilly.com] for details.

    • That is cool. I was used to calling them analytic functions from Oracle, and googling for "analytic functions" and PostgreSQL only brought up posts from people wanting them in PostgreSQL. Now that I know that they're "window functions" they're easy to find:
      Window Functions [postgresql.org]
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.