A multi-paradigm programming language is a programming language that supports more than one programming paradigm. As Leda designer Tim Budd holds it: The idea of a multiparadigm language is to provide a framework in which programmers can work in a variety of styles, freely intermixing constructs from different paradigms. The design goal of such languages is to allow programmers to use the best tool for a job, admitting that no one paradigm solves all problems in the easiest or most efficient way.

I was just reading this blog post by my friend Sandeep Procedural Programming is NOT a Bad Thing! and just thought I had to add some of my own blab …

I think rather than what features a language or paradigm provides, it is more important to ask oneself how many of these problem solving tricks/ techniques / methods one really knows and can call to aid. Understanding a certain paradigms enough to start fashioning solutions around it is non trivial. Knowing several paradigms should help open a world of different techniques of problem conquest. Any reasonably sized software would have you contemplate deep and hard on the problem space and probable techniques. Most likely, new techniques and paradigms will have to be acquired.

The tools we know of mould the way in which we approach problems. As a C programmer, say, what I can think of are data, locations of data, manipulation of this data in some conditional or iterative way. I would see clear steps and their impact on performance. As a schemer perhaps, I could see abstractions which might help me solve larger problems with less effort at the cost of seeing immediate impact on performance. For example quoting from SICP where the author is explaining about ‘concepts’ and ‘abstractions’ – “Similarly, as program designers, we would like our language to be powerful enough so that we can write a procedure that expresses the concept of summation itself rather than only procedures that compute particular sums.”

The key to program design and problem solutions is our ability to see these ‘abstractions’ and hence reduce problem space and complexity repeatedly till we have managed to ‘solve’ it sufficiently.

Certain vagueness or misdirections occurs when people give (or understand) only part of the reasons why they propound a particular paradigm strongly. For example, the Java people build a engineering platform which could scale to handle large complexity and resources and also help management of the whole thing. Large companies with extremely large code bases and with large programmer base have, as an element of the problem space, issues regarding code integrity, collaborative maximal exclusion coding. The issues and hence the design patterns which addresses these issues are specific to such systems. A Linus working on GIT is a different proposition. So Java is not necessarily a very elegant medium of expression of ideas but it is an excellent platform for the management of larger code bases and systems.

One has to choose a platform which will give him access to all the paradigms which his problem space may need to reach a good solution. So the key to a good platform for the creative types and people not encumbered with people problems, turns out to be the flexibility of the platform in providing the programmer a free space where a solution could be designed which merits the problem without being restrained or constrained by any particular paradigm or method of work. Ruby and Python are becoming more popular due to the flexibility and the expressiveness they provide, which I will call the elegance factor, which earlier was underrated.

Me, I program in Common Lisp. It is Nirvana for the programmer. The path to Niravana is always tough. But what you can do with such tools is what makes work pleasure.