Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My company has been using Java (as a language and a platform) for many years. We have lots of products varying greatly in size, purpose and complexity. Whatever the requirements, the answer is always the same - Java. This stance obviously has advantages and disadvantages. On a plus side, there is no context switching between work assignments on different projects, every developer in the company can be relatively productive on many projects; on a minus side, a small tool might end up being "crushed" by Hibernate. On one hand, packaging, deployment and execution environments could be standardized; on the other hand, we might loose agility of the mind and miss out on optimal solutions by always "thinking in Java". I could go on and on and on.

Polyglot programming has become quite common in the recent past, as much as I can observe. Sayings like "right tool for the job" always ring loud in my ears as well. A desire to open up and expose ourselves to more "right tools" is quite strong, but where is a catch? Better yet, where is the golden mean? It's always dangerous to go from one extreme to another. I dread a day of waking up into an incomprehensible mess of a giant pile of Java, Groovy, Python, Ruby, PHP, Scala, etc. with all their corresponding tools, frameworks, servers and philosophies.

Do you have a practical experience working in language and platform polyculture for at least two years? What are your main observations? What are you still excited about and what do you dread?

share|improve this question

5 Answers 5

up vote 3 down vote accepted

We were in a similar situaltion and added another language to the mix when what we wanted to accomplish could not be done in any practical manner with the exisiting language.

It took us years to reach that point though.

To extend your right tool for the job metaphor, it might be better to hammer a nail in with the handle of a screwdriver instead of driving across town to the store to buy a hammer. But when when you need to chop down a tree it's time to head to the store.

share|improve this answer
    
I like your metaphor, handle of a screwdriver might be very appropriate at times. –  Yuriy Zubarev Mar 25 '11 at 17:34
    
That is a great metaphor! –  Dave White Mar 25 '11 at 18:25

I was at one company for about four years, doing heavy stuff in C++. After about a year, I got assigned to running the software infrastructure (CVS and Gnats, primarily), and I wound up using Perl extensively, in addition to what I thought of as my "real" work. We had some libraries written in C, also, but that has at least some overlap with C++.

I had no problems whatsoever with it. I knew what was going to be C++ and what was going to be Perl, and so did everybody else. Enough of us knew Perl that replacing me wasn't going to be a problem.

I'd suggest that different languages be used for different purposes, so there should generally not be a question as to whether to use C++ or Perl. For that, it's useful to have distinctly different languages that are generally good for different things.

share|improve this answer
    
+1 for mentioning being replaceable. There is definitely a higher bar to new hires / other team members when the number of technologies starts to get out of hand. –  Ethel Evans Mar 25 '11 at 17:26

We work with a standard set of tools:

  • Java - general language. All of our major support apps are either Java web apps or webservices.
  • RPG on the AS400 does much of the database access.
  • Visual Basic starts our automatic builds. Not too familiar with how that has worked out.
  • Ant scripts do the build work.
  • Python (for Websphere Admin) does deployment scripting and server configuration.

This whole combination was worked out before I started working here, and as far as I can tell is optimal for what we do. It works and everyone understands it.

I will say though that our requirements rarely change as these are internal company apps. So, there's not a real need to seek out new ways of doing things because our needs are already covered.

share|improve this answer

Why not test the waters without taking the leap?

Java as well as other VM (Virtual Machine) languages are evolving more each day to decouple the primary language (Java) from it's attached VM (JVM). In the case of the JVM there are many languages that you can now choose from that are capable of being run alongside Java code because they share a common underlying infrastructure (the JVM).

Here's a short list of just a few JVM languages:

  • Jython (python)
  • Rhino (JavaScript)
  • Groovy (Scripting)
  • JRuby (Ruby)
  • Clojure (Functional Lisp)
  • Scala (Object-oriented and Functional)
  • Kahlua (Lua)

etc... For a full list checkout Wikipedia's List of JVM Languages.

The benefit of having a team of Java devs is, the JVM is being extended to run a lot more than Java code. So you can run Java, Python, and JavaScript all together.

Try incorporating some Jython for basic utility scripts. Or some Rhino to do server-side JavaScript. There isn't much risk of investment because you don't necessarily have to target one specific language anymore. It'll give your teams room to practice and expand their skill set without breaking your applications.

It might be best to skip PHP and take a look at some of the Python frameworks (pylons, django) if your company it thinking about breaking into web development. The web development leap will probably be the most dramatic. Web development, is different... While some concepts are a lot less formalized (still feels like the wild west) there is much tighter constriction on style if you're seeking an efficient performant web application. Plus, the tools and concepts for optimizing websites are a lot different than what you'd expect on a desktop app.

Microsoft had a huge lead on the VM world by initially releasing C#, VB, and C++ on the .NET VM but the Java world is catching up very quickly.

SideNote: If you're curious, here's a List of .NET CLI languages.

share|improve this answer
    
There's even an 'escape route' from Java by using Scala running on the same JVM and interfacing the same Java libs as needed, or even mixed in as a part of an existing Java project. (Also I'd mention JRuby, Groovy, and Clojure.) –  9000 Mar 26 '11 at 8:27
    
@9000 Good point, I'll update my list of languages with more information on languages that can run on the JVM, since there are many more possibilities. –  Evan Plaice Mar 26 '11 at 9:08

In my experience as a consultant (> 5yrs), I find organizations that focus first on fundamental, language-agnostic skills and development techniques experience a great deal of success in their development projects. Design patterns, development techniques, agile methodologies, all apply regardless of implementation language. Architectural patterns like message buses, web services, SOA patterns are again applicable on all projects. Continuous integration, unit testing, testability. I could probably ramble for a while longer.

The benefits of empowering developers to bring the best tools to bear when delivering solutions should not be understated. Developers get the freedom to apply the best tool to a problem and leverage critical thinking when melding technologies. Happy developers usually equal better products and more successful teams.

That said, there needs to be constraints applied as well, especially for less mature teams. I've seen organizations with a mash of poor fitting, misunderstood and disparate technologies because there was no high-level guidance or constraints on the freedom.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.