1) would they rather use a knife than a screwdriver to undo a screw ? Choose the tool most appropriate to the task at hand - dont use a candle to melt steel and dont use an axe to slice bread. Most developers (rather than managers) will tell you that developers who know several languages are almost always better developers than mono-culture ones. And solutions that use several well integrated, task-oriented language componenents are better than one huge, monolithic, ill-adapted single language design.

If you have four developers who are handy with Perl, Java, C++ and SQL, surely they can achieve vastly more than four purely Java developers.

A building company that only has plasterer's could in theory build a house completely out of plasterboard, but would you really want to live there ??

OK enough with the analogies

2. Does C generally have a pretty IDE ? Is it suitable for large scale development? Perl has Komodo from ActiveState if a developers are so imcompetent that coding without a GUI is impossible. If a developer said you can't code seriously without a GUI, I wouldn't hire them.

Perl has an excellent debugging/introspection available via the -d switch, the Devel::ptkdb GUI debugger is superb, debugging tools include the Deparse modules and Data::Dumper, Perl allows the examination of @INC/%INC and symbol tables, the strict pragma and -w switch catch 80-90% of stupid errors straight off, flexible logging via Log::Log4perl, you can design with extensive parameter checking with Params::Validate, the wonderful Test::Harness framework will save you a fortune in time, money and frustration. I could go on.

Web-work - they can't be serious. I wont even to begin to detail the absolute myriad of rock-solid, flexible, powerful frameworks Perl provides for web development. Unless they want everything done in Flash, Perl is easily a superb Web development tool - and infinitely superior to developing for the web in Java.

GUI work - OK, they have there first genuine point here - Java is better than Perl for GUI development.

3. There's nothing you can do in Java you can't to in binary. That's not a good reason for doing everything in binary. Similiarly for choosing Java over Perl.

As for speed - runtime or development time. I can't think of too many cases where a Java developer will spend less time than a Perl developer implementing the same functionality. It doesn't matter if it took 5 hours to run or 6 hours, if Perl took a week to write and Java took a month. If raw speed is a criteria - do it in assembler/C.

4. Well if an implementation is reject just because it is written in Perl - regardless of whether it works and actually satisfies the design, your screwed.

Why not have a coding bake off between their best Java programmer and their best Perl programmer. A set of 10 exercises to be implemented correctly in the shortest space of time. I bet the Perl guy would win. By days...

hopefully others can provide links to the myriad of articles about how good Perl is.

One last point that may break their 'perl is for scripting' mind-set - Perl is a PROGRAMMING LANGUAGE and an extremely powerful one at that - in fact one could quite easily argue that, featurewise, Perl is much more powerful than Java.