Six Enablers of Multi-Language Programming
July 21, 2008 – 6:29 pmMulti-language programming is a popular topic nowadays. Subjects like domain-specific languages (something near and dear to my heart, as it is at the core of what my company does), “using the right tool for the job” and leveraging the rapid-time-to-market enabled by dynamic/scripting languages are all much discussed. Now, I have my reservations about this becoming too popular. Certainly I dread the prospect of engineers coming to me to push why we have to use Ruby for our next project, and how it will make us more productive, better looking, able to run sub-4 minute mile, etc., but in general as a trend I think it’s an exciting one. It’s great to see all the cool ideas out there, and a lot of the conversations are making us (as well as our chosen development platforms, as they adopt the best of what is available) a lot smarter. So here is my list of the top six things that make it possible:
1) Free, easily accessible information
Via forums, websites and search tools, especially Google, the wealth of information available to developers online is incredible. Yeah, obvious I know, but it helps. A lot.
Learning a language is not like learning a framework. If I wanted to learn about Ruby On Rails. Or Spring. Or Hibernate, buying a book is oftentimes a sufficient resource. That does not mean that you won’t need to refer to other resources, but these tools are of such a size that they can be covered fairly comprehensively in a single volume. This is not the case for a language platform - here a book might be helpful in learning the basic syntax and features of the language, but language platforms also come with extensive APIs. Non-online resources that document APIs tend to be less than exhaustive, often just repeating in book form the core API documentation that ships with the language. If someone wants to quickly come up to speed on the XML handling facilities that are available, or the IO-handling classes, there is often little in a written form available. However, searches online will usually discover concrete examples by seasoned practitioners; this information is invaluable. Also, it goes without saying that these resources are very useful for when strange issues are encountered, and it is very common that when a roadblock is a hit, a simple Google search will return the precise remedy (it’s interesting - and a little bit awing - to contemplate the impact of this single factor alone not just with respect to multi-language programming, but development in general….its hard to overstate what a dramatic positive effect this has had on debugging).
2) Evangelism
The online community makes it much easier for people to rally around something. This is similar to the first item, but what I’m talking about here is not so much information about the language as providing forums for people to advertise and evangelize these new tools and techniques. I think many go overboard in their praise of the new, but the fact is having an enthusiastic, energized and vocal group of folks behind a technology is really essential to popularizing it. I can feel a lot more confident that Ruby is a good choice for application development when I see so many prominent people recounting their experiences with it and encouraging me to use it.
3) Language convergence
Languages today share much in common with each other, and they borrower extensively from one another. Obviously there is also a great deal of diversity; people wouldn’t be looking for new alternatives if there weren’t diffences. However, the fact is that the rate at which innovation is happening with languages is because of the acceleration of understanding of the features provided across the board. A good example is the history of .NET. .NET, and especially C#, obviously borrowed heavily from the design of Java. In fact, I would say the initial releases represented really an incremental refinement and perfection of the Java language. But they have not stopped there. The additions of lambda expressions, implicit typing, and generics are obviously taking their inspiration from other sources. This creates a bit of a feedback loop where the availability of these features in all languages, as well as the awareness of their existence on the part of developers, makes it easier in turn for developers to explore other languages, thus causing them to push existing ones for the inclusion of these items. My experience with delegates while programming in C#, for example, has made me extremely eager to see them added to Java.
And yes I know there was sharing of ideas before the internet. I’m not saying it created it but that it has accelerated it.
4) Virtual Machines
Virtual machines, both language level (JVM, CLR) as well as OS level (VMWare, Parallels), have made it much easier for folks to program in whatever language they choose, regardless of what platform they are using. People can pretty much develop on whatever type of machine they want, and deploy to whatever target hardware they want. I’ll use another example from .NET to illustrate this: for a long time my primary desktop environment had been Linux, and it is now OS X. However, I still do a fair amount of development on the Microsoft platform, and there’s no problem for me with this, in spite of my choice of operating systems. I just simply boot up VMWare and just like that I have a pristine dev environment that sacfices little versus having a dedicated piece of hardware with that OS. This a huge advantage for developers.
5) Development Environments
The sophistication and ease-of-use of modern IDEs makes the task of switching languages much, much simpler. The fact that I can fire up an IDE (often I can use the same one for a different language - both Eclipse and IntelliJ have extensive support for a slew of languages), and start utilizing code and syntax completion, as well as use features that create projects using best practices, provide wizards for common tasks, and contain RAD lifecycle tools for updating code and automatically pushing it to a server/container. All of these features significantly ease the learning curve, and increase productivity.
6) XML and other language-neutral data formats
Lately there seems to be re-examination of XML going on. Personally, I always felt it was over-hyped, the supporting tooling is still sub-par, and the specifications are often atrociously over-engineered (XSD, Soap, XHTML, take your pick). There is though at least one great thing about it: every platform supports it. And everyone agrees that we need easy-to-use formats for language interop. Now, these things did exist before; CORBA and EDI are two noteworthy precursors. Not having used them much I can’t comment, but everyone I know who has worked with CORBA tends to shake their head and say never again….so not exactly a ringing endorsement. Anyway, having these common interchange mechanisms available makes life much easier and seriously lessens the impact of using multiple languages/platforms.
To cite a real-world example of all these things coming together, I recently did a project that used Objective-C and Cocoa as the client development platform, with Ruby on the server side. I have done some work in Ruby in the past, so it was not totally new to me, but I was a complete noob with respect to Cocoa and Objective-C, other than having used C some time ago. Using two great IDEs (Aptana for Ruby, based on Eclipse, XCode for Objective-C) I was able to quickly become productive, and when I ran into issues there were great resources online to be found. I felt good about my choices based on recommendations from colleagues I trust as well as all the online “mind-share” around these technologies (the iPhone is obviously a hot subject now, and Ruby is probably the most buzzed about server-side language), and most of the concepts I found in these languages I had some familiarity with based on my OO and procedural background, as well as the work I have done in the AI arena. Interaction was handled using YAML (I told you I don’t like XML), which was easy to implement on both sides. And of course, deployment was a snap - I’ve got an Apple provided VM for testing my iPhone app, and I’m going to be deploying my Ruby code on a Windows server I have at home. It’s a beautiful thing, eh?
-John




2 Responses to “Six Enablers of Multi-Language Programming”
Your comments about language convergence focused on language “features” rather than language “paradigms”. The chief language paradigms (a much-abused, over-used term) are procedural, object-oriented (class-based & prototypal) & functional (pure and impure). C++, for instance, received great scorn from the fledgling Java community in the mid-90s for being a “multi-paradigm” language (procedural+object-oriented+templates). Smalltalk nabobs criticized Java for not being a “pure” object-oriented language, because int/float/double/char were not objects.
Now, 2008, we bow before the multi-paradigmatic god, with Java/C# (basically the same language) looking more and more like C++ with memory management: static imports, closures/delegates (first-class objects not function pointers), generics (lame C++ templates), auto-boxing (take that, Smalltalk bigots!) and last, but not least, annotations/attributes (C/C++ pragmas).
The apotheosis of this trend is Scala (http://www.scala-lang.org/), a very powerful, but byzantine, language that combines object-oriented (classes, traits, yadda-yadda) & functional (“val” vs. “var” declarations, pattern matching on data types, etc.) paradigms. In practice, a complex language like Scala tends to diverge into multiple dialects, any number for each paradigm or weighted multi-paradigmatic combination. Expertise is diluted. Deciphering colleagues’ code can become exercises in learning multiple domain specific languages whose domains are far from obvious. Why not just learn some flavor of Lisp (Scheme, for instance) and crank out domain specific syntax with its macro facility instead?
Personally, I would like to see a family of simple, pure languages communicating via a recognized protocol. Sound familiar? How about languages like JavaScript, a for-real, prototypal object-oriented language, communicating via JSON with functional languages like Erlang (optimized for 24-7 concurrent/fail-safe execution) or Haskell (strong abstraction & type inference facilities) or Clean (dealing with imperative realties without resorting to monadic obfuscations).
In short: the software future is more functional. We must deal with the hardware future: multi-core, multi-processor, mobile, distributed computation hardware.
By Hugh Gilmore on Jul 22, 2008
Thanks for the thoughtful comments
I really can’t speak on functional languages as you know (though I hope to remedy this in the near future). From what I do understand, they provide an intriguing solution to handling multiprocessors. Though I think its worth noting that a decent container with a builtin threading model (Tomcat, Axis, a million other options) is also a good, simple solution for many applications looking to take advantage of SMP(at least multi-user ones).
Though I think there’s merit to what you are saying about feature-bloat in languages, I do think well done language blends are useful (I think what .NET has done is a good example of this….their primary architect, Anders Hejlsberg
has done a nice job of implementing features that are both powerful and readily-accessible to newcomers).
Everything and the kitchen-sink approaches are not the answer, but I think there is a place for a “greatest hits” approach, though I think it’s going to require a lot more work and implementations before the dust clears on exactly what constitutes this best-of.
Either way, I do think it’s exciting. Certainly more interesting than when everyone was buzzing about how to make their applications as bloated as possible (EJBs, Web Services, thirty thousand layers of indirection) or silly “extreme” proceses, no?
-John
By John Kelvie on Jul 22, 2008