1) To consolidate the total number of languages in use by the Competency, leading to more efficient use of staff
Consolidation of technologies to a finite set is good. It is good when many technologies are used as well. I've been in shops that use 3 without a problem. No need for consolidation there. I'm now working in a shop that uses at least 7: 3 different shells, c++, java and perl. It almost works out, but we get a lot of duplication of smaller API functions such as, "getPrice()" like functions. If there is a lot of duplication or inability work due to multiple languages, it is a good move. If there are significant groups using the language, it may be a bad move.
2) Unsuitability of the language itself for large-scale development i.e poor IDE support, debugging support, GUI, Web work, etc - this was documented in the "Mid Range Language Strategy Document" last year.
Large scale development can be done well with coding standards. W/o, any langauge can be a clusterfuck. Java has great IDE and integration support, most likely, because java is very easy to parse. OOP does lend itself to GUI stuff, but Perl/TK DOES allow for it. But because Java's syntax is easy to parse, building gui's from a gui is a little easier, since code can be reimported back into a tool regardless how ugly the code gets.
3) There's nothing you can do in Perl that you can't do in Java. This position was cemented by the Perl-Java bake-off which demonstrated Java to be at least equivalent in speed to Perl and after much grunting this was accepted, except by some "old crusties", I suspect mainly for INERTIA reasons.
If most of your development team can write faster java than perl, then java is a better tool for them. I can write C++ with the best of them. But mine will not be as optimized. It's not a slight on perl. It's jsut a matter of what works for people. It's not about perl being bad. It's about finding a tool that works.
4) In fact with the new design reviews, any Perl implementations will not get past that gate.
Unless you can show that perl is a better tool for the company, you are not going to get anywhere. That will require convincing key people, and many developers, they can code better in perl. After all, it's baout making money in the end.
The only valid uses of Perl are:
1) utility scripting
2) legacy apps
If I cannot write scripts in a sufficient manner in perl, then perl would be a bad idea. If I can't do gui stuff in java well, then java is a bad idea. Whomever wrote that should be sent to a Systems Analysis and Design course. And maybe forced to witness what perl CAN do.
Please help me to formulate a strong argument against these senseless accusations and show him that Perl is a truly elegant language and can do whatever Java does in less time.
Simple. You need to show the pluses and minuses of each. Show how each would benefit the company in terms of interpolation with other systems... with people... You have to show that in the end, more money can be made. That means showing that it can work with current systems, new systems, with new developers, old developers. In the end, you aren't proposing just a language, but a system to work with. If java wasn't addressed in this manner, it too is a bad solution. In the end, a language would be used that no one understands and becomes nasty to implement.
