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.
Finally
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.
