I'm not so sure. Our department, one of many working on a largish product, uses: Perl, Java, Shell, C++, Visual BASIC (although I'd like to replace that with Perl), batch files (again, trying to replace that with Perl - it's just a matter of time). And, of course, makefiles. Of this, the Java, Shell, and C++ code is shipped - Java and C++ are only shipped as binaries ... although even the Shell, we don't ship the source code. Our shell scripts are done in a template format first (based on Text::ScriptTemplate), and then "compiled" to be platform-specific, allowing us to target platforms a bit easier with a bit more flexibility (e.g., shell code needed on AIX may not even be parseable on Linux). We ship the results of the template processing.

It's all about the right tool for the job. Java is used for GUI. Shell is used for filesystem manipulation (on machines that may not have perl installed - our end-users). C++ is used for all the heavy lifting. Perl is used in our build environment for filesystem manipulation and string manipulation, including generating C++, Java, and Shell code. VB/batch files should be done via perl, but this is where your point comes in - there's only so many perl people on the team, so when someone needs something windows-specific, they don't ask us, they just go do it the way they know how. My counter-point? They do things inefficiently and in a way that is not extendable. It works because they hardcode so much stuff in there - and then when the requirements change, they need to make drastic changes to unreadable code. While on the perl side, I modify some data files (string manipulation, anyone?), and I don't even touch the code. In case you're wondering, even the Java guys can update the data files. There's no perl-isms in there. At least, they're not obviously perl-isms - you don't need perl experience to understand them. If we were using Perl where we're currently using VB/Batch files, it would be more work up-front, but changing requirements would be met way easier.

Short version of this node: I respectfully disagree. ;-)