Slashdot Mirror
Does Company-Wide Language "Standardization" Work?
RMX asks: "In our company, we're currently going through the debate of standardizing on a computer language for our next set of products. The pro-standardization guys say that a single language (like Java) will save everyone time. The anti-standardization guys are advocating a mixed environment (of languages like Python, Ruby, and C#), and argue that the whole discussion is as silly as a manufacturing firm standardizing on screwdrivers for all their screw/nail/glue fastening needs. Have any of your companies standardized on a language? How well did it go?"
at the pharma company I work at. We were all java, C++, LISP, Smalltalkers before. It's been four years now, and it was a wise decision. It's a very adept glue language that has been easy to integrate with other systems, both at the source code and network level. YMMV, and I think perl or ruby both fill this niche well too. We just wanted to have a standard platform for new development, and have been pleasantly surprised that python has been a productive choice for legacy integration and utility tasks as well. We had a requirement recently to integrate with a Java system. I used jython and it took three days, with no curly braces to be seen. We get a lot done every day now, and it's quite motivating.
There are two issues here: using a single or mixed language approach for a particular application, and using a single languange (or not) across an entire organization for all projects.
I worked for a long time at a big national lab that was mostly a FORTRAN shop. They wanted to use FORTRAN for everything, and it was technically a bad choice for everything, but culturally it was the only solution that would fit without causing a jihad among the old timers. I much prefer C++ for these sorts of things (big complex simulations that must run fast), but had little success in converting the masses, even though it was always faster, more portable, much easier to maintain and handle complexity, and also you can actually hire good C++ programmers.
We were able to do some mixed language solutions (C++, FORTRAN, C, perl, etc.) and they were a nightmare to maintain. in hindsight, I think it would be better to keep the apps all in one language rather than mixing. The biggest problem here is portability. These applications have incredibly long lifecycles, and the platforms change severals times underneath you, which seems to affect the inter-language interfaces the most.
Anyway, it depends a lot on the type of application, lifecycle, target platform(s), etc. but I think in general it is best to pick a single language if at all possible for a particular application that is the best single tool for the job. But, if a different application would be better suited for a different language, go with the different language. Mandating a single language policy across an organization for all projects is counterproductive: use the right tool for the job.
> Ada was developed by the DoD precisely because they wanted to have one programming language for the entire US department of defense. Naturally this was a massive undertaking. The programming language had to be all things to all people, and thus grew very, very large.
:)
That was a popular critique 20 years ago, but these days people tend to criticize it in the opposite direction (i.e. no standard class library).
> The problem with this large programming language is that it is so complex that most programmers can't know all of it, and they only use a part of it. That, in turn, becomes a problem whe two sequential developers on the same piece of code know different parts of the language, and the second developer can't read the first developer's code.
I don't think that's correct. I'll be the first to admit that I don't know every obscure feature, but then I don't use it professionally either.
> It also produces a few problems in trying to build a correct, compliant compiler
I have heard that that was true when the spec was first published a generation ago, but any such problems have long since been solved.
> So the point here is that "standardizing on one language" has been tried before, and it was a huge flop.
But a political flop rather than a technical flop. By the time the DoD was ready to start using it everyone wanted to program in C++, and the administrators were giving out waivers like Halloween candy.
Also (as often seen by people's ill-informed comments about it on Slashdot (no, I'm not referring to your post)), Ada has an unjustified bad reputation based on ignorance, such as the oft-encountered claim that the first Arianne 5 rocket crashed due to a problem with Ada, and oft-encountered quotes from Hoare (saw it as a Slashdot cookie earlier today, as a matter of fact) that was actually a critique of an early draft of the language. Much of Hoare's critique was addressed in the final project, and of course we've had the '95 spec since then. (And an 0? update coming out RSN.)
People who actually use it tend to have a high opinion of it. I use it by choice for my hobby projects.
Also, the switch from complaints about it being "too big" a generation ago to being "too little" now show just how fickle out notions of what a language 'ought' to be like actually are.
Sheesh, evil *and* a jerk. -- Jade
Oooh yes...this is where it's really going my friend...and it's gonna hurt so much...
In time you will realize what is really at stake...and it's not Java or not Java.
I saw this personally. I was working at a very large US telco, which had bought many smaller telcos in a short period of time, all using mainframes really. The old timers managed to make all work together nicely, cobol, fortran, c, whatever, it worked.
First, they "standardized" on Java, and one and a half seconds later, they "standardized" on India.
The problem with us programmers is that we don't think like managers. For IT managers, having outsourced all they could is a VERY GOOD thing and it's the hip thing these days. It's a promotion for them. Go to Amazon and check IT management books. They RECOMMEND it. We programmers just don't see it, it's only natural, we code, we are not managers. It is just like it was Java for programmers in the 90s, you had to try it. IT managers are not there to make sure you have a salary, they are there to make sure they have a salary.
And for India, the only way to get started in the game is to standardize on J2EE: not even Java, J2EE. Most of those programmers (personally seen it) can't override java.lang.Object.hashCode(), but they can deploy an EJB.
What was ludicrous about the situation is that being the company very large and rich, they could actually afford to create the outsourcing company themselves from scratch and "make it profitable". They went to India, found the people, interviewed them, prodded them into EJB programming. They used to show us "before" and "after" photos. (There used to be a field here, look at the data center now)
The code itself...oh my God. First thing I saw was a 15 THOUSAND line jsp page, it was average. The guys down in India where such beginners that the company had to buy a million-way mega server from Sun to keep the "portal" running for at least 24 hours straight, and most of what the "portal" was doing was screen-scraping the mainframes (I am not saying Indian programmers are not good, I am just saying that the good ones are already taken/gone to the US etc).
So, in my humble opinion, yes, you can standardize on a language, especially if you take your management's solution, Java, which is all things to all people, provided you use 10 people to make a 3 page website, use a Sun 100-way machine, and you get custom patches to Weblogic from BEA to your custom problems, since it's included in the multi-million support contract.
But as a US programmer (I am assuming you are) you will be made to eat so much manure, you will be sorry you had'nt left.
Just my two cents from personal experience.