LinuxQuestions.org - Programming in multiple languages

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - Programming in multiple languages - How? (https://www.linuxquestions.org/questions/programming-9/programming-in-multiple-languages-how-819565/)

Programming in multiple languages - How?

Hi,

If one would want to write a program in multiple languages (say, using different languages for different sections of the problem that needs to be solved by the program), how should, or how could one achieve that?
I am aware of linking compiled code written in different languages, but what about interpreted ones?
What other methods are there, and what are the pitfalls of them? How elegant is simply writing two separate programs in different languages and making them interact (EDIT: at runtime I mean)?
And no, my own specific problem is not about combining assembly with another language.

I did some searches beforehand, inside LQ and in the interwebs, but I failed to find any satisfying answers.
Btw, an older, related topic: http://www.linuxquestions.org/questi...guages-748548/

And here's ArthurSittler's reply when I asked him on email a week or two ago (yes, I asked his permission to copy-paste it):

Quote:

Originally Posted by ArthurSittler

How to interface programs written in different languages might actually be a good question for the forum. The short answer is that I have not actually done it. I have seen someone else do it, but I was working on something else at the time and did not fully understand how he did it.

If you do want to emit assembly language and you are using gcc, that is a facility built into the compiler. gcc no longer means GNU C Compiler, it is now the GNU Compiler Collection (or something like that). It understands several languages, including Fortran, C, C++, assembly languages, and several others. The Linux source code uses quite a lot of assembly language. That might be a good place to look for interfacing between C and assembly language. You will find a way of doing that, but you should keep in mind that it is not the only way. The code for different architectures often use different conventions to take advantage of the particular facilities available on different CPUs.

The Unix philosophy is that everything is text files. One approach to translingual implementation is that the output of a program written in one language can be piped into the input of another program written in some other language. The second program would think that someone is feeding it input. Of course, the programs would all need to be written in a way that enables such interactions. That is why C takes input from stdin and writes output to stdout.

I am not an expert on Linux, but I know that Linux provides several methods for inter process communications. These include pipes, FIFOs, Unix V style IPC, POSIX message queues, and common data blocks. If the other languages support any of these techniques, that may be a possible connection mechanism.

The most direct sort of interface would be to have a program written in one language call a subroutine written in another language. This is commonly done with C and C++. The reason that it is not trivial is that the language specifications don't actually specify how parameters are passed to subroutines and how the called subroutines return results to the calling program. There are customary methods, but C does not specify whether the parameters are passed on the stack or passed in registers of the CPU. The usual implementation is to pass parameters on the stack. Then the next question is, if there are multiple parameters, how are they ordered? The customary method in C is to push the last parameter first, and the first parameter last. The customary order in Pascal is to push the first parameter first, and the last parameter last. Then there are questions about who pops the parameters. Does the caller restore the stack, or the called function? These questions never !
come up as long as you are using a single language. Assembly language is the exception here, as the assembly language programmer must explicitly adopt some sort of method or other.

I wish I were able to give you a better answer to your question.

Thanks for reading this.

Many languages (including many interpreted languages) include methods for coding functions in C to be called from those languages. Some also support call backs, so the C code can call functions in the interpreted language.

C++ allows you to declare functions matching any C interface, so any function that another language could call if it were written in C could be written in C++, and anything a C function can call a C++ function can call.

C can call Fortran functions and vice versa. I expect the same is true of most other compiled languages.

So if you wanted to combine one interpreted (or byte code or just in time compiled) language with C and several other compiled languages, that should be pretty easy. Where two languages don't have a defined way for one to call the other, you might need an interface layer in C.

Some of the languages (such as Java) that normally use an implementation that is structurally equivalent to interpreted, are also available in a true compiled form.

If you want to mix two different languages that are each structurally equivalent to interpreted, then you have a much tougher problem. The top level run time executable for each interpreted language is normally designed to be the foundation of the whole process. Fully compiled code in other languages can be brought in pretty easily as .so files. But another interpreter generally can't be brought in as a .so file.

Quote:

Originally Posted by steve296 (Post 4031710)

For python,embedding/extending with c (depending on which is inside which) is a process that is easy and well documented. I'd guess that 'competitor' languages such as Perl, Ruby etc have a similar arrangement.

If you chose a particularly eccentric combination, oooh, I don't know, Haskell and Forth (Cobol and APL would probably be entertaining, too) I think this would probably be untrodden ground and rather difficult

Quote:

What other methods are there, and what are the pitfalls of them?

Well, if push comes to shove, you can always make it into two separate problems. One can do something and write a file and then the other can come into action and process that file. Everything is a file, right?

Quote:

How elegant is simply writing two separate programs in different languages and making them interact?

Usually inelegant. You probably wouldn't be doing this if elegance was your overriding concern.

But cf, Tcl/TK and other attempts to graft graphical toolkits on to languages not originally intended for that application, which is probably the most usual example of putting two languages together (followed by something interpreted and C/C++, to code functions to run more quickly).

Quote:

And no, my own specific problem is not about combining assembly with another language.

Hmmm, you don't seem to be asking about a specific problem so much as starting a general discussion about an approach. So I think you'll only get somewhat general answers, rather than anything specific that you can directly use.

Quote:

Originally Posted by steve296 (Post 4031710)

Could you exactly and shortly describe what the problem is ?

I.e. you've been given a correct advice to use IPC in order to make programs interact. Interpreted language can use IPC as well.

You can also link programs written in different languages. like "C" and Fortran.

You can bind functions written in, say, "C" to, say, a program in Perl (look for Perl Inline::C module).

You can relatively easily combine pieces written in different language which ultimately work on the same virtual machine (if it's the case) - visit, for example, http://www.parrot.org/ .

Quote:

Originally Posted by salasi (Post 4031757)

Exactly. That sentence was there because* I didn't want to get answers about assembly (I'm very, very far from that level), because they wouldn't help me in mixing different languages together (of course I'm not trying to sound disrespectful about assembly, either). I'm concerned of elegance only because I don't know whether other people would mind if I solve this problem in a sloppy way; in case I would make the code open-source. Or, is that a "don't poke your nose into other people's coding habits" type of thing? (If that kind of unwritten rule actually exist)

Actually, what I'm after in this thread is receiving general answers to, basically, which are the common practices when one needs to combine two (or more) programming languages which don't have any already-existing interfacing solution?
What can go wrong if one uses the "everything is a text file" approach?

*(Actually, I do have a project in mind - only planning and daydreaming, mind you -, in which I'd use C and prolog (yes, I know about gprolog.h), I'm just curious how can one solve these kind of problems by not using interfacing. Actually, I may even write the whole program in prolog....)

Quote:

Originally Posted by steve296 (Post 4031860)

...
What can go wrong if one uses the "everything is a text file" approach?
...

Too much time it requires to parse data in it.