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

Comments

I just read a blog article on what Google does:

[John Harrison]

http://panela.blog-city.com/python_at_google_greg_ stein__sdforum.htm discusses the fact that Google has three official languages: c++, Java, and Python. It then goes into some detail about the use of Python at Google. It is a worthwhile read.

Re:It's been tried

[Detritus]

Ada is still widely used for critical applications, like avionics and weapons systems. The mandate may be gone, but the language is far from dead.

Re:Pondering further

[Bushcat]

The World RPS Society at www.worldrps.com should be able to help you with this. To quote, "RPS enthusiasts will also learn advanced strategies, crucial for those playing above the level of the recreation player, which throws are illegal and (because RPS is very dull when played alone)..."

And, of course, "Think twice before using RPS for life-threatening decisions."

The Department of Defence Tried This

[Grail]

The USA's own Department of Defence [sic] tried this. Their attempt at standardisation was called Ada. How many people program in Ada these days? That's right, the fringe minority desperately trying to hold onto their Defence jobs... and the lecturers who taught them.

"We at ACME Corp are going to standardise on concrete cinder blocks as our building material."

It's really as simple as that.

Re:Ada

[Crispin Cowan]

Sure, but I consider C++ to be an abomination that needs to be wiped from the Earth: it gives you the safety of C, and the peformance of Smalltalk :)

C is an appropriate language for systems programming, and for high performance/small footprint applications where every last byte of memory and cycle of compute matters.

Statically type-safe languages like Java, C#, ML, and Haskall, are appropriate where space and time are less tight, but correctness matters. Like, it would be nice if your desktop applications didn't bomb :)

C++ is a gross kludge that gives you the appearance of type safety, but doesn't really deliver it. Similarly, you work hard to program in a tight language that is C-like, and then C++ bloats it out and hands you huge, slow executables. IMHO C++ is not appropriate for anything at all.

Compared to C++, Ada is just wonderful :)

Crispin

Re:Solutions Should Be Natural

[16K Ram Pack]

In my experience, I'd rather steer clear of such programmers.

I've had to debug hideous code because developers decided to make use of a technology just to boost their CVs. Programs mixing ADO and DAO because someone added some code and thought they'd try out ADO (even though having consistency in the same program was more important).

My favourite programmers are those who concentrate on delivery. They keep an eye on what's around the corner, but at the same time, have a balanced view of using new tech over old. They get the job done because they have been using the same tools and methods for so long that they know how to handle certain issues, and coding it is almost second nature. Which means that they are more focussed on things like getting the business requirements right.

Definetly true.

[autopr0n]

Unfortunetly there are not really enough non-halfwits to go around. It would be nice if all software could be written by CS-Gods, but that's never going to happen.

It's always better to hire the best, and pay for it, but most bosses don't see the value. And some projects can be done by less then the best, if there simple enough (of course, for a non-technical person to figure out which are which are which isn't always so easy)