in reply to Is Perl the End-All?

Reliable and performant multi-threading applications, like advanced graphic-intensive GUIs, are probably the most visible problem for Perl right now. Any operating-level code is out, too, since Perl is based on C, and the standard C library functions are in general not reentrant. That probably also eliminates Perl for a lot of embedded device code.

Another, more disturbing problem for me is that, IMHO, it is very hard to develop with large teams in Perl, since there is no means to express the interface of a function in code. You have to rely on POD to document your interfaces. This makes it very hard to check programs for interface consistency. Also, the variety of parameter passing idioms ("my $arg = shift;", "my ($arg) = @_;", "my %named_args = @_;", "my ($fixed_arg, $ref_to_hash_of_options) = @_;", "my ($fixed_arg, %hash_of_options) = @_;", etc.) in Perl makes for a nice array of hard-to-find bugs when combined with lack of documentation.

That said, for small teams or single persons Perl is *the* most productive language I have seen till now. This is largely because of the amazing CPAN. Says Bruce Eckel (in: Thinking in C++. Prentice Hall, 1995. Translated from my German version.): "The only possibility of achieving really impressive increases in productivity is using other people's libraries."

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Replies are listed 'Best First'.
(dws)Re: Re: Is Perl the End-All?
by dws (Chancellor) on Aug 31, 2001 at 23:29 UTC
    ... it is very hard to develop with large teams in Perl, since there is no means to express the interface of a function in code.

    In discussions like this, it helps to quantify "large". For someone who has been working solo on 300 line CGI scripts, 3 people and 10,000 lines of Perl might seem large. For someone who has worked under the covers in, say, a large open-source project, 3 people and 10,000 lines of code may seem trivial.

    Here's a data point: I've worked inside of a system that had 80,000 lines of Perl (not counting the CPAN components we used), of which the Perl part was about half of the code base (other parts where DHTML templates, some Java, some C++ for web server plugins, and a bit of SQL). The product was developed by a core of around 6 developers, and maintained by a core of 4, with quit a few non-core people contributing. In Perl, we had about 50 classes for major objects (and at least that many classes for helper objects -- I didn't read the entire code base, so there may have been twice that number). The lack of first-class support for interface specification was not a major impediment. The major impediment was getting new people (a) up the Perl learning curve, and (b) getting them up to speed on the theory of operation of the product.

    We did use POD, though we put more effort into keeping it up-to-date than we spent reading any of it.

[reply]

      Thanks dws, I am glad to hear that.

      The biggest Perl based system I have worked with till now is a commercial content management system called "Imperia" that has a little bit more than 175.000 lines of Perl code (with comments) in the last version I worked with.

      I agree with you that "theory of operation of the product" is the biggest impediment in learning to work with such a system, and Perl is not a trivial language in itself, too.

      Still, I find it very annoying that in Perl, your only option to be sure how a function is called is to wade through the actual big lump of code. And you can't auto-extract this information easily, either.

      Christian Lemburg
      Brainbench MVP for Perl
      http://www.brainbench.com

[reply]
        And how many lines of code do you think that system would have been in another language?

        I absolutely agree that Perl does not offer a lot of support for developing large software systems maintainably. But a lot of that is due to the decision to make a small amount of Perl do what would take considerably more in another language.

        "Keep it small" is a valid approach to maintainability for many kinds of problems. It is one which many languages lose sight of. But it certainly isn't a magic bullet, and I wouldn't be surprised that a 170,000 line project in Perl could get painful.

[reply]

In Section Meditations