As those who listened to my WebDev Radio interview know, I am working on a book on polyglot programming. This has me asking smart people what they think about polyglot programming, and one of the most surprising pieces of feedback I’ve gotten (from Grails podcast, among others) is that polyglot programming is somehow “too hard”: that developers aren’t smart enough to handle it. This strikes me as an odd complaint.
Polyglot programming, defined most simply, is the use of multiple languages in software development. Although Neal Ford claims to have “accidentally coined” the term, the term predates Neal Ford’s Dec 2006 blog entry: for evidence, see a 2002 Dr. Dobbs article on .Net polyglotism, and a 2004 DARPA presentation on the Babel polyglot support system, which has whitepapers dating back to 1998. So the term itself has been around for a while.
The idea that underlies the term has been around in some form or another since C became the Universal Assembly Language: interoperability with C has always been critical for projects like mod_* (perl, php, rails, caml), which bring non-C code into the Apache web server. Now we’re rediscovering interoperability by having languages interoperate on the JVM. This opens up a new freedom to pick the right language to solve the problem at hand for Java development.
The reality, though, is that we all do polyglot programming all the time. We use command line scripting languages to simplify our lives, and build languages to manage repetitious build processes. In the sphere of web development, we’re regularly working with regular expressions, JavaScript, and declarative languages like XML, CSS, and SQL (or its derivative, HQL). It’s exceedingly common to see jobs looking for developers who can write both an ActionScript front-end and a JVM back-end (Grails, Roo, whatever). I worked at a shop where we used perl for file processing and fed those into a database, just to be consumed by Java batch process. One gig had service calls from Java to .NET in order to interoperate with Microsoft Office products. In none of these cases did the architects sit around and go, “Oh, man, we can’t implement that solution: people are just too stupid to handle it.”
Sure, everyone has a specialty: something they’re better at, and nobody is going to be an expert at every language at the JVM. But recognizing that a particular problem (e.g. highly concurrent processing) is vastly simpler in another language (e.g. Clojure) doesn’t require expert-level capabilities in that language: it just requires familiarity. Writing that solution in that language then becomes an opportunity to learn and develop in that alternative language, and learning a new language isn’t that hard once you’re used to doing it, especially if there’s a more experienced person (or a mailing list!) to help out.
When developers encounter a new DSL, they don’t throw their hands up in the air and declare that they need a specialist in the DSL to code the solution—previous experience, context, and support makes coding this new DSL accessible. The same is true of domain-agnostic languages, but we’ve somehow built up this entire damaging and false sense of identity wrapped up in the language we code: we can sometimes too-closely identify as a “Java person” or a “Ruby person” or a “Groovy person”, and so changing languages means changing identities.
Part of the difficulty is also that the nature of software development has transitioned in large swaths of the industry. As I noted in my ancient The Programmer is Dead; Long Live the Developer! post, actual computer programming is often not the part of the job that pays the bills. The part of the job that pays the bills is understanding how to appropriately tune the O/RM, or knowing how to use the newest and bestest TDD framework, or understanding the particular intricacies involved in deploying to Google App Engine or getting Google Maps to display what you want. Brian’s right, and Programming Doesn’t Suck! Or At Least, It Shouldn’t: but a lot of what developers do these days barely constitutes programming. It’s just configuring and gluing together these bits and pieces in order to get the particular effect we’re looking for.
Given that background, shifting to a new language also seems to imply learning a whole new set of tools and surrendering a lot of hard-won knowledge. And for communities that aren’t used to learning a whole new set of tools regularly (i.e. everyone except the Ruby community), that can be really intimidating. Thankfully, sharing the JVM platform means that you can pull those tools forward in a lot of cases, and polyglot programming specifically means that you can keep using your old tools to do the things they do well, but you can still evolve your coding towards more productive and appropriate languages.
Even better, polyglotism on the JVM means that you can have gradual adoption for languages: if you end up making a wrong choice of language, you can shift off the language and rewrite that code out of existence whenever you have free time; if you know a language is a right choice but don’t know it well, you can write the parts you can handle in the new language and fall back to the old language solutions when things get tricky or novel.
I hope it isn’t too much longer when polyglot development manages to break its way into the mainstream of technical conversation. And I’m saying that as a JVM software developer, not just as a guy writing a book on the topic.
15 Comments
Hrm. Here’s a feeble critique of polyglotism: Polyglotism is the worst idea I ever heard (Saying “OOPS!” isn’t a particularly strong argument.), shared with me by Surya Suravarapu (@surya_s). At least it’s enumerating some concerns.
I spend most of my day flipping between python and javascript. Aside from the occasional syntactical mix-up, I think my brain is handling the ‘stress’ of two languages just fine. If anything each language I’ve learned, or even dabbled with has provided me with insights into the other languages I use. It wasn’t until I picked up some of the basics of lisp that I realized how useful javascript could really be.
I hope I’m not one of the “smart people” who thinks most programmers are too stupid to learn new languages, especially given how much time I spend ranting on how programmers should not only learn new languages, they should learn new, obscure, weird languages like Ocaml and Haskell.
I’m not sure when the term polyglot first got applied to programming, but the idea has been around for years. Way back in the day (before Python, Ruby, Java, et. al.), it was common to be able to link your C, Fortran, and Pascal code all together- by running Bash scripts driven by make. You young whippersnappers, get off my lawn!
It’s about exposure. If you are in an environment where you have others around you that do more than one language you will pick them up. You will cross train and you will use the language that fits the problem. I’m in a “java” shop that said everyone of is either comfortable with or has exposure (they could solve a problem with) duh java, jython, groovy, grails, objective c , c , c++, cobol, plsql, esql ….. Even our jr devs have to do this.
It’s exposure you have to create the culture.
Reasons to use more than one language are the following:
1. It is the quickest path to solve the problem cause that language is the right tool.
2. See #1
3. Your a developer and your lazy.
4. Your building a “SOA” solution and don’t have time to tell the flat file cobol guys to learn something else.
5. Your lazy
Anyway …
I’ve started programming professionally as web developer. Since I was /forced/ to learn Perl first, then PHP3/4/5, Java, .NET and a everything that is coming — I’m currently working with Python (Django) and Java (GWT, WebServices, JEE and Enterprise Architecture based applications) — as /new languages/ to keep myself updated, I’m a polyglot programmer. Those languages run just in front, but I’ve worked on daemons using C, extending complex stored procedures in C under PostgreSQL, building Python and PHP Extensions, programming in both PL/PGSQL and PL/SQL and a lot of technologies that are in my mind now, such as SGML and XML.
I think that most specialized web developers are working in many areas than just a few languages, but this is because it is required. This is not about just installing WordPress and gluing plugins or even modifying them, there are many systems running complex architectures that needs a good knowledge on many technologies and their capacity, and most them demand knowledge on many programming languages, and then polyglot programmers are formed by those kind of systems. Then, the programming basis are important, good knowledge on the platform they are working on is important.
Hi Robert,
Hope all is well.
Well spoken! As you said almost all software projects today are polyglot. You’re spot on. We can handle it, and the JVM is just making it easier.
Mark
Maybe for some coders, polyglot is workable. But for the shop I work in (and the ones I’ve seen in the past), I’m afraid polyglot programming is just a way to chase the latest language fad.
It’s plenty enough to ask a coder to follow any of the backbone-languages (Java, C#, C++, I’d even throw in Python.) Each are progressing at a rapid clip– to really write efficient and elegant code means understanding spec changes and maybe even refactoring some of your past efforts.
Do I know programmers who can write ‘workable’ code in several languages that will execute and even produce correct results? Yes, of course. Anyone can write simple code in a variety of languages. Do I think there are many programmers that are capable of writing (and maintaining!) truly excellent (elegant, efficient, maintainable) code in more than a couple of languages? I don’t. Not by a long shot. Think of the truly big names in programming– how many are associated with even more than 1 language?
My .02 worth. Don’t let me discourage anyone from learning new languages– just don’t try to use them all!
Rick
I think that Polyglot programming is a good thing. I do it.
But, I found that most devs are lazy :D. Really.
The thing is that being a “real” (read: efficacious) polyglot programmer *is* difficult and requires ingraining the paradigms (kill me now) of the languages in question.
It’s been my experience that the bulk of developers have difficulties getting through *one* language, let alone many–as a simple example take Java web developers who might be passable at Java, but code JavaScript the same way. For JavaScript, that’s just not the best way to go.
Being polygottal requires focusing on being polyglottal–absorbing the mindset of the languages in question, not just passing exposure.
Of course it’s hard to master and keep up with more than one language, but sharing the JVM means you don’t have to: you can still use your old tools when necessary and then “drop in” to the other language to accomplish the thing it’s best at.
This idea that you have to truly master another language before you can adopt it or gets its benefits is one of the key things we have to shake from our heads. Certainly there are advantages to mastering other languages and learning to work within their paradigm more fluently, but mastery isn’t necessary to get advantages from a polyglot system like the JVM.
Sure, when you first learn a language, you’re going to code it in a way that is more familiar to you. And being able to still be productive while doing that is a Good Thing: if you can get a boost by the nature of that other language (e.g. Clojure’s concurrency), that’s great, even if you end up coding Clojure that looks like Java with parenthesis in the wrong place. If you need to tune/refine that code, you can bring in/develop Clojure expert skills at the point.
One of the things I postulate is that we’ll see more and more languages that do a few things and do them well: languages that really target a particular area as a key advantage that they offer. And these languages are going to continue to get substantial press and interest.
Re: debugging, which has come up a number of times (cite, cite).
Tricky debugging is true of any new technology, and we overcome it over and over again when we need to. JVM bytecode provides the hooks necessary for debugger tools to be seamless, so it’s time for the IDEs to step up and make that smooth.
But this points out a larger issue: part of the reason it’s easy for me to move from one language to another is that I code without an IDE. I’ve grown to hate IDEs over the course of my career: with the exception of mechanical manipulation of Java files, I’ve never found them to provide a productivity gain over a few bash scripts, vi, and a language that doesn’t suck. My experience with IDEs have been that they’re always buggy, heavy-weight, touchy to configure, and annoying to upgrade, and worst of all, they’re almost always language-specific (with other language support being a clear bolt-on). I hope that this is one thing that changes as we move forward into our polyglot future.
The one thing I occasionally miss is step-debugging1, but even that’s usually a sign that I’ve got too much going on within a piece of code, and logging and TDD provide most of what I’m looking for, anyway.
1 A stand-alone Java step-debugger akin to Firebug’s JS debugging would be cool.
I too have grown to hate IDEs over my career. They are billed as productivity enhancers but I think that in the long run they are productivity killers.
First, and this is undeniable, IDEs are a productivity sink in that you have to learn how they work, how to configure them, how to upgrade them, how to import code into them (if necessary) etc. Of course if the IDE gives you more productivity than it takes away it’s a net win. This is has not been my experience, mainly because of my next points.
Second, one of the biggest sells for IDEs is autocompletion. Autocompletion is the crack cocaine of the programming world, it feels wonderful at first, but in the end not healthy. It encourages a certain style of programming, which in the end a programmer has to transcend to make an order of magnitude jump in productivity. There no one set of things I can identify as the culprit here, but I think the overarching problem is over reliance on static typing to make the autocompletion mechanism happy. I am not casting aspersions on statically typed languages (though they more easily contribute to the problem). But, a programming style which emphasizes dynamism over static information, dsls over standard language constructs, declarative constructs over procedural constructs, dynamic reflection over static information, meta programming over standard programming does two things. It makes you more productive and it gives autocompletion fits. If you insist on autocompletion you may have to give up one or usually more things that will make you more productive in the end.
A third problem is the concept of step debugging. IDEs excel at this. Code without bugs is a good thing, and debuggers help you find bugs, so what’s the problem? The problem is step debugging makes less sense as your code is less easily mapped to a von Neumann architecture. Yet, more productive languages and styles move you farther and farther away from a von Neumann style of execution, so step debugging makes less and less sense. How does one step through a groovy builder? A lisp macro? A lambda function? A function composed from other functions? Functionality based on a configuration style of programming? The list goes on. Of course one can define a way to step debug through all of these things (and yes I am aware that some IDEs provide valid ways of doing all of these things), but it’s not obvious, it may not be very generalizable, and in the end it may end up being more trouble than it’s actually worth. As a general rule if your code base benefits substantially from step debugging I would argue there is something wrong with your code. I of course would make an exception for very low level code, though this is less and less common these days.
I think what a lot of you are missing here is the issue of maintenance, installation, configuration, and support which are all orthogonal to whether or not the developer is “smart enough” to handle the context switching.
@Bill
Check my upcoming Manning book and the September NFJS Magazine, both of which address both of those points. The book talks about some of those approaches, and the September NFJS Mag is on the wonderful boundary between OSGi and polyglot programming.
I’d be interested in hearing specific concerns you have on those issues.
More interesting blog posts via Grails Podcast.
Are polyglot systems a good idea?
Delivering Business Value Through Polyglot Systems (part 1)
Polyglotism is the worst idea I ever heard
5 Trackbacks
[...] reading Robert Fisher’s article about Polyglot Programming, I decided to make a list of languages used frequently on my current project 1 (in no particular [...]
[...] Robert Fischer, We Aren’t Too Stupid for Polyglot Programming [...]
[...] Polyglot programming. I think what makes it so difficult is that the debugging tools to do it really aren’t there. [...]
[...] We Aren’t Too Stupid for Polyglot Programming [...]
[...] numeric tower, etc. etc. These things are frustrating if one happens to be working in a polyglot environment, but I’ve no doubt that necessity will draw the larger players in the JVM language space [...]