Unfortunately, interfacing multiple languages is itself not a strategy for LFM-people, because most of them can (or believe they can) only fit one language into their brains. There are costs to using more than one language on a project. Managers frequently overestimate these costs, because they're the ones who will look bad if their superior (or investor) looks at their development process and say "Wow, this is chaos. No wonder you can't ship software."

There does seem to be a loophole: you can use multiple languages if they all start with the same buzzword. So, the same manager who balks at a Python/C++/SQL solution because it uses too many languages has no problem requiring that his developers learn Java, JavaScript, Java Server Faces, Java Persistence Query Language, Java Expression Language, and the Java Standard Tag Library, because they all start with "Java". Same goes with XML/XSLT/XSLFO/XPath and derivatives.

Based on this observation, I suggest a renaming of all common hacker tools. Python should be renamed "ParrotSnake", Ruby "ParrotGems", Lisp "ParrotParens", SQL "ParrotQueries", JavaScript "Parrot in a Browser", HTML "ParrotTags", Haskell "ParrotMonads", and so on. Then we could freely use any of these on a project, because they're all the same language, duh. Of course, the Parrot project itself should be canceled, because it'd defeat the purpose to have them actually running on a common VM. This is strictly a marketing initiative.

Insightful! But does this in your opinion apply only to LFM-people - my understanding is most LFSP-people don't see multiple languages as an option either?

I dunno - most LFSP-people I know use multiple languages regularly, learn new ones as a hobby, and their "preferred" LFSP is just the top of a long list of skills. That's why we call them "smart people". ;-) Take a look at Programming Reddit - most of the Haskell evangelists are also quite fluent in Python and C and usually know Lisp, Ocaml, etc. too.

There do seem to be exceptions - Common Lisp in particular seems to be a LFSP where many of its leading practitioners only know Lisp. Smalltalk, too, but to a lesser extent since all the commercial Smalltalk jobs morphed into Objective C or Java jobs. But I don't really see Lisp as being at the top of the blub hierarchy any more - there's been 20 years of progress since then and some really interesting developments.

"Common Lisp in particular seems to be a LFSP where many of its leading practitioners only know Lisp."

The hardcorest Lisp hacker I know wrote the chapter on C++ in the UNIX Haters Handbook. He also wrote a C to Lisp compiler for the Symbolics Lisp Machines. (And he works as a C++ programmer right now. :-))

UNIX Haters Handbook, published in the early 90s: http://research.microsoft.com/~daniel/uhh-download.html

I'm not so sure. Most of the Common Lisp people I've met know Java. I can't think of a single one who doesn't know C.

Or did you mean Common Lisp people tend to have only that language as their LFSP, no matter how many LFMs they know? In that case I would agree - I definitely see CLers ignoring Ocaml, smalltalk, etc. For my part I guess it's because CL took a long time to learn fully and I need to build up some energy before I invest that amount of time in another LFSP.

I'm a game developer. At work, we use C++, C# and our own scripting language. Our language is embedded, so the communication protocols between C++ <-> our language are straightforward, and C++ <-> C# happens through function callbacks.

At home, I use C++ plus Lua. I tried to use Lisp, but the CFFI had problems interfacing with certain foreign libraries.

To get around C++'s constraints, my solution is to move all of my game engine code to Lua with only a lightweight wrapper in C++. Lua is extremely powerful - for example, functions are first class objects, so it has closures. It's dynamically typed, so I'll spend less time convincing a compiler I should be able to run my code. It's very fast, because it has a JIT compiler which uses DynASM to generate assembly code, so it's about 1/10th the speed of C - huge for a scripting language. But most importantly, the communication protocols between Lua and C are extremely clearly defined, and work. Communication between Lisp and C is much more vague, and only sometimes works - Calling Lisp from C, for example, don't work on all platforms.

So I'd guess what influences me in my choice of multiple languages is how well two languages can communicate with one another. Can all constructs from Blub translate into Floob? How does Blub call into Floob, and vice-versa? Is it supported on all platforms? Is there a lot of example code?

You can certainly have a language mashup and solve problems in elegant ways, but it all hinges on how elegant the communication is.

If you use several different languages, and if they don't share resources (Window handles and such), and if communication between them is not speed-critical, then you can write a networking layer which each language uses to communicate with every other language. But that option seems pretty rare.

Shawn

I work in a Java shop but do some statistical work using R. For me, Java is the easiest way to gather together data for an analysis. R is the clear winner over Java for doing statistical modeling. Gluing them together is possible, and some people have written bindings. However, these are not well documented, and they are not mature enough to use in a production environment. The difference when mixing together use of (J/X)* languages is that they have mature bindings (often simply because they are all written in Java).

I'm all for using the right tool for the job, but it's really hard to take on the risk of an integration one might have to maintain or expand upon. Using two languages isn't itself a problem, either for developers or managers.