MPP: Multi-Paradigm-Programming

The September-November issue of the Software magazine is a special issue with a lot of articles about MPP. There a number of nice articles with Dean Wampler (DRW Holdings) and Tony Clark (Middlesex University) present the MPP and what’s happening in the industry, an interesting Discussing with Neal Ford and Brian Goetz, and a number of other good articles about MPP.

“A collection of coherent, often ideologically or theoretically based abstractions constitutes a programming paradigm”

- Dean Wampler,Tony Clark

So what’s it all about?

Object oriented programming, functional programming, concurrent, imperative… there are a wide number of different paradigms, and when more than one paradigm is used in the development it is called MPP. The situations where only one programming language is used are becoming more and more uncommon; because the nature of current software development projects hardly ever allow using only one software development language.

Is it even possible to ignore MPP and try to develop using only one paradigm? Largely it is dependent on the nature of the system, however for the most common systems, here’s what Neal Ford (Thoughtworks) writes:

“Most teams are by necessity MPP teams now. No one writes in a single language anymore. Even trivial applica­tions have a general-purpose language, SQL, Ja­vaScript, CSS, and dozens of frameworks, each of which includes an external DSL (usually in XML) that is its own mini language (the syntax is XML, but the XMLSchema defines the se­mantics). For a long time, teams that refused to use SQL (preferring instead some sort of flat file “database” tuned to a particular 4GL language) or that refused to use Ajax would be considered behind the mainstream. Increasingly, teams that ignore MPP will find themselves falling behind their competitors.”

So what it tells us is even if you develop your application using one programming language but you also use a common database, you still end up with MPP, since you still have to communicate with the database, and it will most probably be in SQL, or a similar querying language.

In the situations when more than one programming languages are used Neal Ford has suggested to use the term “polyglot”. This is very common now days. How many of you can now say that their system is not polyglot? Even if complete systems are developed using one language (like Java) there’s now this tendency to write the Unit tests using a more powerful language (like Groovy or JRuby), which give a lot of insight into the functionality being tested, and allows the junior developers not to concentrate on the line of codes but the functionalities. There are also tools like JTestR that add the extra elegancy to the Unit tests using the Ruby ideology. So what’s this all called? Polyglot.

Why would one use MPP anyways?

The OOP has its shortcomings just recall the synchronized access to shared, mutable state. Instead the properties of Functional Programming, such as immutable values and side-effect-free functions, are the foundation of robust concurrency models. There are a number of proofs that the FP does even improve the code quality compared to OO Languages.

The factors above have been the driving force behind the metamorphosis in the software development world and the creation of languages like Groovy, Ruby, Scala, etc.

What do they provide us? They provide us the Encapsulation mechanisms and intuitive ways to model complex domains in software of OO, coupled with very powerful attributes of FP. In the end they result in making the lives of programmers’ easier, the code production faster and code sizes much shorter.

What does Agile have to offer?

Well, Agile has nothing to do about the programming languages, however in my opinion it can affect the use of certain paradigms in developing of your software. Imagine if you had to develop an application in the waterfall model, you have to decide on the technologies/language(s) you are going to use and start developing aiming to finish your work until the deadline. Doesn’t sound really language friendly does it? You have to think everything from the beginning, having in mind that you cannot change something in the last stages.

In contrast, in an Agile environment, working in a certain tempo (tact) you get feedbacks very quick. If your SCRUM-sprint length is 2 weeks, that’s the time you have to wait to get some feedback about the technologies used. Based on that feedback you either elaborate the languages you have selected, or, since it has been only 2 weeks, and if you have specific results that you can base on decisions to change a certain technology, then the maximum at risk is that from the 2 weeks. This brings us to a core principle of Lean: “Decide as late as possible” and make the decision in the last responsible moment allowing the development teams, the architects to think naturally and not act trying to make the deadlines of the waterfall.