billburke flame bait

Let me first start off being a little facetious with a little tongue in cheek…I’m an American. I have no need to speak another language because well, I speak English. 99% of the civilized world speaks English so WTF should I ever learn another language? Case in point, I minored in German in college. For two semesters I went over to Munich and worked at Deutsche Aerospace so that I could learn German better. The thing is, besides the fact that my coworkers spoke damn good English to begin with, all the documentation they put out was in English, the units used were feet, pounds, miles. When the French came over to work with us, we also spoke English. So what is the freakin point of learning German? I was pretty damn disappointed that I wasted all this time in college learning German when in reality it was just a freakin useless exercise…

Which brings me to the point of this blog. Polyglotism in software has to be the worst idea I ever heard. The idea of it is that you use the language that is best fits the job. Some say this is a huge boon for the developer as they will become more productive. In practice though, I think this is just a big excuse so the developer can learn and play with a new language, or for a language zealot/missionary to figure out a way to weasel in his pet language into a company. Plus, you’d probably end up being average or good at many languages but a master of none….But lets pretend that it is a benefit to the developer. Developers need to realize that there are implications to being polyglot.

Maintenance Nightmare

So, you’ve added a Ruby module to that big flagship Java application or product your company is so proud of. You did it fast. It works. And management loves you for it. They love you so much for it, they’ve promoted you to software lead and now you are running a brand new project. Now that you’ve left your polyglot project, somebody needs to take over your work. Unfortunately, your group is a bunch of Java developers. For any bug that needs to be fixed, these developers need to be retrained in Ruby, a new Ruby developer needs to be hired, and/or a Ruby consultant/contractor needs to be brought it. Multiply this by each language you’ve introduced to your project.

Refactoring Nightmare

The JVM is pretty cool now. We can run Ruby on it, Python on it, and even PHP on it. Your JRuby apps can work with Java APIs. Same with Jython and JPHP. Great. So now your developers can use any one of these language to build out extensions to your Java app. But what happens when you want to refactor one of your re-used Java libraries? OOPS!!!

Installation Nightmare

Ah, so you’ve weathered through the maintenance and refactoring nightmares and you’ve finally shipped your product. Hmm, but you’ve just added the complexity of installing multiple runtimes on your user base. Its not hugely bad if you’ve used the JVM as your base virtual machine. But you still need to package and install all the appropriate Java libraries, Ruby gems, and Python libraries on the appropriate places of your user’s machine. You also need to hope that all the desparate environments don’t conflict with anything the user has already installed on his machine. And that’s just with languages running in the JVM. Imagine if you used vanilla Ruby, Python and Java all as separate silos!

Support Nightmare

A support call comes in for your product or application. Its obviously a bug, but where is the problem? Is it your application code? Your JVM? Your Ruby VM? Your Java library? Your Ruby gem?

All and all, let me put it this way. We all work in multi-national environments. What if each developer documented their projects in their own native language, because lets face it, they are most productive in that language. Where would we be? Doing what’s best for oneself isn’t always best for the big picture.