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

Solutions Should Be Natural

[eldavojohn]

Problems and needs are naturally occurring things.

They take on unforeseen forms with non-standard characteristics. If your tool can't solve the problem or satisfy the need, you build a new tool that does. It's the human way.

Likewise, your company can standardize methodologies and practices all it wants. But should they ever standardize the tools they use to solve problems ... well, let's just say it won't be long before a problem or need comes along that the standard doesn't fit.

And then someone might be tempted to work hard at trying to make your standard fix it and work. They might spend hours re-inventing the wheel. And what will that get them?

Why, the ability to say, "Yep, and we did it all with one language."

The customer doesn't care how a solution is created. They care that it works and meets their requirements. Rarely have I seen requirements that read "... and it must all be done in the same language."

I am a computer programmer. I make computing devices do what I want. I will use any tool at my disposal, to hell with my employer's proposed "beneficial" restrictions.

In my dictionary, fatalism is the inability to cope with change. Adapt or fail. I am required to adapt to each new language I learn and I hope I never get rusty at that. Confining employees to one language does just that, it gives them a false sense of security and teaches them to think inside their box.

Re:Solutions Should Be Natural

[acidrain]

Why, the ability to say, "Yep, and we did it all with one language."

And the fact that I can actually debug all the code that goes into one of our games. I love debugging a C++ callstack that goes in and out of an interpreter a few times. It's bad enough having ten programmers with different approaches to programming without mixing langauges.

Mixing langauges essentially means that a person who introduces a new langauge gets to build themselves (and a few of their pals) a little ghetto where other programmers are afraid to walk at night.

Re:Solutions Should Be Natural

[JanneM]

I got the impression the poster was talking about choosing the right language for a given project, rather than mixing languages within the same project - or mixing languages within a single binary.

Now, embedding an interpreter can be a very good idea in some cases (Think Emacs - or a game like Neverwinter Nights for that matter) - but of course only if the benefits outweigh the pretty daunting drawbacks that you point out.

By contrast, having more than one language in a project may make perfectly good sense if the project itself is heterogenous; you may want to write the web backend in Java while having thin client UI glue as client-side Javascript (and of course access the database with SQL).

And choosing proper tools for a new project rather than habitually, thoughtlessly use whatever you used on the last one is a no-brainer.

Re:Solutions Should Be Natural

[Duhavid]

I've worked with code like that in the "language of choice".

Do these introducers never get asked to justify their actions?

I dont see a problem with mixing languages, as long as the
choice is a defensible one that moves the project forward.
Making project choices on the basis of "gee, this will look
cool on my resume", or "gosh, I really want to play with this"
on any level ( in language or out ) should, generally, be
disallowed.

Re:Solutions Should Be Natural

[Wdomburg]

And then someone might be tempted to work hard at trying to make your standard fix it and work. They might spend hours re-inventing the wheel. And what will that get them?

Why, the ability to say, "Yep, and we did it all with one language."

At the other extreme you've got people writing in whatever they want whenever they come across a problem and end up re-inventing the wheel because either "I don't like Perl!" or "Numbnuts wrote this code in Object Intercal 95, which doesn't have a compiler/interpreter on the platform I need."

And what does that get you?

Why, the ability to say, "Nope, we don't confine our employee's choice of languages." Well that and a morass of code based as much on individual whim as any logical need.

As always, there is a middle ground - having a standard (or standards) with an allowance for justified exceptions.

Re:Solutions Should Be Natural

[MonaLisa]

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.

Re:Solutions Should Be Natural

[rve]

Are you the only programmer at your company?

Support and maintenance costs go way up when every programmer writes his little chunk of the application completey in his own style. By standardizing, on tools, coding patterns, naming etc, a company makes it less difficult for someone to debug or modify code that someone else wrote.

Re:Solutions Should Be Natural

[NitsujTPU]

I have to say that I agree with both your and the parent's point of view, but I think that you're taking what the parent is saying a bit too far.

The parent is speaking of company-wide decisions. It makes a lot more sense to write a video game in C than in PHP, in the general case. It makes a lot more sense to write a web site in PHP, than in C, in the general case. You don't want to force your developers into an awkward scenario by having a company standard tool.

You, surely, can picture the conversation where the writer of the interpreter from your game is told that he cannot use LEX/YACC, because his company standardized on C++. You can't? I was once told this at a meeting.

On your point, however, I can also agree. Needlessly writing code in other languages makes debugging a pain, and reduces your ability to share code inside the project, a place where I imagine that the most reuse is likely to take place.

Still. I can't really see the need for a company-wide decision to standardize on a single language for all of their development.

Re:Solutions Should Be Natural

[Jeremi]

Mixing langauges essentially means that a person who introduces a new langauge gets to build themselves (and a few of their pals) a little ghetto where other programmers are afraid to walk at night.

Just to be contrarian... it can work the opposite way as well. Many of my co-workers are scared of C++, but when I added a Python interpreter to the codebase and started implementating some of the program's functionality in Python, they felt comfortable creating and editing Python code.

Re:Solutions Should Be Natural

[alister]

These kinds of things are usually dictated by a CIO who knows nothing. They are usually pushed by a vendor (either MS or Sun) and after a few dinners, a golf outing or two and maybe a nice watch the CIO makes the ruling that everybody is going to use the same language.

That's ... one way of looking at it. A wrong way, but a way nonetheless. Did you ever consider that each extra language costs money (whether the environments are free or not) to implement? Why should I have four languages that all produce web applications when any one of those four can perform the same tasks as the other three? What possible reason is there to re-invent the wheel three times?

I'm an IT Manager, pushing standardisation. No dinner, no golf (that'd ensure I didn't use that vendor's language), no watch. As to whether I know anything, I guess you'll have to track down the people in my area. The development manager seems to think we're on the right track though.

Alister

Re:Solutions Should Be Natural

[Trejkaz]

Agreed. If an underling wrote bad Java code, I would reject the code review. If they wrote bad Ruby code, I would reject the code review. There is really no difference what language they wrote, if they can demonstrate a reason for using a different one and there are no strings attached (e.g. as there are for anything attached to .NET) then no problem.

Re:Solutions Should Be Natural

[DavidTurner]

You have a great point about the difficulties of cross-language integration and debugging. It can be a bit of a nightmare, and is a good reason to develop individual products in a single language.

However...

"Where other programmers are afraid to walk at night"? What kind of "other programmers" are we talking about here? Speaking for myself, I have little time for programmers too afraid to venture outside of their "comfortable" language. Particularly if they then have the gall to describe themselves as "developers".

Software engineering is language-neutral. If you can do it in pseudocode, you can do it in Lisp, C, Pascal, even (heaven forbid) Visual Basic. As many others have pointed out, some languages are better suited to certain tasks than others. One of your responsibilities as a programmer is to know which languages are appropriate for the task at hand. Blindly hammering away with C or Python or whatever is a sure road to obsolescence.

Re:Solutions Should Be Natural

[StressedEd]

Many of my co-workers are scared of C++

That's a healthy attitude to have. Once you are scared of the beast you learn to treat it with respect!

The lion tamer that runs into the cage armed with nothing but an innocent air and a blindfold doesn't stay a lion tamer for long;-)

[Unless of course (s)he manages to put the blindfold on the lion, but that is another story and not really a suitable metaphor]

Re:Solutions Should Be Natural

[The_Wilschon]

or "gosh, I really want to play with this" on any level ( in language or out ) should, generally, be disallowed.

Except that "Gosh, I really want to play with this" is, especially among hacker types, probably the single most powerful motivator there is. Disallow that, and not only do you lose out on the drive that hackers have to play with something cool, but they get annoyed and disgusted, and probably wind up working less hard on the things that they are told to work on.

Re:Solutions Should Be Natural

[Confused]

There is really no difference what language they wrote, if they can demonstrate a reason for using a different one and there are no strings attached (e.g. as there are for anything attached to .NET) then no problem.

This attitude may work well in small throw-away projects, but from experience I can tell you, maintaining a mixed language product is hell. Just think about the awful mess you're going to have 5 years down, when you need to do an upgrade. If the whole project is written in one language, you're going to have to find only one replacement compiler/library/development environment - which can be hard enough. If you have a mix of exotic languages, you basically can forget it, just rewrite the whole mess.

The same applies to training. The original developers may have been the biggest guru in the necessary languages, but where are you going to find maintenance drones that are fluent enough in all of them? Training a halfwit well enough to maintain some crappy C-Code is hard enough, trying to train him in C, Ruby, Scheme and Haskell is impossible. And even if you'd succeed, Mr C-Ruby-Scheme-Haskell-Halfwit won't stay once he comes out of training, he'll be gone to the next job before the ink on his new resume dried.

All in all, if you're doing long term projects stay with one language and try not to use too many extra libraries where you don't have the source code available.

Re:Solutions Should Be Natural

[47F0]

Yep, you're an IT manager all right.

Frankly, I think you should standardize on COBOL for your video game product.

A question for you. When you take your car to be serviced, do you feel like effective work is being done when the entire collection of shop tools in the garage fit into a lunchbox?

I've been doing this for thirty years. I have worked, both as management and grunt in highly standardized, and very non-standardized environments.

My take? It's a bell curve. At one end, development anarchy is non-productive, and unmaintainable. On the other hand, you absolutely cannot be afraid of the idea that a hammer is not a universal tool.

Somewhere in the ideal is the notion that it often take more than one tool to do the job effectively - balanced with the knowledge that it seldom takes fifteen wrenches to change a tire.

In general, simply because of human fear of the unknown, or sheer sloth and inertia, a large majority of shops gravitate WAY too far towards standardization. Your development manager DOES NOT WANT NEW TOOLS - it makes their job harder (i.e. challenging) "We're a VB shop - you can do anything in VB. VB Rules". Yeah, well, sometimes that's exactly right. Sometimes.

Sorry, but I promise, whatever the cost of acquiring those new tools, if they're appropriate to the job, not acquiring them costs even more in the long run. Every time. But hey, if all you care about is the next quarterly budget, pick your poison and live with it.

Otherwise, get used to the idea that your mission is going to be constrained and compromised by the fact that you bought the $9.99 tool set at autozone instead of hanging out at the back of the Snap-On tool van learning something. In the meantime, if your business is at all competitive, someone is out there gunning for you - with a little faster gun.

Re:Solutions Should Be Natural

[Bush Pig]

To repeat a quote whose source I can't recall: "If the only tool you have is C++, everything looks like a thumb."

Re:Solutions Should Be Natural

[petermgreen]

the trouble is unless you are prepared to use a purely procedural C style api (and with some of the less conventional languages even if you are) calling cross language can be more work than reimplementing the functionality from scratch. (wrap object in C style api and then re-wrap that c style api for the target langauges oop system) and if some or all of the langauges aren't native code compiled will likely increase your deployment hassles too.

and ofc if you wan't your java code to run untrusted then its going to have to be 100% pure java. Not to mention that using awt/swing components in a non-java window does not appear to be documented anywhere (the jni awt stuff gives some clues on possible ways but it seems to be mainly aimed towards native code drawing within a java window not vice versa).

Re:Solutions Should Be Natural

[TheRaven64]

You dont learn a language, which is just basically a syntax and keywords, you learn abstract concepts like iterations, paralellization, recursiveness, object orientation, etc.

You learn all of these things. Then you look at Visual Basic code, and realise that a lot of other people didn't.

Re:Solutions Should Be Natural

[cduffy]

My environment is all web-based programming.

If that's all you're doing, and there's not a huge amount of variety between projects, and your sysadmins don't write in-house tools which might be covered by this policy, good for you. That said, I'm in an environment where there are good reasons to be heterogenous, and I would object strenuously if there were attempts by someone in management to make that change.

Our core (a large webapp) is written purely in Java. That makes sense -- it should be written purely in Java, and if some developer were to prefer to use Jython or a Java-bytecode-compilable Scheme variant, they'd need to have an exceedingly compelling reason. However, there's more to our company than just the one webapp, and that's where other languages come into play.

For the surrounding infrastructure that supports our code, we have bits written in POSIX shell (mostly related to integration with various components of the operating system -- these would be much more trouble to build and maintain in a different language, and the JVM's limited view of UNIX permissions means that some of their functionality couldn't be implemented in Java at all without writing a JNI module); bits written in Python (most particularly, our framework for using a fully OO inheritance model to build screen scrapers for 3rd-party terminal applications with which we need to integrate. This uses pexpect, a Python-focused variant of Expect [which is otherwise available for Tcl, and also has a Perl variant, but would be a PITA in either C or Java], for the screen scraping bits, and makes heavy use of Python's object model (including some things that Java won't do) to keep the code size and complexity for the actual screen scrapers (as opposed to the framework) at a minimum).

We maintain patches to some 3rd-party OS-level tools which are written in C. We maintain some win32-specific tools, including an installer (written in a custom language just for the purpose) for a package of items to be installed on our client systems. We've patched the DSDT tables used to initialize the PCI bus on our servers before (large systems which were given to us by a partner free-of-charge) and written our own SCSI drivers (to be able to use a tape jukebox which we picked up nearly for free). We couldn't conceivably do all this in one language.

If we'd been hamstrung to use Java for everything, the Windows installer would have been a pain. The screen scraper integration code would have been almost unthinkable to write in-house, and we would have licensed a (hard-to-use and expensive) API from a 3rd party. We wouldn't have been able to write the remote client support tool based on the UltraVNC SC client (the first version was literally put together overnight; the upstream code is C++). The system administration tools would have been written in shell in violation of the policy, because convincing sysadmins to write their tools in Java is pretty much unthinkable.

That said, things are still broken out. The core dev team, which is most of the coding staff, only needs to know Java (and in many cases SQL). The system administrators only need to know POSIX shell, Python, PHP, SQL and C (and the entry-level ones can get away with only POSIX shell). The integration developers only need to know Python, Java and SQL, with a little POSIX shell being helpful but not required. The deployment engineers need POSIX shell, Python and SQL, and the most senior of them need C. Just because we have a number of different languages in use somewhere in the company doesn't mean that everyone needs to know everything, and the strong majority of dev staff (the core team) knows only one. System administration, integration and deployment are much smaller groups, so training them is more reasonable. (Further, these requirements are of the form "someone in the department must know", rather than "everyone in the department must know", particularly for the latter-listed languages).

Standardizing on

Re:Solutions Should Be Natural

[Patrick May]

The same applies to training. The original developers may have been the biggest guru in the necessary languages, but where are you going to find maintenance drones that are fluent enough in all of them? Training a halfwit well enough to maintain some crappy C-Code is hard enough, trying to train him in C, Ruby, Scheme and Haskell is impossible.

You could avoid the problem by not hiring halfwits.

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.

Re:Solutions Should Be Natural

[16K Ram Pack]

You are right.

For instance, with your set, would PERL make sense? For me if a developer said that they wanted to add a step to a process as PERL, I'd tell them to just write it in one of the core languages. A 10% time saving wouldn't justify the legacy costs and lack of leverage. On the other hand, if someone suggested that we install Bugzilla, even though it was another language, it could make sense.

In the end, it's about what the most cost-effective decision is. And most of the time, adding a new language doesn't meet that. The most common justification to me is actually switching languages (like companies I know that decided to stop writing new VB and switched to C#, or in my case, making a cost-based decision to switch to Python).

Re:Solutions Should Be Natural

[crawling_chaos]

Disallow that, and not only do you lose out on the drive that hackers have to play with something cool, but they get annoyed and disgusted, and probably wind up working less hard on the things that they are told to work on.

Which causes management to move development to the subcontinent, where such prima donna behaviour is not coddled. You take the man's money, you play by the man's rules. If you can't return value in excess of your salary on those terms, expect to be asking someone if they'd like to Biggie Size that soon.

A while back there was an article on NASA's programmers for the Shuttle's systems. They don't use the latest whiz-bang tools, they work nine to five, and they follow a development model that is so rigid that most coders would quit after the first five hours. They also have never flown a mission critical bug, if I recall correctly. There's not a line of Ruby, no perl scripts, no XML, no fun. Just software that works as advertised. In the end, that's what management wants to build. Your self-esteem is secondary at best, despite what your Kindergarten teacher told you all those years ago.

Re:Solutions Should Be Natural

[Chandon Seldon]

Code for the space shuttle is embedded systems code designed to run on an otherwise obsolete platform. Also, they can easily afford to spend a million dollars per line of code.

Real projects are a bit different. There are time and budget constraints. The choice of programming language(s) is an engineering consideration, and the choice should be made by the same people who would chose data structures and algorithms.

In the real world, working with more than one programming language can save a lot of time and effort. A competent programmer should know most of these languages anyway, and learning a new one is pretty easy.

Re:Solutions Should Be Natural

[16K Ram Pack]

... and then what happens if you then want to put some of the functionality that you wrote in your flat text reader into your web service (for example)?

Multiple languages in your example are only justifiable if I know that the file processing in our key language could not meet the business requirement (like it was overnight processing and would take 20 hours in our key language and 2 hours in an alternative). Even then, I'd seriously consider what else could be done first.

The cost of programmers and delivering the service is a far higher consideration to me than the cost of machines. More languages means more complication and risk.

Re:Solutions Should Be Natural

[TheSpoom]

I'm sorry, but even as a programmer I can see that having your program work and be maintainable is much, much more important than allowing a developer to play with new toys.

Re:Solutions Should Be Natural

[Dekortage]

This reminds me of a guy I worked with couple of years ago. He was a research scientist for a large technology company. The only programming language he knew was LISP. For some reason I don't remember, he was eventually told that he had to begin writing his projects in Java. So he learned just enough to write a LISP interpreter in Java -- and then continued to write all his projects in LISP.

Re:Solutions Should Be Natural

[Chandon Seldon]

Training is a small short term cost with huge long term benifits. There's no good reason not to do it.

depends on what you code

[Pavel Stratil]

Among my collegues we discussed this about a year ago. After doing some performance tests and after trying to write "problematic" pieces of code in some other languages, we dropped the standardisation idea. You either end up with bad performance or some long bizzare code (when you have problems with translation). There are also times where interpreted/scripting languages are of much higher value. Naturally you shouldnt end up using everything...

There are a few languages groups:
Special: Sql, Fortran, ASM
Brute force: C,C++
Object: C++, Py, Java, Ruby, Lua
Scripting: Perl, PHP, asp
High level: Haskel, LISP

As Python, Ruby, Lua are all the same and closely related to Java I definitely wouldnt use all of them. You might be well of with one, maximally two from each of the groups you use (appart from the special group:)).

That's my point of view being a person solving a very wide range of problems. But if you just write stuff that doesnt have much inovation (i.e. basic desktop apps.), a single language might suite well enough.

Re:depends on what you code

[shutdown -p now]

First of all, there is no such language as "ASP". Classic ASP is VBScript/JScript out of the box (and you can also have e.g. PerlScript if you want to). ASP.NET applications can be written in any language that targets .NET, but typically it's C# or VB.NET. Also, it's very interesting how you lump Perl and PHP together and call them "scripting". If it means what it normally does, than why Python, Ruby and Lua aren't there as well? Or did you mean to write "web development", perhaps? but then it's even stranger, because Python and Ruby are also just as good as Perl in that regard (ever heard of those things called Zope and Rails?), and Perl is also a decent generic-purpose language which supports OOP (arguably to a better extent than C++ does, in fact). Lua, on the other hand, is not an object-oriented language by itself.

Also, what makes Lisp high-level over, say, Ruby? And Haskell is a very different thing from Lisp, you know, probably deserving a category of its own (together with Scheme and OCaml).

Then... WTF? Python and Ruby are closely related to Java?!! And Lua, too? Gosh... Lua isn't even object-oriented, for one! Ruby is essentially a bastard child of Smalltalk semantically, highly dynamic, closure-centric - nothing even remotely close to what Java is. Python - it has multiple inheritance and multimethods, again, something Java avoids on purpose. So... er... looks like you don't know what you're talking about, really...

Re:depends on what you code

[Anonymous Coward]

We need a new moderation option: (Score:5, Pwned)

Re:depends on what you code

[root-a-begger]

I agree with your concept of categorizing based on type/style of programming. I don't especially agree with your categories, but that's just my opinion.
About 2 years ago, I went through the same thought process as asked in the original post. I was not encumbered by a large IT department that would dismiss my opinions if I came up with non-mainstream ideas. This led me to a very broad and lengthy search. Here is the result of my quest for an answer:

1 - Application language - Erlang
2 - Brute furce / close to the metal - C
3 - System scripts - Bash

I chose erlang after 8 years of Java programming which was followed by 8 years of Smalltalk. The main reasons for departing the mainstream OO world were concurrency, distribution and conceptual integrity. I found that in large systems what kept me worried most is being able to "prove" that my code worked as the system scaled and became distributed over local and worldwide "clusters". I wanted to be certain that no race conditions or locks occurred (just being able to monitor and restart VMs was not the answer for me). You can get concurrency assurance with Java or any "shared memory" / object pointer based langugage but you need very well written and tested frameworks to fully encapsulate anything that may be touched by more than one thread/process. Solutions like JBoss or other widely encompassing application servers also were not the answer for me as I had to trust that everything the app server did was correct and wading into these projects to find out if things are correct or to fix anomolies is a big challange.
I simply grew tired of writting the frameworks required to encpsulate concurrency and limiting my application code to the nature of the frameworks. Sure, there are many existing frameworks in the Java world that encapsulate the hard work and concurrency for you. But thats exactly the problem: there are many of them. This gets me to the last point of my rational: conceptual integrity. Each Java framework unleashes its own concepts and patterns. I wanted one small set of patterns that are used everywhere. I found this in erlang. It turns out that by making concurrency a first class priority in the language design, the need to invent frameworks and other patterns to encapulate the hard work mostly dissapears leaving behind a clean slate to write your app.

The second category, C, speaks for itself. Occasionally, I need to touch the OS or even bare metal and want a very straightforward way to do this. My C code ends up being very limited, well tested and compartmentalized.

The third category was a tough call. I was tempted to pick Python/Ruby/Lua/Tcl for system scripts. But the bottom line is I didn't really need them and for anything complex, I could write system tools in erlang that were called by Bash. This keeps my usage of Bash simple and maintainable without introducing yet another language.

I realize that my first choice, erlang, brings up the obvious issues of how do you replace programmers easily when you can't find resumes with erlang expertise. I have found that no matter what lagugage you choose, you have to re-train programmers to do things your way and there is a learning curve to introducing anyone new to your IT group. My choice in erlang has not increased the learning curve for good programms I bring on board.

I realize this seems like a giant plug for erlang. It is and it isn't. My rational stands on its one regardless of your choice.

good luck to you...

Re:depends on what you code

[kahei]

As Python, Ruby, Lua are all the same and closely related to Java


Shh! I am getting near my target... the greatest of all game, the beast I have hunted all my adult life... the Complete and Total Idiot!

Many times in the past I thought I had found him -- but now, now I am sure. Mere ignorance alone _cannot_ explain the statement above! The most awe-inspiring thing is the inclusion of Lua, which is so utterly unlike both Python and Ruby in one way and Java in another way! Without the Lua, it would just be factually wrong, and a bit stooopid. Adding Lua, though -- that takes it to a whole nuther level!

Python, Ruby and Lua. All the same. And all closely related to Java.

Magnificent.

Comment removed

[account_deleted]

Comment removed based on user account deletion

That's dumb.

[Max Threshold]

Speaking from experience: use whatever tool works best for the job. Let me guess... the guy advocating using one programming language for everything wears a suit and has never written a single line of code in his life?

Now, one thing that does need to be standardized is terminology. I'm working on a contract right now for a wireless telco. The hardest part of this project was getting managers from various departments to agree on how this system we're trying to automate is supposed to work, and describe it to me in a way that would allow me to translate it to software. Compounding the proverbial six-blind-men-describing-an-elephant problem was the fact that everybody was using different vocabulary.

Re:That's dumb.

[Rix]

I bet you've never driven a backhoe professionally, but still you have strong opinions, based on good business sense, on whether people should accidentally cut off your company's Internet connection with one?

Yes, but I wouldn't presume to tell someone else which brand of backhoe would be least likely to do that.

All languages are the same

[photokevin]

Standardizing on one language is not a problem. "The determined Real Programmer can write Fortran programs in any language".

Re:All languages are the same

[JabberWokky]

Ironically, my fiance's place of work has standardized on Fortran.

It's still the best tool for the job in some fields.

--
Evan

Re:All languages are the same

[AndroidCat]

I've seen COBOL written in Pascal. The horror, the horror...

Re:All languages are the same

[Tablizer]

I forget - does Fortran 66 still have the neato three-way conditional goto?

For backward compatability, I think it still has it. It was something like:

    if x - y (100, 200, 300)


Which IIRC would traslate to something like:

If (x - y) > 0 then goto 300
If (x - y) = 0 then goto 200
If (x - y) < 0 then goto 100

It must have been invented by an octopus. Funky Fifties.

Size of your company

[erbmjw]

It can depends on the size of your company. I worked for a fairly small shop that specialized in Java and SQL work, because of that we became known for it in a positive way. It also was very useful because we all had a decent grounding in Java and our constant work in it had all of us improving our own skill sets quite rapidly.

But the firm had only 9 geeks, so as I said ... small shop. In other situations I can see why multiple languages would be more useful than a standardized company one.

Danger, Will Robinson

[Gorobei]

If you can, avoid the discussion/meetings/emails.

Firm-wide standardization drives are

a) usually politically driven, and if you voice the wrong opinion you will be disliked.
b) driven by the incompetents - if they could do something profitable, they would be doing that.
c) out of date by the time they are finalized.

There is no upside here because there is no magic standard that will make things better.

Pick Two

[Tablizer]

Pick one static/strong-typed language like Java or C#, and one "scriptish" language such as PHP, Python, or Perl. Some tasks will be best suited to one or the other.

Re:Pick Two

[samkass]

I think the parent is exactly right. All the people talking about "use the best tool for the job" have probably not worked very long in the industry. Being able to build on each other's successes, re-use code across projects that gets more vetted with each project, and build expertise with all the "gotchas" in your language of choice will make your company's product better and the company more profitable. These days, you can do almost anything with any of the popular languages, so there's no point in using more than one or two of them.

I'd say, standardize on Java, C#, or C++ (depending on your needs) as your primary language, add your scripting language of choice, then fire anyone who can't handle that. You'll be better off five years down the road than if you'd all built your fiefdoms around the tower of babel and every project becomes a throwaway codebase as the next "best tool" comes along 4 months later.

Any company that can't standardize on a language doesn't really have a coherent vision anyway, and probably is either a bunch of folks pretending to be a consulting firm or will disappear before too long.

(I'm sure I'm going to lose mod points for this reply, seeing what other people have written, but I don't see how any other approach is practical in the long term.)

Re:Pick Two

[dracvl]

Especially when you have languages like Jython available, standardizing on Java and Python makes sense.

Re:Pick Two

[Anonymous Coward]

The best tool for the job is not necessarilly the language the lead programmer likes best.
I've worked in the industry for 8 years, and seen the results of standardising on a single language (or platform) firsthand. It wasn't pretty.

Of course code reuse is all nice and furry, but it's hardly ever practiced.
Far more often you find out after several months writing something that another department has a project doing exactly the same thing (especially in multinationals, sometimes even in the same building, and yes it's happened to me twice).

What is needed is a middle ground between rigidly always using X, and chaos in which everyone uses what seems like a good idea at the time.
Sadly the larger the corporation is the harder it is to get the people making such decisions to leave any authority in the hands of the people below them who have to implement them, leading to dictates from up high which are to be treated like gospel.
For example in one company there was a policy decided at board level that EVERY project HAD to be implemented using all IBM technology on both hardware and software.
Web application HAD to be EJB (yes, they dictated EJB, not just Java) with lots of XML using DB/2 as a database and Websphere on AIX as an application server.
No discussion possible.

We went ahead and used JSP/Servlets on HP with Oracle instead, hiding the purchases behind massive smokescreens, and noone was any the wiser.
This was done after IBM themselves advised us against using EJB on Websphere.
We could get HP hardware and Oracle cheaply (fraction of the cost of IBM) and quickly (instead of waiting a good time for delivery), and it was in tests deemed more reliable and better performant.
Now AFAIK the entire serverfarm uses HP and Oracle, and I doubt the board knows about it...

We chose Java

[Andrew Tanenbaum]

but then we weren't allowed to use SQL or XML anymore!!

Hello Mr. Rumsfield

[woolio]

Problems and needs are naturally occurring things.

They take on unforeseen forms with non-standard characteristics.

Are you talking about the "known unknowns" and the "unknown unknowns" ????

Like a single screwdriver?

[PornMaster]

Why wouldn't it be more like standardizing on torx vs. phillips head, or standard vs. metric?

We all know that monoculture can be bad. Besides platform uniformity, strict monoculture opens you up for enterprise-wide vulnerability, and even getting people with a similar, closed mindset. But it also provides for the ability to have a common dialogue with one another. It can be a shared jumping-off point. It keeps you from getting screwed when the one guy at the company who knew mindfuck leaves, and nobody else knows how to read his code.

There are costs and benefits to having, and to deviating from, a standard operating environment. Deviations should be allowed, but the deviations shouldn't be up to the developers, they should be weighed by management (who shouldn't be idiots), and risks and benefits weighed.

Business needs shouldn't be determined by developers. Developers tend to believe in nifty hacks. Code monkeys can love the elegance of using nuance in their code, but there's also a reason that they're not in charge. And it's not just because managers are stupid. Processes may be tedious. They may even be a reason for a developer to hate his job, which isn't good for productivity. Knowing 4 languages, and having the business be dependent upon him may be wonderful from his point of view. But having an employee dictate how things will be done can be destructive to the business. Particularly when he leaves the company for another job, and the new Java guy can't do shit with the Ruby and python.

Some of the pros and cons

[alangmead]

A single language makes each developer easily replacable. You quit, they just hire another Java programmer. If the collection of software you develop with is sufficiently unique (XSLT with extention functions written in both Groovy and Jython on IKVM running under .Net) you can create a position that would be nearly impossible to fill.

On the other hand, having each developer work on projects with their own collection of technologies tends cause the maintainance tasks of those projects go back to the original developer. This is generally a bad thing. Having a developer know that no one will ever see their code gives a temptation to take shortcuts that they wouldn't take others. Even more than code reviews, splitting maintanance across developers encourages quality code. You don't want a co-worker cursing your name as they try to add one minor feature to something you've done. ("F'n Andrew! Why'd he do that!").

Different languages and other technologies have their strengths and weaknesses. If they are chosen based on their strengths and not just their familiarity (let alone out and out prejudice) then their should be productivity gains achived from the choices. Of course, that means that this would increase the ramp up time a new developer needs to be very productive.

So if you have high turnover, you want to get new developers productively quickly (which would imply standardizing on as few languages and technologies as possible) and you want to get projects seen by as many developers as possible before the original developer leaves. (If Andrew is long gone, then "F'n Andrew!" can be an excuse given by the maintainance programmer, even if it is groundless.) If you have a lower turnover, then developers start getting a better feel over which technology choices fit in which business scenarios.

If this standardization is being driven by upper management, they are hoping to turn the developer positions into a cookie cutter role.

Re:Some of the pros and cons

[WellsDoofus]

"If this standardization is being driven by upper management, they are hoping to turn the developer positions into a cookie cutter role."

-- We agree!

"A single language makes each developer easily replacable."

-- Dream on! At Wells Fargo, they have a bunch of hackers that have no concept of design. If you think a similar language helps, I want some of what you're smokin'.

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:I just read a blog article on what Google does:

[mpsmps]

They aren't dogmatic about it and there are many more languages in heavy use at Google. Orkut is written in C#. Google also uses Javascript/Ajax extensively for many of their client-side sites. If you want a good illustration of how ridiculous it would be to insist on single language such as Java everywhere, imagine if all their sites (e.g. maps.google.com) had to be provided using Java applets.

Pondering further

[deadlinegrunt]

What item should I pick to always win in rock, scissors, paper?

Re:Pondering further

[j-cloth]

Rock.

Next question?

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

Re:Pondering further

[Liquid Len]

Obligatory Simpsons quote:
Lisa's brain: Poor predictable Bart. Always takes `rock'.
Bart's brain: Good ol' rock. Nuthin' beats that!
Bart: Rock!
Lisa: Paper.
Bart: D'oh!

Re:Ada

[Tablizer]

But that group is so 70's. Though I have to admit that I dig "Take a Chance on Me" and "Dancing Queen".

Re:thats just stupid

[gmack]

A few years ago the company I worked for was pretty much all PHP with a couple of projects in perl. I ended up taking over a project and redoing it in C. The downside of that was that when my boss saw that my C based app outdid the perl code it was supposed to replace and could be used to replace some of the PHP as well he started to want to standardize on it.

I've never been quite as nervous as when I was asked if I could redo the websites in C.

Thankfully we talked him out of it and he came to his senses.

Standardise on Logo

[Steven Reddie]

It might seem a little primitive having to do a whole heap of pen up, pen down, move, and rotate commands to draw a dialog box, but imagine how impressed future employers will be when they see on your resume that you developed an enterprise scale distributed system with it.

Better reasons than that...

[cfulmer]

"Save everybody time" is the best the pro-standardization folks could come up with? How about: (1) save training and support expenses for multiple sets of tools & languages; (2) specialists in the language & its quirks can benefit the entire enterprose not just the single group; (3) integration between different pieces of software is significantly easier if they're all in the same language; (4) easier to reuse code; and (5) easier to adjust when developers leave.

It's impossible to know whether it's a good idea in your case without knowing a lot more about what your company does, but in general a bad technical decision made for a good business reason is better than a bad business decision made for a good technical reason. The first one will cause you headaches down the road, but the second will make sure there's no road to go down. The key is deciding which decisions are good and which only appear to be good.

Be sensible

[Julian Morrison]

Like anything else, the answer's "be sensible" - play to your strengths. If your company uses the "infinite monkeys" model, then standardize on Java.

In general: an adequate coder can handle Java and bodge C++. A good coder can pick up and use any ordinary language in a week or less, and be fluent and experienced within six months. A guru can handle the oddballs, like lisp and haskell, and make them dance.

Do not expose code monkeys to haskell. You'll pop their fuses, leading to expensive lawsuits, etc.

There is perhaps another viewpoint...

[riprjak]

...You seem to be seeing it as a negative, yet standardisation is the Engineers greatest tool; without standardisation, Eli Whitney wouldn't have been able to manufacture weapons fast enough to win the American Civil War; Henry Ford wouldn't have produced a cost effective automobile; Toyota wouldn't be the insanely successful company they are today, of course, they standardised on a method of doing things, not a specific type of tool... Anyway, enough engineering bias, let me try and make a point :)

Could a layman not ask the question of multiple programming languages being utilised as follows; why do you need to use thirteen different tools to solve the same problem thirteen different times? This is just as foolish... Note I am not talking about solving DIFFERENT problems...

Standardisation is NOT INTENDED as a straight jacket, however it does intend to ensure that faced with the same situation you use the same solution. It is about portability and interoperability, it is about ensuring that if you get hit by a bus an equally competent colleague can pick up where you left off with minimal learning curve. Naturally you should employ process improvement methods after each activity to fine tune the methods!! that goes without saying. Anyway the true Engineer only uses appropriate tools to solve a problem. Sometimes "appropriate" means the tool which is perhaps not the most ideal immediately, but creates the least ongoing burden (for maintenance, interoperability, etc...).

The descision to standardise should be made for one reason only, to IMPROVE your businesses products or processes. If you do not gain from standardising, do not standardise. Likewise, do not resist standardisation just because it is out of your comfort zone, because it makes YOUR life harder even as it yields overall benefits or because you PREFER tool a over tool b. It most certainly not be resisted because it makes your job less secure. :) Like everything else in business, there is only one reason to do ANYTHING, you take an action because it yields an overall, objective benefit. Of course, I, personally, take the long view to "overall" and often recommend and sign off on short to mid term pain for long term gain.

just my $0.02AUD
err!
jak.

We settled on python

[ubikkibu]

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.

Argument for Standardization

[Hairy1]

There are a few things I could say about standardization:

First of all it means that any developer can work on any project. If you have a developer leave, die or go on holiday their projects are not left in limbo while some other developer gets up to speed. In large shops it might not matter so much, but with a small shop of four or five developers it's a different story.

Maintaining a level of professional proficiency in any language means spending time on a regular basis developing in it. Languages and utilities change all the time, and to keep up takes time. I can't imagine a single developer being proficient in more than three languages. For example, I used to do Delphi, but havn't really done anything in it in a couple of years, so I'm not really in touch with it anymore.

From a business perspective its good to concentrate on being good with one technology rather than being mediocre in several. Learning new languages takes time, and so having standardized on one language means not needing to train new employees in several languages, and also keeps the employment pool wide.

It means you can be clear about which projects you are aiming for, who your clients are, and allows you to concentrate on what you are good at. Obviously you don't want to chose a language which paints you into a corner - it must be flexible, generic, well supported by employee availability, and accepted by clients (and yes, some clients do care).

However, that doesn't mean you stop evaluating the options. Right now we are moving from Java technology towards Python. Our bread and butter is still Java, but Python is giving us a faster more effective way to develop web applications without sacrificing our favorite language features. We even mix languages in projects.

However, unregulated use of languages is not permitted because it would mean having no clear strategy for the future support and maintenance of the project. Moving to python for me means moving all our developers to that technology, and making sure we don't lose the company advantages we built up by using Java.

Dilbert - GO FOR IT!

[ratboy666]

If you can get yourself on the "Standardization Committee", you can probably even have REAL fun! Like -- ask stupid questions: how does the language express factorial 10,000? Can I see some sample code? How about implementation of Knuth's Algorithm for sorting tape runs (whatever). How about dynamic programming? Backtracking? Functional programming? OOP support? Report generation from databases. GUI interfacing? Multi-threading?

You get the drift. I am sure that you could generate at least 1,000 pages of samples, criteria, &etc.

Ratboy

For a product line, ok. For a company, god no.

[gte910h]

Unless your company is an ungodly narrow sort of business, you should rule out the use of other languages entirely.

If you're hiring programmers who are totoally hopeless in other languages, you're not getting very smart programmers.

However, it makes oodles of sense to restrict languages for a certain product. That makes everyone on the team interchangable, and it makes it easy to have a place to plop new hires (who know that language).

However, before you build in a product restriction, you should put an out for performance/library reasons. I think it's silly for a shop to standarize on Java/Python, when you quite often need to make a C/C++ JNI/Swig wrapper to get certain tasks done.

At my firm we do a LOT of Python with C++ performance cores. We do some Expect scripts to interact with interactive programs. If we had standardized down to the point we would have used One And Only One language, then we would have one of many suboptimal situations: Standarizing on Expect would have been silly, TCL is not a full featured language. If we had standarized on Python Only, some of the code that needed to run over HUGE datasets would have taken approximately 15 times longer to complete than the C++ core did. The C++ core took HOURS as it was.

If we had standardized on C++, our dev/debug time would have been much much higher. We also would have had to spend more hiring developers (you can get good python code out of an intern. Good C++ doesn't come out of interns often enough to mention).

Standardizing on C++ isn't really standardizing. For a project to really standardize on C++, you have to pick a subset of that colossus and forbid the rest.

                                  --Michael

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.

Are You Surrounded by Incompetents?

[cheesedog]

Here's how to tell that the people that surround you, um, how to put this delicately... 'lack critical thinking skills':

1. They advocate standardizing all software development on one language
2. They advocate standardizing all development tools in one IDE
3. They advocate standardizing all code formatting into one standard (tabs v. spaces, how far to indent, where to put the curlys, etc.).
4. They advocate standardizing on hitting '60' instead of '100' when you use the microwave and want to heat for 1 minute.
5. They advocate standardizing on one height for all adjustable chairs in the office.

Notice a pattern?

If there are enough people in your organization that this issue actually has to be debated, you might as well start looking for an exit -- the company is doomed to, at best, forever wallow in mediocrity. I'm not exagerating. This type of 'discussion' shows a serious disregard for reason, logic, and a lack of respect for wisdom. It's a serious indication that those spearheading the push have no clue what they should be doing in their roles -- they can't figure out how to do real work that would actually be valuable to the company, so they choose to waste their time on this.

There is something else at play here: whoever is pushing for this doesn't trust their developers to make sane decisions regarding development tools. Maybe that mistrust is warranted, maybe it isn't. Either way, you are screwed.

Now, if you were talking about a 5-man startup, it's almost a sure bet that you are all going to be writing in the same language, and you might even all be using the same IDE. Same if you are working in a small team in a larger organization. But a company-wide push to put all your eggs arbitrarily in one basket? Insane. For one, it means that the company will only attract (or keep) programmers who are not interested in developing new skills. And a programmer who is not interested in keeping their toolset current is generally a very poor programmer.

Smart people don't build monocultures on purpose.

Pick Two: It Does Make Sense to Narrow the Field

[BigTimOBrien]

Pick Two

One from - Java, C#

One from - Ruby, Python, Perl

It makes perfect sense to standardize on both. Scripting languages will always be more appropriate for text processing and other tasks like validation and system administration.

But, from what I've seen, it is important to standardize an organization on one of each. Letting people go off and just write System X in new technology Y might be enjoyable, but it does end up in a great deal of duplication and expense. For example, one environment I've seen has a great deal of Actionscript, a great deal or Ruby, more Perl than I'd ever want to see, and some J2EE applications. This usually occurs when an organization lacks a sufficient level of oversight over architectural decisions.

Just pray that neither side wins. Writing only Java is as silly as writing in a different language every single day.

Standardize on Hindi~

[colin_n]

Your company should standardize around Hindi - the new programming language in India - It is an extremely natural language - you write down your requirements in English (even on paper), send it via e-mail / snail mail to a supercomputer called "India", the "India" machine turns it into Hindi and feeds the information to a cluster of other India machines, known as "Indians" and then these "Indians" break it down into functions, write the code, put it back together, compile and send you the binary - you wont have to worry about what language they code it in!

Re:Standardize on Hindi~

[strider44]

Is the binary Big Indian or Little Indian?

Re:Standardize on Hindi~

[BeardsmoreA]

At least if you mix them up you should end up with a decent Na(a)n.

Sorry. No really.

Re:Standardize on Hindi~

[piergi]

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.

A common language is good...

[localman]

I've never tried standardizing on a language after the fact, so I don't know how that would work. But I am a firm believer that a common language for the development team is a good thing. Much like a common spoken language for the team is a good thing. It encourages code reuse, sharing, and general system understanding. On the occasions that something in our system is written in another language (we had a few C modules from contractors and third parties), it usually ends up being a mystery system and we accept it with it's behavioral limitations or we end up rewriting it in our own language (which happens to be Perl) so we can tweak it as needed.

Of course we actually do use several languages: perl, SQL, DHTML. But each one covers a very specific, non-overlapping domain. I've tried to stay away from having a second language cover the same need in a different way. It's hard enough to keep everything understood and shared as is.

Cheers.

Minimize platform diversity, don't eliminate it.

[firewrought]

I believe in using the best car for the job. When I'm going to the beach, I take the SUV. When I'm driving to the other side of town on surface streets, I take my civic; if it's raining, I'll swap out the touring tires for all-season ones and give the windshield a quick RainX treatment. When oil prices spike, I'll whip out my OBD-II and tweak my fuel ignition timings; I usually remove all the passengers seat too, though one time a coil popped loose and tore a hole in some new jeans. If I've got a date, I'm going to pick her up in the Porche, unless she's the earthy type who would rather make out in a Jeep... or, actually, I'd prefer to use a HumVee, but I had to sell mine so I could rent a 18-wheeler to help my friend move out of his apartment. It was a hefty expenditure given that I had to hire a commercial driver and pay insurance, but we were able to get it all in one trip! With an ordinary vehicle, we would have to ferry stuff back and forth, which would have taken, like, ages.

Moral: 'The best tool for the job' is not the same thing as 'the best set of tools for all of our jobs'. I suspect most businesses will do best picking one or two languages (static+dynamic works well, like Java/Jython) and sticking to them except in well-justified exception cases (like needing to write a device driver). DBA's and sysadmins will probably have their own collection of scripting languages dictated by their DBMS or OS platform.

The opposite of 'best tool for the job' (often subscribed to by programmers) is the 'one size fits all' advice (often subscribed to by management). It has problems too. If your bias is towards 'best tool', think about (1) overcoming any reluctance you have to learning a new or "rival" platform (2) long-term cost and risk of having an extra platform [it's higher than you think]. If your bias is towards 'fits all', learn more about when language choice it matters and be receptive to dialog on new or alternative tools. (2) avoiding pointless diversity which will cause headaches for future maintainers down the road.

Mixed results

[Todd Knarr]

I've had mixed results with standardizing on a language. All too often it's done purely for the sake of standardizing, with no thought to anything else. Programming languages are tools, and ones being used by a team not just one person. You want to minimize the number of variations in your tools so people don't have to worry about needless vagaries from one tool to another. At the same time, you don't want to standardize so far that you eliminate entire kinds of tools and end up doing the equivalent of trying to use a rock as a hammer because your shop's standardized on screwdrivers and screws for holding things together and so doesn't have hammers (the programming equivalent would be trying to do simple scripting jobs, that'd be 5 lines in Perl or bash, in C++ because that's the language your shop standardized on).

The only times I've seen standardizing languages work is when the first step was to not standardize. The first step in a successful standardization effort will be to ignore languages and instead take stock of what kinds of programs you need to write. Include all those little one-off jobs that you have to do several of every week, eg. the little hack to extract the error messages you're interested in from the logfile. Then, for each kind of program, look at the languages suited to writing that kind of program and see what one your developers are most comfortable with and, just as importantly, what your existing code is written in. An inferior langauge that all your developers know well is superior to a superior language that they're not familiar with, and if you've a large body of code in one language then that language is better than a different language. If several kinds of programs can be served sufficiently well by one language, well and good. If not, well and good too. The goal is to simplify getting the job done, not hamstring yourself with rules not related to getting the job done.

In the Unix world, normally I expect at least 4 standard languages. You'll have shell script (typically sh because so many other tools expect it, but csh is possible), make (because every development environment typically depends on make at some point), another scripting language (Perl, Python, Ruby, etc.) and a "real" programming language (commonly C, C++ or Java, add VB and C# in a Windows environment, others are possible).

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.

This is what Architects or Team Leads are for

[feldkamp]

This is what lead engineers, or architects (responsibilities and titles vary by team) are for.

There should be a chief, and he should listen to the opinions of the entire team. Then, using his expertise, wisdom and the input of the team, he/she should make the decision.

In fact, a good architect or lead should have a good instinct for this... it will be highly dependent upon the system architecture, team makeup, etc. If the pieces are easily seperable (say, a c# GUI app that communicates to a ruby-on-rails web service), and most developers on the team know both languages, maybe multiple languages work. On the other hand, if only one or two programmers know ruby (or c#), or you're talking about one app that uses both languages, the situation gets murkier.

I've served as a lead dev / manager for teams in both scenarios. In the past, I developed a large system based on Delphi combined with C++ (several applications), and recently a whole system with C# (again, multiple applications and components). I can say that both are doable, but each was approach was tailored to the requirements of the system.

The distinction between standards and uniformity

[jd]

I agree completely with what you're saying. It all comes down to an important distinction between having standards and having uniformity. "Wait!" I hear some cry, "Aren't the two the same?" Well, no. A standard translates, in pseudo-code terms, to "if X then Y". Uniformity translates to "always Y".

What needs to be standardized, then, is not the language per-se, but the rules by which a language is selected. The IF statements. If you read through the standards documents on the IETF's website, you are not looking at a single, all-encompassing rule. You are looking at possibly a few thousand rules, with enough logic behind them to determine which rule applies.

In the case of a company picking a programming language, you probably don't need a few thousand rules. A single side of paper should be more than sufficient to cover all the meaningful languages and the cases they apply in.

Rule 1 might be: "If a more precise rule is not defined, programs should be written to the ANSI dialect of C, revision C-99 with all threading assuming the POSIX threading model and other parallelisms within a single computer assuming OpenMP extensions. Where a more precise rule exists, that rule takes precedence over this default action."

For embedded code in web pages, the rule might be: "Except where a specific project requirement dictates otherwise, embedded code within web pages should be written in PHP, revision PHP-5.1"

For transportable bytecode, you might say: "Web-enabled applications, applications needing to run on clients without installation and applications needing to run on otherwise unsupported platforms should be written in Java and compiled to bytecode using a standard Java SDK version 1.5"

For configuration code, you might say: "Automatic configuration files should be written to the standards specified by Gnu Autoconf and Gnu Automake, using the applicable Gnu M4 macros" (Hey, M4 is a language too!)

You'd then have a few more cases for specific types of work the company does a lot of. This may include additional rules requiring C, but that's fine. You want the specifics in there, so that if you want/need to change the default action, it doesn't screw everything up.

If you're defining standards for languages, I'd also define in the same document some standard coding practices (eg: keep namespaces distinct, if you're using javadoc or something similar then comments should follow javadoc's rules, if you're using a code validator that uses comments to embed commands then state what commands should be used and when, if you're using a SCM - a very good idea - then comments to embed details like revision notes, date, etc, should be included in a standard location, etc.)

The upshot is that there's a lot of different things to consider, nobody can just pick one language for all occasions. Well, they can, but the only language that will ALWAYS work for ALL cases is assembly, and I don't think many people really want to write entire applications in assembler any more.

Re: Ada

[Black Parrot]

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

This is Why We Have the Mess We Do!

[SerpentMage]

"I am a computer programmer. I make computing devices do what I want. I will use any tool at my disposal, to hell with my employer's proposed "beneficial" restrictions."

This is why we have we mess that we have now! If you were an engineer and machinist you would be screaming bloody murder! About 20 years ago the car industry had the problem where they had 20,000 parts that were unique to a car. When a new model was introduced there were 20,000 more parts unique to the car! All of these unique parts were wrecking havoc on car design, and maintenance.

If any of you remember the K-Car from Chrysler it was the first attempt in the car industry to share parts (Oh the horror! ;) ). It worked and brought Chrysler back from the brink. From that point the car industry understood standardization needs to happen. Now we even see standardization of major parts across car manufacturers. And yes standardizing on one screwdriver is part of it!

Right tool for the right job, and learn from Java.

[Darth Liberus]

I settled about a year ago on two things: 1. Use the right tool for the right job. Web applications, which perform most of the processing on a remote server, are very different than GUI apps that run on a user's desktop. It's stupid to think that one language is going to provide everything you need in every case. GUI apps need strong typing to run quickly and keep the end users happy - Web apps need rapid design to keep the VPs happy. End users love GUI apps and hate crashes; VPs love Web apps and don't care if if an app crashed from time to time as long as it mostly works and gets done NOW. Pick whatever language is appropriate for the task. 2. Learn from Java. Java has its warts, but from a structural standpoint it's probably the most solid language I've ever worked with. These days I mostly work with apps that target mod_perl, but my code - and the code of anyone who works with me - is required to adhere strictly to Java's naming convention, must follow a pure OO paradigm, and do its best to act like a JavaBean, with "getters" and "setters" properly implemented and static and normal methods documented as such. By doing this, I've managed to make Java programmers actually like working with Perl... something long thought to be impossible :)

I see your problem!

[Gorimek]

A company where that can happen has a much bigger problem than languages. Such as a complete lack of teamwork and communication between it's developers!

Standardizing on a language will help a bit with the symptoms of that, I suppose, but unless you address the actual issue, I don't foresee great things for that kind of organization.

Not to get religious, but avoiding problems like this is one of the big "hidden" advantages of pair programming.

Re:I see your problem!

[Nybler]

You betcha. That's the situation at the company I'm working for, and we're attempting to rectify it. The problem is right now we have just about every language that's ever been used: COBOL, Fortran, C/C++, Delphi, PowerBuilder, VB, Java, VB/C#, Perl & Python. And those are the only ones I know about!

As a result we also want to standardize on a language - or at least a set of languages. The purist in me says you should use the right language for the right job. The practicalist in me says you should use a language that's easy to find developers with talent in that language and can handle any business application coming our way.

The fact we have a plethora of languages is indicative of a lack of management oversight. Developers can pretty much do whatever they want - as long as they meet their deadlines and functionality requirements. Some managers manage the technology more than others - but there's no overall consensus throughout the organization.

Our challenge now is we have a newly-formed group managing the development tools and languages and the developers are resistant to any changes in the status quo. Especially looming large is a potential showdown between Java and C#.

I don't mean to flame, but with all these religious wars going on in IT it's become apparent to me why so many companies have turned to outsourcing. How are other companies managing their technology without engaging in holy wars?

Muliple languages is the way to go

[bartmc]

My boss is confident enough in his staff and himself to be able to pickup and maintain whatever the developers decide to do their job in. Currently I have written C#,Java(JSP/Servlets,J2ME/MIDP, server applications, Blackberry J2ME stuff, Applications), C/C++, Tons of Shell scripts, XML, LaTex, HTML, XML running on Solaris,Windows,FreeBSD,various flavors of Linux. All of which ultimatley connect to either an Informix or Postgresql database of which the host apps are running on an old legacy SCO UNIX system. Whatever does the job best is our motto. Id hate for my boss to walk in and say convert everything to . It would be hell.

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

Libraries - not languages

[StressedEd]

Having read many of the posts here I think people are missing the importance of libraries.

I would hazard a guess that most people want to get a problem solved in the most painless manner possible when programming.

Surely the best way to achive this is by avoiding the reinvention of the wheel.

In some manner I tend to view languages now as nothing more than the glue that binds library calls together!

My approach is:

1. Work out what you want to do.
2. Find libraries that implement the most difficult parts of the problem.
3. See what language bindings exist.
4. Choose the language appropriate to this.

For example, there is a wealth of scientific code out there in F77. Just because F77 is old doesn't mean that the libraries are now wrong. They still do what they did back then. They are still useful. People have spent a great deal of time working out the error propagation in these codes, the efficiency and their validity. Do you really think you will save yourself time and do a better job by rewriting it in Java? No! So. Use them.

Then there are (great) libraries such as ATLAS or FFTW [*] written in C. Why assume you can do better? You can't, use that too.

In the rare case where you need to have something written from scratch, write it in whatever you are comfortable with. In my case C++/Boost (yes another library).

Finally you need to tie all this together, and hack around with it, and analyse the results so what's wrong with a bit of Python and MATLAB?

Perhaps this is an extreme example, and doesn't fall into the buisiness relm but the point is "the path of least resistance". Sometimes that path is dictated by existing code.

Do you really expect someone to rewrite from scratch an XML parser in "DoomJuice", or whatever is fashionable in house, just to please the people that want to standerdise on "DoomJuice"? No, use an existing library!

Ok, I've made my point. I will stop now.

[*] Yes I know FFTW technically uses Objective CAML to generate C code, but that's really only a distinction that a nerd would make.

Using one language for all

[Z00L00K]

is one of the more stupid ideas. You will never be able to achieve all features you use in one single language. If you are doing development in Java you may get away most of the time, but there may be things that can't be done unless you do a different language. (of course the portability suffers, but it is a trade-off between function and availability.)

Every generation has had it's favourite language, and the big ones has been Cobol, Basic and C in history. Currently the languages Java and C# is rising, and offers flexibility that can be used and abused but in the end are far much more flexible than the early languages. Ada can be defined as a father of Java and C#, and certainly has it's place.

What you actually should focus more on is not a specific language, but how to model solutions and do efficient coding models. It doesn't matter what language you use if you aren't able to do a good system design. And system design is not something only for senior system analysts to do - even junior programmers should be involved. Start with a large meeting whith a HUGE whiteboard and a lot of pens in different colors - try ideas - even ideas that may seem stupid and explain WHY it's stupid. Break down into task groups and let each group do it's own analysis. This should be repeated through various phases in the project to be able to stay on track. A system isn't better as it's overall design - even if it incorporates solutions that are outright brilliant.

Building a system is like building a house - you use different material for different parts. The foundation the house resides on is the operating system. Utilities like electricity, gas, water and sewer are all connected at foundation level, which can be seen as C code (and optionally assembly code) and are normally part of the language you use unless you have special features. The basement is done with the basic language classes of Ada, Java or C#. As is the framework of the rest of the house. The walls are then done by extended classes of your language of choice and then all trimming, wallpapers etc. are your completely custom-built classes. There is need for different class groups in different rooms - like a kitchen and a bedroom does have different properties - so only a few properties are common, and you may even be able to accept that they don't even share these properties in an abstract base class since that may require too much interoperating time between different task forces. It all comes down to how big your project is. The re-inventing of the wheel can't be avoided every time, and if the wheel costs five minutes to invent - is it worth the time to check if it is already invented?

Hmm, web development anybody?

[LoveMe2Times]

If you're doing any web development (and let's be honest, if you're doing any develolpment, your organization is doing some web development somewhere), you *must * use 3 or 4 different languages. No way around it. If your organization isn't using some combination of HTML, XML, CSS, Javascript, XSLT, XPath, ActionScript (1, 2, or 3!), SVG, and other web languages, well, WTF?? Toss in a server side language, either Java, ASP.Net (any), PHP, Perl, Ruby, etc, and often you pick (or have only 1 choice of) a tag language to match (like JSP/JSF/etc with Java). Unless you're using some data abstraction layer, ORM type thingy, you'll probably have some SQL kicking around too.

Next, if you create an end-user application of some kind, in many many cases, you must use C/C++ due to end user requirements. Some of this is being eaten up by C#, but not everybody is willing to target the .Net runtime. Then, you probably have to write an installer, and this might be using InstallShield's scripting language or similar. Does your QA department do automated testing? The automated testing tools usually have their own scripting languages too (maybe these are moving to .Net languages now, I haven't looked in a while). And if you're a big dev team, you'll be doing automated builds, so'll have somebody who's actually hacking around with makefiles (potentially MS format NMAKE files).

If you're company is big enough to be worrying about this kind of problem, you'll have an IT infrastructure of some importance. Your IT team damn well better be using Bash scripting, Perl, Python, or some other Sys Admin language. Even Windows admins these days write scripts; there's even this new scripting framework scheduled (as an add on?) for Vista. How about your Apache config files? Your various mail/proxy/firewall configs (talking to UNIX folks here...)?

If you have a real IT division, I'll bet you have an accounting section. Remember why people have such trouble moving to OpenOffice.org? That's right, custom Excell/Acess solutions. What's that, VBScript you say? Moving into Fortune 1000 territory, how about R3? Well, that SAP system never actually did anything, but those consultants sure made a helluva lot of money. Manufacturing and assembly lines use all kinds of weird stuff. Got any telephony solutions running around? Are you targetting mobile devices? Use scientific/mathematical software? Rendering software? Various pre-press systems? Work in the medical/health care industry? A lawyer's office? All these verticals have lots of custom things running around that you sometimes can't avoid.

So in a nutshell, any reasonable corporation doing software development *should* be using 5-10 languages. If you were to pick only 1 language, the only choice you could possibly have is HTML. You could theoretically write a static HTML page with no CSS, no Javascript, no server side scripting, no SQL, and no Flash. You could run it off of one server, with no admins and no scripting. With no product to hawk, you don't need an accounting deptartment, and voila. Good luck with the whole money thing, though... What a stupid question. Use what you have to based on the requirements, and when you have a choice, do your best (maybe even bend over backwards) to avoid unnecessary proliferation.

One Standard Language

[Danathar]

It was tough. But once we standardized on english, communication was MUCH easier.

Re:Depends...

[Bloke down the pub]

So what language should a company that sells paper use?

Re:Depends...

[O.W.M]

English.

The Danger in Corporate Language Standardization

[constantnormal]

... is that it tends to degenerate to the "lowest common denominator", or the most widely-used language for everything, regardless of applicability and common sense.

Nonsense such as COBOL in the desktop environment, or perl in an IBM mainframe environment. Neither makes much sense, as the supporting codebases that might make COBOL in an IBM mainframe environment do not exist in a desktop environment (without extensive (and expensive) porting) and similarly, the large pre-existing codebases for perl do not exist (or again require substantial porting) in the mainframe environment, not to mention perl's targeted UI of a unix shell or console is not what one is presented with in mainframe environments. REXX makes for a much better choice of a scripting language on the mainframe.

Yes, you CAN use COBOL for everything. Or Java. Or C/C++. Or perl. Or assembler.

That old saying, "To the man with only a hammer in the toolbox, every problem looks like a nail", applies here.

Having a toolbox with a reasonable assortment of versatile tools is a sign of a craftsman. Having a toolbox with every tool known is a sign of a rich dilettante playing at being a craftsman. Having a toolbox containing a single tool is a sign of an idiot playing at being a craftsman.

Re:The distinction between standards and uniformit

[sgtrock]

I know your list wasn't meant to be complete, but you missed one case that tends to get ignored a lot on slashdot. That's OK, the bulk of the people hanging out here are developers or have a development focus, so they tend to forget about the rest of the IT staff. ;)

Think of all the scripting that gets done by the network and system administrators to keep everything humming along. It's almost always unrealistic for that staff to fall into line behind a single corporate wide language that was chosen to support a completely different set of design requirements. Heck, in their case it's virtually impossible to pick a single language due to differences between platforms and availability of tools. For example, in most cases they're happy if they only have to worry about choosing between Perl, Python, shell scripts, and/or batch files on *nices and/or Windows. Then there's JCL or ?? for the big iron plus Ghu knows what for rarer platforms like Tandems.

None of the above takes into account the network admins who, in addition to worrying about the differences between (again, for example only) Cisco and Juniper, also have to have at least a basic understanding of whatever scripting language(s) their management consoles support.

Anyhow, I agree that the idea that all coding done by a company can be done in a single language is wrong for all the reasons that you enumerated, and I agree that a list of standard choices based upon requirements is very important. That single sheet of paper probably needs to grow to a sheet and a half or two sheets to cover all the possibilities, though.

Value

[omyar_hunt]

The question of client value is one that has been ignored up until very recently, with areas like interaction design, and Agile methodologies incorporating client needs and goals into the day to day programming work. It comes down to this - only do what work has obvious value to the customer . The only question for these standardizers is : what value does this peice of work have? I would purport that standarizing on a language across multiple disparate teams for it's own sake has no value. So whats the reason these people have for wasting company time and money? Are they backed up in their claims by metrics, prior experience of a successful changeover, or published works backing them up? OR are they, as I would assume, going with a bad idea through lack of imagination? Trollish as it may sound, lack of imagination in people who have big ideas is a bigger problem than people realise. Those who come to the idea first, and quickly, are those who are most unwilling to change (src: http://www.poppendieck.com/ Lean development techniques). It is exactly these types of personality which graduate towards management positions, pushing bad ideas until they are proven irrevocably wrong. Who are they anyway? Are they programmers themselves? (in which case I'd be inclined to dismiss their opinion on the basis they are naturally biased to one language anyway) or are they managers? (in which case I'd be inclined to dismiss their opinion on the basis they don't know what they're talking about)

There are perfectly good reasons to standardize

[drdread]

I run an engineering division within my company. I have ~40 developers and a total staff of around 110. This includes biz dev guys, testers, systems engineers, production engineers (builds, installers), etc. We do mostly contracting work, with a small amount of licensed product sales.

We have standardized on a single language (C#), and it has worked for us. We have a significant base of legacy code, including C++, Java, and Visual Basic. I can tell you from personal experience that 90% of the agony we endure is related to the legacy code, specifically maintenance of said code. Keeping enough people up-to-speed with skills to work in more than one or two languages is a tough challenge. Organizationally speaking, my life would be vastly easier if we could get down to 100% of our code in a single language.

Of course, that's never going to happen, so we do try to retain the people who have experience with our legacy code base. We also try to assign new people to work on the legacy code whenever it looks like we're getting short of experience in any one area.

I'm a coder by trade and experience -- this management stuff is definitely new to me. I have always personally enjoyed learning new languages/techs/whatever as a developer...but from an architectural and business standpoint, I can definitely point to reasons to standardize on a single language or development platform. We are transitioning to a product line architecture, where deliveries are based on off-the-shelf in-house components (new development as necessary, of course). Customers *hate* it when we tell them "after you install this, you'll have .Net 1.1, Java 1.5 and VisualBasic runtimes on your machine, along with all the support libraries, etc." They would much prefer a homogeneous environment with minimal footprint.

There are also issues within a product line with mixed-platform development. Unless you work *really* hard on decoupling components at exactly the right places, mixing platforms makes it difficult or even impossible to develop a solid product line. I'm starting to think that it's actually impossible without going to a full-out service based architecture.

So don't dismiss the idea of standardizing on a single language. Just because you're a developer and you want to play with the latest cool toys, that doesn't mean there is a defensible business reason to allow that.

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)

Re:The distinction between standards and uniformit

[iabervon]

The original question, however, said they were considering standardizing on a single language, which is a dumb idea. It sounds to me like they're conflating the good idea of having standards with the bad idea of having a standard that doesn't respond to requirements.

Its a simple debate

[dilvish_the_damned]

One that we have here at times, only under differing guises. To end the arguement early I would ask "Why cant we just do everything in Perl?", and the response would be "Perl hardly makes sense in a multitude of situations, for instance you wouldnt use perl to build a packet router".
And I would say "and C hardly makes sense when you want a scriptable telemetry data simulator". So we use at least two languages here as long as you dont count the cases where we use C# for win32 gui's, java for some corba interfacing stuff, VB for program/device monitoring (on win32), etc.
There is no 'silver bullet' language so why would you force yourself into treating one like it was? Any time you might have saved by not having to learn a new language will be eaten alive by the time spent trying to shoehorn a problem into a your chosen languages paradigm.
Really, all languages suck, some less than others, but its really contextual.
To really break the arguemtn you might say something like "When we standardize on a language we will also standardize on the types of problems we can address competitivly".
At least thats the way I figure it.