From Perl to C and Back Again
No doubt, Perl is a good programming language. However, there are situations in which you might want to use another language, be it because native C code offers better performance or you want to use an external library not written in Perl. The canonical way to use the XS interface. If you choose to take this road, you will hardly do anything else during the next few weeks as the learning curve is extremely steep. The Inline module aims to come to the rescue here as it helps you getting started within minutes. Among the supported programming languages are C, C++, Java, Python, and many others, with the C interface being the most mature.
All you need to do is to use the Inline module, tell it the external programming language and specify which parts of your script or module contain foreign code. In these parts you can define functions as you like and call them from your Perl code as you would call an ordinary Perl subroutine.
The devil, however, is in the details. Perl has a mixture of strong and weak typing, as scalars are dynamically converted between integers, floats and strings, while arrays and hashes are separate types. Of course, the foreign programming language will have a different type model, so it will not know what $foo means. For the C interface this is solved by using the same data structures Perl uses internally, and you can use the Perl's internal functions to manipulate objects.
In theory, this also works the other way round, i.e., calling Perl subs from your foreign code. Unfortunately, the C interface does not like callbacks, resulting in a crash of your program. The workaround is to use Perl's callback convention directly, which should work fine.
Especially for the C interface there is extensive documentation available, containing many useful examples. For other languages the situation is rather mixed, often depending on how mature the support for the language is.
What the Inline module lacks is scalability. While it works fine for a small program or module, it is not a working solution for all situations. One problem is that you need to supply a directory where the compiled stuff is stored. There is no standard way to do this, so if everyone used Inline this would eventually clog up various pieces on your disk. There are a few more minor annoyances, like the line numbers shown in compiler errors do not match the lines in your Perl file.
In general, the Inline module is an excellent choice when you need to produce results quickly. However, for larger projects you will not get around digging into the XS system.