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.

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

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.