views:

369

answers:

16

I've heard two good pieces of advice when it comes to choosing which language to use in a development team. To paraphrase:

Use the language you're most familiar with unless you have a compelling reason not to. It'll provide the best return on investment.

and

Different languages have different strengths. Be fluent in many languages so that you can choose the best one for the project.

These two are not mutually exclusive of course, but I was wondering to what degree different development teams tend towards one or the other. My suspicion is that most shops lean heavily towards one language in particular.

I'm not talking about different domain-specific languages, such as C#, HTML, JS, XML, etc. which all coexist performing different tasks in the same project. Rather, I'm interested in the primary development language for your projects, e.g. Java, VB, C#, Delphi, Perl, etc.

How many "main" languages are used in your team? Why does that work (or not work) for you?

+1  A: 

My projects usually run with a single stack per project (e.g. C#, ASP.NET, Javascript, SQL, etc.). We don't mix things like C#/VB/Java if we can help it.

Michael Haren
+3  A: 

We use Java (back end), C# (fat client front end), JavaScript (Web Front End). We also have some ruby for code generation.

I'm a firm believer of "best tool for the job".

Jim Blizard
+2  A: 

We produce an API toolset for .NET. Our code is written in C#, C, C++, and javascript. We ship demos translated into VB because many of our customers want that. We have some coders who work entirely in C#. I work in all 4, but do more C and C++ than anyone else.

plinth
+1  A: 

My shop is primarily Nemerle, large chunks of Python, C, and assembly, and little bits of Perl, C#, Boo, and custom DSLs (built on top of Nemerle for simplicity). Things generally work out quite well; Nemerle, Python, C, and assembly are used for the bulk of work, and one-off scripts are written in Perl and others where needed. This allows developers to use the best tool for the job and we all get good knowledge of a mix of tools.

Cody Brocious
A: 

Python.

We have a few very short .sh and .bat files run test scripts and demos.

We have a few scripts that are complicated. These are the kind of thing that are often done as shell scripts. Instead, we have Python programs that do shell-like things.

S.Lott
+3  A: 

At my company, there's a mess of different stuff and we pay the price daily in integration hurdles. Whenever it's up to me, I stick to one development platform for a couple of different reasons:

  1. Ease of integration
  2. East of training.
  3. Ease of hiring of new personnel.
  4. Ease of resource allocation

As near as I can tell, no one development platform is so much better than another that you're losing out not adding that one into whatever else you've got. Some are sucky enough to want to avoid, though.

One thing about knowing many different languages... there isn't enough time in a day, or life in a lifetime, to become expert at many different development platforms. For my money, I'd stick with mastering one development platform. And when I say mastering, I really do mean mastering it. Knowing a little about lots of stuff is not really all that helpful, IMO.

Robert C. Barth
A: 

I usually take into account who is most likely to be maintaining the code in the future before I decide what language to code in.

VB.NET programmers seem to be "ten a penny" so if I'm coding an application from scratch, I tend to favour VB as it will cost the client far less in the longer term to maintain it, and as I tend to prefer to be finished with a project once I deliver it, there's a high chance that my client will need someone else to maintain it other than me. If I know the person that will be maintaining the application favours C#, then I'll write in C#.

Maintenance will cost the client far more in the long run if you code in a language that programmers tend to charge more in, so if you program in C (for instance) then there's a far higher chance that the client will have to pay more for maintenance than if you programmed in VB.NET.

BenAlabaster
+1  A: 

Java & SQL.

In fact my supervisor is a very, very firm in making us ALWAYS use Java. In the beginning I couldn't understand this as there are often better ways to do things in other languages (namely C# for front end work) -- but his point is a good one IMO; "if we all adhere to one language (in our group) then everyone can work on code X, Y, Z. This makes it a lot more stable when considering the "hit by bus" scenarios that can\may occur.

javamonkey79
A: 

It is not surprising that choosing one general purpose language over another can make a big difference (even if you are not familiar with it at first). A good example can be found in the beginning chapter of the book Practical Common Lisp.

Also, it is not surprising to see a big project written mainly in one language accompanied with small tools written in many other languages (e.g., perl/bash/python scripts).

It may also happen that the first prototype is written in one language (say, matlab) and the final product written in another (say, c/c++).

In any case, choosing the best language to suit your needs is the most important. That's why you need to know (not necessarily familiar with) as many languages/tools as possible. A good programmer is expected to pickup any language in a week, as said by some experts :)

PolyThinker
A: 

We make Windows based packaged applications so we tend to use the tool with the least development time. These days bulk of our work is in C#. Some is in VB.Net and our legacy applications that we still maintain are made in VB6.

Cyril Gupta
+1  A: 

I supervise a bunch of different projects at any one time. They are almost all research projects, so people need a fair amount of freedom to do what's right for them. Here's how things seem to shake out in practice:

  • Each project has a one main language. Recent languages have included Haskell, Lua, Modula-3, Objective Caml, and Standard ML.

  • We work on compilers and run-time systems, so we usually have a little C code somewhere.

  • Test and build scripts are written in ksh, Lua, or a combination. We like ksh for its integration with the OS for long life and portability. We like Lua for its simplicity and for integration with C code. We try to avoid Perl but it creeps in occasionally.

Projects get pretty complicated over time (we're talking 5 to 10 years) but we recognize the problem and try to keep the complexity at a manageable level. The answer to your question is on average, about three languages per project.

It also helps to standardize on a build system and version control. We're pretty happy with Andrew Hume's mk for builds, but we're searching for a new version-control system. We currently have CVS for legacy software; we tried darcs but had bad luck with conflicts and performance. The next candidate is probably git.

If I add up the languages for all the projects that I have under version control, it would be a very large number---unmanageably so. But most of those projects are frozen.

Norman Ramsey
A: 

I'll define team as group which consists of three small to medium sized teams. The front-end team uses Ruby and, indirectly, c. The client team is pure c. The infrastructure team (mine) is primarily Erlang, indirect Perl through the Test::Harness library and c.

Nick Gerakines
A: 

We use C++ and C#. So we have to do a lot of COM Interop and it is more difficult to achieve a uniform look and feel.

tuinstoel
A: 

We use Delphi, ASP.Net, VB.Net and some C/C++.

I still hope to get a chance to use C# in the future.

Gamecat
A: 

IronPython, C#, CPython, C++, JavaScript, and Windows batch files - they're all used for components large enough for me to call them "languages we use".

We try to limit the number of languages - for example we replaced Java and VB components, and may replace some complex batch files with Python scripts, but overall the list above isn't too large for us.

An important note is that sometimes adding a new language to the mix is the difference between accomplishing something (e.g. we already have the library for that language) or not (reimplementing the library is too expensive). In this case, the easy and correct choice is to add the new language.

orip
A: 

I work in 2 teams. Let me pick the iPhone games team as an example.

We have 2 programmers. My partner is good at c. I can code in c, c++, ruby (mainly rails), and a bit of perl and php (mainly Drupal) lately.

Our target is to deliver some iPhone games. The missing language is Objective-C.

So I learned Objective C as I am the UI guy. Thus, one more language is added to our team.

To look back, the number of languages increases when there is a needed. Some language skills are lost (for example, I can hardly code in dBASE III/Clipper, Lotus 123 macro, Ada, or 8086 assembler these days) as we get older.

Computer languages are similar to real world languages. Once we learn one, we won't forget it. However, the less we practice, it gets more difficult to express what we need to the machine ;-)

ohho