You are here

Hybrid Languages


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;

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.


If your "concrete" language is Java then embedding groovy will do what you want, with a little more verbosity, see

Or use boo if you're using C#, see

If you're using C you can embed Lua or the like, even more verbosely.

If you're using Perl then Inline::C can be used to embed C in nearly the manner described, but that's the reverse of what you want, perhaps.

Reports suggest Groovy is an up and coming language, though perhaps not as mature as Ruby/Rails or of course Perl, PHP and Python -- is this incorrect?. It will be one to watch.

However, the first goal was to let people use a language they already had lots of experience thinking in. I can code in any language you name pretty quickly, but languages are no longer defined by the language spec, but rather by their large libraries of classes and functions. A C coder can learn Java in 30 minutes, but takes much longer to have all the class libraries and patterns at their fingertips. Once you've been thinking in a language a long time, you can often solve certain problems right off the tip of your fingers, which is what this proposal's about.

Pro*C is (or was, several years ago) Oracle's solution for combining C and SQL. It was implemented as a C preprocessor.

There are a set of Inline:: modules for perl which allow escaping to other languages, including C, C++, Java, Ruby, Python, Guile (Scheme), and TCL. I believe these are all exposed at the subroutine level only, so the equivalent of your example would have been something like:

char *foo = get_response();
perl_s(foo, 'complex regexp I know how to do in perl', '');

PERL('sub perl_s {$_[0] =~ s/$_[1]/$_[2]/g;}');

except inside out, and with native quoting rules which make multi-line strings much less painful.

Forcing a function call makes the type and namespace issues much more tractable, I think.

SWIG is a semi-automated toolkit for making native-compiled libraries (ie, generally C or C++, but other languages with real compilers would work too) usable from perl, python and tcl.

If you're trying to do multi-paradigm programming (which is more or less what you're looking for here in the end), Lisp makes it very easy to switch between functional, imperitive, logic programming, object oriented and other styles within the same function. Modern compilers are pretty damn fast, too.

Yes, I know this is not what you were looking for. You want to switch between your favorite languages. I'm just pointing out the reason many people love Lisp is precisely because it allows the sort of "switching" you are looking for without actually changing language.

I agree, I had a very similar idea a few years ago:

.NET's common runtime and its new "partial classes" feature are certainly an improvement, but context-switching between languages on the fly is still a dream for now.

Add new comment

Subscribe to Comments for "Hybrid Languages"