Polyglot Doesn't Fix Your Messy Architecture
Posted by Nick Sieger Wed, 15 Sep 2010 20:12:00 GMT
One of the problems we have as members of the JRuby team is to convince a Java-based audience that programming in a new language is worthwhile. As a result, we consider ourselves proponents of so-called “polyglot programming”. One of the opening points I made in my talk addressed arguments for and against polyglot programming.
I usually try to make a case along the lines of “learning a new language is good for you anyway”, which can come off sounding a little patronizing, like I’m reminding the audience that they should take their vitamins. While I do believe practicing multilingualism (or polyglotism) with computers is good for your programming career, I wouldn’t like to be admonished by the speaker if I was in the audience.
This time I took a different tack. I’m not sure if it’s a convincing (or even supporting) argument in favor of Ruby or polyglot, but true nonetheless.
First, I likened a software project to a physical workspace. When you use a new language in your project, you make a new space for stuff. Maybe like adding a bookshelf or some binders or a filing system.
Problem is, if your idea of organization is analogous to the cluttered desk below, adding a new language is just going to pile one more binder onto the mess.
On the contrary, if you have a well-organized project, adding a new language also doesn’t necessarily automatically make your project better, but it does give you capabilities that you didn’t have before.
In the end, polyglot programming won’t fix the messy architecture and organization of your project. If you think adding Ruby to the project will make things better by itself, you probably shouldn’t be thinking about it in the first place. Ruby can be used as a tool to clean up the mess, but only if you actually clean up and remove it, and not just paper over it.