Polyglot Programming: Flawed Dream?
Polyglot Programming: Flawed Dream?
Join the DZone community and get the full member experience.Join For Free
Bring content to any platform with the open-source BloomReach CMS. Try for free.
I’ve been reading for some time various articles and blogs about Polyglot Programming, and the perception I got is there are two opposite views: the ones preaching it and the ones that tried and it didn’t work for them. IMHO, the points made by polyglot programming enthusiasts sound indeed pretty attractive, in theory. I haven’t seen any practical evidence yet to convince me this is a good idea.
The right tool for the job?
The main point made by “polyglot programmers” is to “use the right tool for the job.” Sure!…it sounds great. IMHO, there are some hidden issues in this statement. First of all, to choose the right tool we need to have a deep understanding of the available tools *and* the problem itself.
In the case of programming languages, I think it is necessary to know a language beyond basic familiarity. IMHO, it is not enough to read a book and put together a couple of cute little exercises. Learning the syntax of a language is not enough, we need to learn what makes a particular language different. For example:
- How mature is the language (and its libraries?) Who’s behind it?
- Tool support: is there IDE support for X language, or do I have to use a text editor? What about debugging and refactoring?
- Static typing vs. dynamic typing?
- Paradigm: OOP? functional? hybrid?
- Closures? Metaprogramming? insert-your-cool-feature-here?
- Corner cases in a particular language
- What about testing? are we using a separate language to write our tests?
I think we need to get the “feeling” and “style” of the language: I don’t want to write Java code in Groovy or Java-esque code in JRuby, just because I can. When using an alternative language, I’d want to use the features that makes such language a better choice.
Learning a programming language well enough takes a good amount of time and effort. It is too easy to “think” we know one and go ahead and write spaghetti code. The same applies to the paradigm behind the language. For example, Java is, IMHO, one of the simplest programming languages. Object-oriented programming has been around for many years (1960?) How many of you have seen horrible code in Java, written by “senior developers”?
Bottom line is, do we really have enough knowledge and experience to pick the *right* programming language?
In an ideal world, we can spend as much time as we wish learning programming languages to choose the right one to solve the problem at hand. Unfortunately, we are constrained by both time and costs. I think the noble goal of polyglot programming can easily degenerate into:
- endless meetings, in an effort to agree which one is the *right* language, or
- take the decision lightly, for example: “concurrency in Java is hard, therefore we use a functional language”
Either way there is a risk of wasting both time and energy, either at the beginning or during the project life-cycle, which translates into wasted money.
Another hidden cost is the cost of integration. In a private conversation, my good friend Steven Herod brought up an excellent point:
Well, its the obvious problem, is the benefit of best of breed outweighed by the cost of integration?
You can see this even at the application level, is the best accounting system + the best CRM system + the best billing system better than a single system which does all functions, but not as well.
In most cases, you burn so much effort glueing things together that whatever productivity you get from a good tool is lost….
IMHO, we also need to have the following in mind:
- how possible is to refactor code across multiple languages? do we have to perform a text-based, error-prone “find and replace”? (especially when mixing languages with static and dynamic typing)
- is it hard to navigate through layers of code written in multiple languages?
- how hard is to switch from one paradigm to another? (e.g. object-oriented and functional)
- are any supporting materials necessary? (e.g. books, magazines, training classes – all of them cost $$)
- how easy, fast and cost-effective (and actually possible) is to hire somebody that knows the languages and tools used in the project? are consultants needed?
As we all know, the most expensive part of a project is its maintenance. Polyglot programming supporters talk about the productivity gains when creating an application. Sure, this is great if we are all consultants that write applications, and leave them to the clients’ IT staff for maintenance. Till now, I haven’t heard about maintenance or bug fixing of a “polyglot” project. Writing code is always easier and more fun than maintaining it ;)
I’d sincerely love to read more about success stories of polyglot programming. Not just how great polyglot programming is, but some explanations about:
- project size/scope
- team size: how many master programmers? how many journeymen? how many junior programmers? what about their background?
- what programming languages were used? why?
- who picked the programming languages used? how was the selection process?
- what type of training was necessary (if any)?
- tools used: any IDEs? text editors?
- what were the benefits of polyglot programming? improved productivity? reduced costs? more fun?
- how easy was to find answers when having technical issues?
- agile or waterfall? or something else?
- were more developers hired for the project? at which stage?
- how was testing performed? what about continuous integration?
And no, pet projects and demos do not count.
I’m skeptical of polyglot programming. Although it sounds good in theory, there are factors that need to be taken in consideration before mixing several programming languages in a project. I’d like to learn more about success stories of real-world projects. Until then, supporting polyglot programming sounds more like cheer-leading to me :)
Opinions expressed by DZone contributors are their own.