Polyglot programming environments

We are forced by the nature of our products to be a polyglot environment. We have a server software you can install on promise which is implemented in C. This server interacts with different databases. Many types of client software connect to this server ranging from command-line utilities for system administrators to sophisticated calendar applications on desktop operating systems. The clients we implement ourselves range from single page web application implemented mostly in JavaScript to native mobile client on Android implemented in Java.

As you can see we do not have much choice. However, we do not see this as an issue. We question our past decisions and at least spent a moment here and there to think what technologies might have suited us better given what we know. Where others see value in coherent environment, big frameworks and general purpose languages, we try to see the best way to achieve our goal. Having cohesive software environment is just one thing to consider on achieving that goal, not a mantra.

Coobooks in many languages

This, I believe, has many advantages. Similarly to knowing more human languages, simply knowing more technologies often broadens your horizons. Suddenly, you are not limited by pundits of language-of-your-choice community, by framework authors or some technical committee. You have more freedom and more intuition at the same time. You see problems in different perspectives. Since computing is a large space, you can find and learn radically different paradigms, like in human languages, which in turn can helps even more.

Large part of our code base is written in JavaScript, a.k.a. The World’s Most Misunderstood Programming Language. JavaScript is a general purpose programming language which looks like C but has properties of LISP and other “weird” languages. Our first project in JavaScript was built on top of SproutCore application framework which tries to bring properties of Cocoa environment from OS X and iOS to the web. It is influenced very much by original concepts of object-oriented programming which is something not found in C, nor any other of those “weird” languages. Then, we started working on Mozilla Thunderbird extension which is also a task mostly solved by JavaScript. But it was a very different experience and actually we were lost for some time. The whole platform suffered from over-engineering so typical for Java ecosystem. We tried to shield ourselves from it firstly by introducing some concepts we learned from SproutCore which did not work well because Mozilla and SproutCore are both very rich and very different platforms.

We actually found the answer in the origins of JavaScript, in LISP – a strange beast from functional programming world. Our code became lighter and different. It is hard to pinpoint the exact moments where such changes occur unless they happen in big batches which we consider a bad practice and try to avoid it. The exception that proves the rule and one of the most significant changes was rewrite of our XML-RPC module which is visible in commit dda11c0 – XML-RPC components replaced by a module. A combination of OOP and FP resulted in removal of more than one thousand lines of code yet preserving expressiveness of the source code, I’d even say improving it. Funny thing was that some aspects of SproutCore started to make a whole different sense than before and we were able to use them more gracefully.

Embracing the polyglot nature of software development, not fighting it, simply boosted our ability to understand the tools we are using and to utilize them better. I am personally always terrified when I see software shops sticking to one technology stack. To me, they seem like a boy building muscles only on one hand, not the whole body. There are times you have to show what you got and you cannot choose what to use, so it is better to be prepared.

Leave a Reply

Latest Posts


Get the latest news first via email, RSS or social media.


Technical support
+420 776 172 646

General inquiries