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.

  • What's an "OO" environment? – GrandmasterB Dec 10 '14 at 20:19
  • 4
    Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat Dec 10 '14 at 20:19
  • Object Oriented...maybe using wrong or older term. What is the term for the stacked environment? – VSW Dec 10 '14 at 20:49
  • We know what "OO" stands for, but what kind of environment do you associate with that term, as you are talking about it as opposed to an "IBM mainframe environment"? Is an "IBM mainframe environment" not programmable with object oriented means? AFAIK IBM made a big fuzz about Java on OS/390. – Doc Brown Dec 10 '14 at 21:14

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?

  • 2
    Not to mention what happens if there are three people who suddenly need to work on the same project, with the same files, and only one of them knows PHP because the others were hired when they could choose whatever they wanted to. Then they start complaining "Why does Liz get to choose to work in Python, but I have to work in PHP because Dave made that decision 2 years ago?" – FrustratedWithFormsDesigner Dec 10 '14 at 20:18
  • But when the company picks a language coders don't like...then what happens? Company picks Ruby, upsets Dave and Liz...they walk? Company picks "insert older technology here"...Dave and Liz know it but say it's old...they walk... – VSW Dec 10 '14 at 20:46
  • 5
    @VSW ...and then company replaces Dave and Liz with Ruby programmers that hopefully aren't prima donnas. – Doval Dec 10 '14 at 20:55
  • 1
    @Snowman: I just waited for that "right tool for the job" phrase - in language discussions, someone will always throw this buzzword in. It is not completely wrong, but fact is, for at least 90% of all programming tasks within a company you can choose any of the popular multi-purpose languages, and assumed the programmer has a modest level of knowledge in that language, he can solve the task with it. – Doc Brown Dec 10 '14 at 21:05
  • 1
    @Snowman: I guess we are thinking in the same direction. For example, if you need some custom commmand line tools, it will absolutely make sense to use some kind of scripting language. But it is typically unnecessary to write one tool in Perl, one in Ruby, one in Python, one in awk/bash, and one in VBScript. But that can easily happen when every dev of your team is 100% free to choose what he thinks is "the right tool for the job". – Doc Brown Dec 10 '14 at 21:28

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".

Not the answer you're looking for? Browse other questions tagged or ask your own question.