Sadek Drobi is a software engineer specialized in design and implementation of enterprise applications. Mostly interested in solutions for bridging the gap between business and developers (e.g. agile, DSL, domain driven design) he is currently working on a research proposal with a focus on language oriented programming and multiparadigm design. Sadek works as a consultant at Valtech. Passionate about his profession but also about photography, he publishes a technical blog at and maintains a photo gallery Sadek has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

And you get all the VM libraries for free! Is it actually what I want when I switch languages?

  • submit to reddit

So it is getting more and more interesting. A vast number of languages available. And they are even available on your favorite platform. So you may not need anymore to beg for a process of changing a deployment environment to change your programming tools. It is all changing, and you may now start thinking about what language or paradigm suits best the domain or even the sub domain you are trying to model.

Everyday we hear about languages implementations on the JVM or the CLR. Every language has its own taste and semantics. All of these implementations try the best to satisfy an important second promise which is leveraging the preexisting platform libraries and giving an easy access to them from within that language. So on the CLR you get a promise of an easy access to all the .NET framework, and from Java, well, to the J2EE enormous libraries.

Well designed .Net libraries might be bad designed F# libraries

Some days ago I was trying to solve a small problem using F# (a new member to the .Net family). The reason I chose F# for this problem is the functional paradigm, my specific problem was easier to model using functional paradigm than any other paradigm. What I noticed while using F# is how easy it was to access the large .Net libraries, but I also noticed how can that potentially affect my way of programming. As I already mentioned the reason I chose F# was its semantics, I realized that .Net don’t talk F# and to access it I had to program with its semantics: imperatively, with a command like style almost dropping the expression oriented style that was one of the reasons I chose the language for!

Worse, this drew my attention to how this promise of 100% integrity with the preexisting libraries can affect the language design and implementation. Looking at implementations of popular languages like Ruby and Python on the JVM/CLR one can notice concepts that have almost forced in the languages (like attributes and signatures) . I guess these additions add noise to the language and to the code written with them, but that leads to an important question: How languages should communicate in a multilingual project? And what and where should be the seams when communicating between them?

Some libraries and frameworks are not even necessary for other languages, some just don’t fit, and some need to be wrapped and adapted for the new language

Before trying to think how to communicate between languages, I need to think about what is the kind of libraries I need for the new language. I mean of course it might be technically possible to use Spring and Hibernate when programming JRuby. But in case it is your first choice then, I guess you might be missing the point. There are a lot of frameworks and libraries that have been constructed because of limitations of the language. That is why you need to think twice before just accessing a foreign library because it might be supported natively by your language of choice or its supporting libraries.

Nonetheless , there are some necessary libraries that just don’t exist in your language of choice, and it would be kind of nice to have the painless access to them. But on the other hand, and as stated previously, these libraries don’t talk your language. It is somehow senseless, for instance, to specify type parameters while accessing strongly typed APIs from a dynamic language like Ruby, or say implementing strategies or writing 10 lines of imperative code for configuring a mutable object from a functional programming language like F#.

Some of these necessary APIs can be adapted for the target language. So in this case our issue is solvable by wrapping these well thought mature APIs to make them fit better in the target language paradigm. This can be done using abstractions while leaving other unnecessary details behind like state or type casting. This makes them less intrusive on your paradigm or language. Some libraries’s paradigm, however, is impossible to hide, and in this case you either need an equivalent library for your language, or you need to think carefully about your modules and boundaries to be able to use different libraries with different paradigms without one module being intrusive on another.

Understanding properties and semantics of each used language is the key to a better integration and communication

Each programming language is built and designed based on some theories, principles and concepts. Understanding these does not only help you in your decision of language choice, but this also helps you identifying where and how languages should be communicating. So for example modules written with functional programming languages can be imagined as stateless services that take an input and yield an output, modules written using OOP as holding the state, and modules written with configuration languages place some global, most probably immutable, variables into the environment. This thinking also helps defining barriers between modules to identify when the scope of one language ends for the starting edge of another.


In this post I tried to draw attention to a hairy, in my view, promise we get from language specification implementers of a seamless integration with existing libraries and frameworks. I guess in the no-fit case, the seam will be in your code and it will obscure it and add noise to your language rather than nicely being abstracted behind a foreign API wrapper. Proper design is instrumental for a non intrusive integration. Properties of each of the used language and frameworks should be considered.

Published at DZone with permission of its author, Sadek Drobi. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Ronald Miura replied on Tue, 2008/06/03 - 6:09pm

Completely agree. A 'language' is not just syntax, but also libraries. If the an API does not carry the 'feeling' of the syntax, it doesn't matter if the syntax is nice, the resulting code will look alien.

Groovy may be an exception, because it was designed from the ground up to be an 'enhanced Java', and they made a whole set of language hacks to add its 'feel' to the existing Java API. But when you adapt an existing language to a common VM, you ends up having to re-implement all the language-native libraries, and wrapping the VM-native API to fit the feeling of the new language.

And this happens not only with languages and VMs. Layout for Swing components in XML has been tried many times, but they all failed (in my opinion), because they were just thin wrappers for the flawed (complex and clunky) Swing API, including layout managers (arguably a good idea in theory, but a bad idea in practice, with a terrible implementation). Hopefully, JavaFX Script with its approach of creating a new, higher-level component hierarchy that fits better with the language (JavaFX's Widget isn't a JComponent, it HAS one) may fix a number of problems 'unfixable' in Swing. If it is not too late, of course :)

Steven Baker replied on Tue, 2008/06/03 - 8:34pm

why would you expect anything different?

Ronald Miura replied on Tue, 2008/06/03 - 9:54pm in response to: Steven Baker


Well, because the JavaFX team have a real opportunity to fix things. The Swing team never really had the chance to rethink the architecture, because of the backwards compatibility.

All I can do is wish them luck, because this opportunity won't knock at their door a second time. :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.