From my QCon09 London presentation slides.

In QCon London 2008, I had the opportunity to have an interview with one of my heros: Simon Peyton Jones. Simon has an enormous capacity of making the answer to almost any question precise and clear no matter how abstract the subject is. I Strongly recommend that you have a look at this interview if you are interested in programming languages in general. Following Simon’s talks and interviews requires almost no prior knowledge about functional programming or Haskell.

In this interview, computer scientist and researcher Simon Peyton Jones discusses properties of functional programming languages, and particularly Haskell, that have inspired some features in mainstream languages. He gives his opinion on the issues of syntax and language complexity and talks about some research work on subjects such as Data parallelism and transactional memory.

Bio
Honorary Professor of Computer Science at the University of Glasgow, Simon Peyton Jones currently works at Microsoft Research in Cambridge. He has led several research projects focused on the implementation and applications of functional programming languages. He has greatly contributed to the design of the Haskell language, and is the lead designer of the Glasgow Haskell Compiler.

Access this exclusive interview published at InfoQ.com

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.

The first time I got introduced to mutation, I had a bad feeling. How can x:=x+1 be logical at all?

It felt so unnatural, scary, or maybe like a hack. Then, because of society constrains, I got to forget the bad feeling about that. Well, my mind started to tolerate with counter-logic logic. And that is how I became an enterprise developer. I am not sure how proud I am with this title anyway. I feel that tolerating and accepting the counter-logic logic is one, and most important one, of the prerequisite to this title.

Nowadays, I am working on a project that has to process a huge number of data to do calculations on it and produce results that make sense to the user. Performance is a constraint. And I decided this time to do it the right way, the way that I believe is right. The logical way.

I decided to the calculations with no mutable state. I wanted immutability to be my guarantee to safety. Mutability breaks logic, and so produces bugs. But I couldn’t imagine how hard this choice can be. You tend all the time to feel that it is easier to introduce a mutable object, mutable flags, temporary mutable containers inside loops. Imperative programming is so tempting. Just like drugs. It feels so strange and weird in the first time, but then, it becomes a habit, a bad one, and you can’t help but to break into it. Mutation and imperative programming is the simplest thing that work in some way.

Today, I am happy I almost finished the whole calculation logic I had to model ( and it is quite a complex one). And I am proud that I could resist introducing mutability in the algorithm. Yet, I did some experiments along the way to introduce just a bit of state, kind of just what I need to introduce faster one kind of calculation. This very small mutation just breaks it all. It just breaks the whole modularity of the algorithm, and just makes the whole calculation much less generic, and more importantly less maintainable and evolutive. Such a small mutation, like introducing a mutable flag, or a global variable, just breaks the whole logic of my calculation, and drives me far away from a good modular calculation, with a good design based on plain old principles of separation of concerns. It just makes impossible to go further with the implementation! It is like a cancer of code…

Now, after the discipline and the resistance to a mutable state, we are so happy with the resulting code that yet needs polishing, makes it very easy to parameter more calculations and so add more desired functionality to the program. And just for fun, we compared it to the same calculation done with imperative programming. It is much more concise, intention concealing, and as a result, surprisingly we paid no performance cost for a much more declarative code.

I owe a lot to Erik Meijer, Paul Hudak, Linq, and Haskell :)

It has been a long time since the last time I committed posts here. I’ve been submitting quite frequently posts on the Architecture section on InfoQ community and sharing them here too. Actually I tend to like what I am doing with InfoQ. Often I think about an idea or a subject and then go to find arguments of different people about that subject. For me this is very richening and I hope that it has been informative to readers of both InfoQ and this Blog. However, sometimes I don’t succeed to find a loud argument about a subject that seems important to me. I open my blog writer to try to talk about it, mostly I fail because of lack of time. I’ve started working a couple of months ago on a very interesting project. And I can’t help but to keep thinking about lambdas and calculations.

Aside from all that personal stuff, I’ve decided this time to finish this post, to try to represent some ideas and my own opinion about an important topic that I find not sufficiently treated in communities.

When we talk about design in software development we talk about modularity, the fact of partitioning a problem into modules that interact to produce the expected result. Mostly this modules are partitioned through separation of concerns principles. Modules can be Objects, Functions, Namespaces, Modules or any other modeling tools that exit in the programing language of choice. Interaction of these components needs to be defined by combining and composing these components and designing their interactions in a certain way. Examples of interaction definitions tools are workflows ,orcherstration tools, and even Dependency Injection frameworks.

Interaction, composition and combining, all of that means coupling. And we know damn well that any coupling should be loose and well mastered. That is why actually we use interfaces, abstract classes, and a whole toolbox of patterns,  to control the coupling that we have to face in our software design and architecture. One very important point one should not forget, is that these patterns do NOT remove coupling. Dependency still exists after using these patterns and tools, the difference is that coupling becomes more loose, in a way that components wont depend statically on particular implementations, but rather on a contract that should be satisfied by an implementation that is bound later on (at runtime or preprocessor time). Notice my use of “static dependency” in this context. We can imagine these patterns and tools’ role is to turn the static coupling between components’ implementation into a dynamic one (late binding, strategies, overloading, polymorphism…).

Dynamic (runtime) coupling is inevitable,  at least when we want to do a modular code. I guess it is still ok to have runtime coupling until we fall into behavior coupling. Behavior coupling is one of the most annoying bug generators I cross everyday. Behavior coupling is a kind of runtime coupling. It is when two components are dependent on some state. And component B can’t succeed if component A doesn’t do its job on some shared state with B before. Taken into such a small context, behavior coupling might not seem that harmful, but the problem rises when several components are coupled behaviorally.

Behavior coupling problem might seem obvious, and easily evitable.  But not when, with a little observation, we notice that it is everywhere!

An example of an unsafe behavior coupling, is stateful event-based GUIs. In general, they have a special lifecycle. Complexity goes wild when several components need to manipulate the view. And ask these components all manipulate a shared state, they become all behaviorally coupled. I’ve seen a lot of projects where producing the expected behavior on the interface becomes a nightmare.

This kind of problem is not exclusive to GUIs. Actually all stateful components make candidates of a runtime coupling generator. The problem with behavior coupling becomes serious when it shows as ad-hock mutation of a shared state. Meaning that there is no well defined diagram or component that described the interaction of the several components with that state. It is indeed possible to have some kind of tools that can trace this interaction to draw a diagram that represents the behavioral dependency. However I think it is a good practice to explicitly define dynamic dependency, coupling and interaction in some formal way. This can be workflows (through xmls or other technology) that describe explicitly in a visual (or at least visualizable) manner , the runtime interaction. Yet a workflow is just a technology, and one needs a lot of discipline and modeling efforts to master the state of the view, and so the behavior dependency between several components.

A better solution to this problem is not to have state, no mutation. When there is no mutation and no shared state, then there is no behavior coupling. The question that is raised right away is how can one do real world applications without mutation and without state. Isn’t programming without state contradicts object oriented programming? Isn’t the world stateful? Databases, GUIs, how can we ever interact with that yet not having mutable state?

First of all, OOP is about having a state, but not absolutely a mutable state. Immutable object brings isolation to the logic of components which has its good side effects on modularity (removes behavior coupling) and performance (especially when talk about concurrence and multi-threading).

But what about GUI frameworks, and databases?

Databases, GUIs, File System these are just some kinds of IO sources that somehow indispensable for a useful enterprise application. By the end most of the value of an enterprise application comes from its interaction with the outside world. And the outside world does have a mutable state. But this doesn’t mean that enterprise software should have mutable state internally. One can push out the mutation and keep it in the outside world. This keeps the software safe and uncoupled behaviorally. That is merely what functional programming solution to IO is about. Keep your software clean from mutable state.

Keeping mutable state out turns your software into a function, a side effect free function; which given the same input produces the same return value (evaluates to the same value). The input when in the case of a database are data from the database ( and maybe inputs from the UI) and the output is a list of commands, different kinds of commands: Some UI command that when executed by the UI (outside world) will mutate the state of the interface. And other database commands (also outside world) that when executed by the database driver will mutate its state. However, in this case the software given the same input will produce the same list of commands. This keeps your software out of mutation and side effects. Which means out of behavioral dependency and coupling, and so safe with much less bugs.

This technique is based on Monads, something Haskell programmers are quite familiar and comfortable working with. In Haskell by the way, you do not have a choice but to isolate IO inside a monad (IO monad), that is one of the reasons why Haskell is viewed to be the only pure functional programming language.

I am not a functional programming geek. I have a very heavy imperative programming culture. And that is exactly why I write this post. I am a C# programmer. And I felt to share what Haskell taught me about good practices of programming.