Our company is moving from IBM mainframe environment and coding, to an OO environment. Is it possible...or is it correct/plausable to NOT have any standard whatsoever with regard to the server side language of the OO environment we move to? Is it normal to say "Dave works in PHP" so all things he does will be in "PHP"...and we'll hire Liz who has Python..that will work too. Dave works on a financial application in PHP, will Liz does time cards in Python. OR would it be better to say.."Company ABC programming standard is Python..." Dave has to learn Python, and Liz is ready to rock and roll with the company. I'm just trying to know what an OO environment looks like with regard to standardized language or free do what works best for the situation/coder environment.
closed as primarily opinion-based by Doc Brown, gnat, user40980, amon, user22815 Dec 10 '14 at 20:55
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
Typically, companies standardize on a single language for a variety of reasons (tool support, talent availability, interoperability, etc). I've worked for some companies that used multiple languages, but they were the exception. Having individuals pick their own technologies is usually a recipe for disaster. When the PHP guy leaves, if nobody else knows PHP then who takes over his code? And do you keep it in PHP or will you wind up rewriting it in the "new guy"'s language of choice?
It should be pretty obvious that if you have two or more persons working on the same program, they need to use the same language, or at least the same (small) set of languages. So when there is is only one team or department in the company who does software development, they will typically not make their lifes harder by unnecessarily chosing a new language for every new program they have to develop.
The real world situation looks often like this: in lots of companies of reasonable size, you will find different, independent teams or departments, which chose they toolset some time ago for a specific programming task. And if the teams are working independently, the chances are high they make different decisions about the programming language. The bigger the company, the more likely this will happen.
After a while, most companies tend to change their structure, for example one department will be closed or cut down to half of the people, or the programming tasks are "outsourced" to a different department, which can easily lead to a situation where another department has to take over some existing software packages for maintenance. Or two former independent departments have to work together on a common software project. This will quickly leave you in a situation where one team has to manage different programs in different languages. And that is IMHO the "norm" for lots of companies I have seen before - not because "it works best", but because "that's the way it works".