There are a lot of popular programming languages out there, each popular for being good at a particular thing. The C family languages are fastest and have a giant legacy. Perl is a favoured choice for text manipulations. Today's darling is Ruby, leader of the agile movement. Python is a cleaner, high-level language. PHP aims at the quick web/HTML scripter language and has a simpler access to SQL databases than most. Java's a common choice for large projects, with lots of class libraries, slower than C but faster than interpreted languages.

However, my goal here is not to debate the merits of these languages, which are only barely summed up above (and no doubt incorrectly to some perceptions.) My goal is to point out that we all love our different languages for different purposes. And more to the point, one of the reasons we love a particular language is that we *know it*. In many cases we might decide we could more quickly solve a problem in a language we know well, even though another language might be better suited overall.

Sometimes I'm sitting coding in one of the more concrete languages, like C or Java, and I think to myself, "This problem would be 2 lines in Perl." It would probably be slower, and perl would not be a suitable choice for the whole project, so I spend the time to solve the problem in the language I'm coding.

Many of the languages have mechanisms to deal with foreign or "native" methods, ie. to deal with objects or functions from another language. Most of these systems are clunky. You would not use them for 3 lines of code, nor would it be particularly readable.

So I propose being able to "switch languages" in the middle of a piece of code. You're programming in C, and suddenly you break out into perl, to so something you immediately know how to do in perl. You get access to the core data types of the original language, and as much of the complex ones as can be made simple. If you need to get real in-depth access to the complex data types of the other language, go back to its foreign methods interface and write a remote function.

Read on...


char *foo = get_response();
#language perl
$c{foo} =~ s/complex regexp I know how to do in perl//g;
#endlanguage

It doesn't matter that it's possible to do the substitution in C. It's possible to do anything in C.
What matters is how quickly you know how to get done what you want done.

Such an example, a switch to perl, would of course be extremely inefficient by C standards (especially the first time, when the whole perl system would have to load.) You would only use this sort of function when that doesn't matter, or so I hope.

And, as you will probably notice, there are some hoary problems on just how to glue the data together involving memory freeing/object destruction (at least in C/C++) or garbage collection. Some glue will be hard, so you don't do it unless you really need it. Some will be easy. It may be necessary to import and export data through implicit or explicit creation of variables used only for that purpose, so the glue can worry about what happens to that data. Copying everything is ineffecient but again, this is not for code that requires such efficiency. But programmer time can be more important, and if the programmer could code up an SQL modification much faster and more reliably in PHP, it might make sense to do that.

Though sometimes it might be. There are times when coding in a higher level language that uses strings and rarely does character at a time loops over them, that you want to switch to C++ or some other language where that's the norm, both for speed and because of the way you think in that language.

There is another way to attain part of this goal, which is to build class libraries for one
language that "think" with the paradigms of another. And people have done this, creating perl
regexp libraries for C or PHP.

I'm sure some people will respond with "Just learn Python" or "Use Groovy" or "Use Jython" and for some programmers that is the right course. There are people who claim that one language is the true best language for everything but I doubt they are ever truly right. But there are lots who may be able to solve problems more quickly if they can just shift in and out of the thinking styles that make each language great for the the problems it does well on.