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

2 of 654 comments (clear)

  1. We settled on python by ubikkibu · · Score: 5, Interesting

    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.

  2. Re:Solutions Should Be Natural by MonaLisa · · Score: 5, Interesting

    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.