http://www.perlmonks.org?node_id=1029467


in reply to Is Perl the right language for a large web application?

walikngthecow: this is a good question, that I (and many others) have been wrestling with, from time to time.

In my opinion, in comparison to Python, Perl is more expressive, more powerful, and much neater in its language architecture. I think the Perl sigil methodology is brilliant (namely, that scalars start with a '$', arrays with a '@', hashes with a '%' and so on); that the operator determines the expression context, instead of the variable type; these and several other pillars of the Perl language make it really distinct.

On the other hand, many areas of the Python language seem like a kludge (for example, its regex implementation, and its implementation of array slicing).

If you know Perl well - if you have mastered Perl - then you have in your possession a considerably more powerful tool than Python.

Some additional considerations:
1. On a sizable web project, you need to use a tool - I understand that "Catalyst" is a popular one - but I've never used it. I have been using wxPerl.
2. It seems to me that the user base of Python is much, much larger than that of Perl (maybe because of the rumors that Google is using Python internally?) and that the Perl user base is slowly shrinking. A couple of years ago, there was a resurgence in Perl, since the biology departments, in universities, have discovered that it's convenient (and powerful) to use Perl for manipulating genome sequences. But since then, it seems that Perl usage is flat and decreasing.

Helen

Replies are listed 'Best First'.
Re^2: Is Perl the right language for a large web application?
by space_monk (Chaplain) on Apr 19, 2013 at 07:51 UTC

    Lots of companies/organisations use Perl extensively on sizeable projects - the BBC, LoveFilm and GlaxoSmithKline are 3 I have personal experience of.

    One thing that puzzles me is that PHP seems to be the standard web development language, even at enterprise levels. I can appreciate it is perhaps easier to program in, but the fact that its performance seems to be some way behind Perl leaves me mystified as to why it is a choice for large scale projects.

    I develop in Perl and PHP, finding that the former jobs are less available but more demanding and more rewarding, whilst the latter keep my bank balance afloat till the next Perl job.... :-)

    If any of my proposed solutions have minor errors, it's because I don't waste my genius on trivial matters. :-P
      I think PHP does appear easier, since you can usually read exactly what's happening and people recognise the PHP doing stuff within a familar HTML structure. Although maybe that's with dancer etc now - it's a long time since I used perl CGI. It's also the case now that people assume that PHP is the thing to use. Poeple even talk about the LAMP stack (which is pretty standard and powerful, I have to say)

        One of the main reasons PHP is easier for a lot of newbies is that their web hosting company has already set things up to make things as easy as possible. Just rename one of your HTML pages ".php" and you can start sprinkling in some code.

        Perl, if your web host supports it at all, is probably running via CGI (fine for small scripts, but not the most efficient method for large scale projects); modules that could make your life easier, like Plack, may not be pre-installed, and installing them without root access may be non-obvious; for people who have never touched a Unix command-line before, even trivial things like chmod +x represent a major barrier to entry.

        This is fixable but would require co-ordinated effort from the Perl community. For example: a web-based control panel to make it easy to manage local::lib directories, and which would also provide one-click glue between Apache and a PSGI application. (Plus evangelism, evangelism, evangelism to get this widely pre-installed by major hosting providers.)

        While PHP is easy to get started, it also has drawbacks that make PHP development harder in the long term for bigger projects. Until very recently, namespace management was poor, meaning that every part of your code had to be careful not to tread on every other part's function names. All functions lived in a single flat namespace. (Class methods being an exception.) Namespaces were introduced in PHP 5.3, but are not yet widely used. None of the many, many, many built-in PHP functions are namespaced. Most large PHP projects (e.g. Drupal) still use a flat namespace.

        PHP's OO model is less flexible than Perl's too. With the recent addition of traits, it compares favourably to languages like Java and Python, but it's still not up there with the mighty Moose. With fewer options for recombining different bits of code into different objects, DRY can suffer.

        There are other things, but I won't bore you all.

        Incidentally Dave, we appear to live around the corner from each other. (On a planetary scale at least.)

        package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name