One language to rule them all?
Is the polyglot programming phase over? A cry for simpler Java
Over the past few years, many have advocated a polyglot approach to application development - a concoction of different programming languages (each with their own set job), all melding together to form a cohesive piece of software.
The craze seems to have been spreading like wildfire in the middle of the last decade - we've seen Groovy and Scala arrive on the JVM and receive praise from all quarters for their different approach to problem solving. Even Google stepped up to the oche and launch their own encompassing Web application support recently, aiming to hit a bullseye with Dart.
In turn, we saw new theories regarding multi-paradigm programming languages pop up such as Martin Fowler's coining of the term 'Language Orientated Programming' - prophesying a new breed of programming and tools, or 'Language Workbench' for the job, that married all languages under one roof. Neal Ford's proposition of Polyglot Programming looked like a sensible one - advocating the combination of languages within development so you could call upon the best when needed
Whilst it's great to have an array of options for a job, the embarassment of riches can often lead to crossed wires. Many bloggers have, metaphorically speaking, been at each other's throats often in recent months engaging in bitter arguments over the benefits of one language over another. So the question is - is it time to return to a simpler universal langauge development environment after flirting with a multi-paradigm approach?
It's an argument raised by Lofi Dewanto who cites a number of
reasons in his blogpost 'Why "Polyglot Programming" or
It Yourself Programming Languages" or "Language Oriented
- the difficulty to be fully proficient in one language, let alone three or four
- Project complexity increase with the addition of languages- the example of a Struts web application contains:
- Various programming languages don't have strong enough material or infrastructure to support it to enable others to learn - Groovy is an example Lofi uses here to back up his case. Early Eclipse editors weren't up to scratch and updates nullified old versions of code when you had to update.
- The risks involved when creating your own Domain Specific Language (DSL) -
Before you discuss with them don’t ever create your own DSL. Especially if you are working for SME (Small and Medium sized Enterprise). With a small team and small budget you will never ever maintain your own language decently.
Unlike some, he does offer a solution to the pitfalls of polyglot programming, wanting to see 'one language for all aspects in one application' created in the next year or so.
My best solution sofar is Java + XML, that’s it, no more, no less. No mixing with Groovy, Dart, Ruby, Scala, << name your DSL here >> in one application. Especially if you are working as contractor, please don’t try to use all those languages just for a small Java web application. I don’t say that you should not use the other languages at all. The only thing which is important is not to mix those languages in one application. In SME you maybe also want to use just one programming language for all your applications.
The conclusion of a pure and plan Java caused a split reaction between those who commented. Pierluigi Vernetto offered the following:
I agree BUT...an application should be written in only 1 language, for sake of simplicity, agreed, but often accessory tasks like scripting the configuration of WebLogic domains need to be written in Python or Groovy... and honestly introducing the opportunity to learn a new "hot" language like Scala can attract on the project the best programmers.... surely the risk is that people lose focus and play with the technology...
anyway this is not a perfect world... it will never be...
This appears to be the main stumbling block. With so many languages now on the JVM, it becomes ever more difficult to keep up to date with every single one. A developer can't possibly be expected to be efficient or able to work at their full capacity. But with barely any project being pure Java, as Christoph Adamek notes, this appears to be the best compromise:
What you can do is to use a flexible language which allows for internal DSLs. You can adapt the language to your problem by in fact creating several variants of the base language. Classic example is Lisp but you can do it with Ruby and Scala, too. Certainly not with Java.
A solution to this long debate doesn't appear to be near, but we'd love you to offer your thoughts and share your polyglot programming experiences below...