views:

217

answers:

7

Tell why you think Python, Perl, Ruby, etc is easiest for plugging in modules from other languages with minimal thought.

To clarify, an example: I want to write business logic in Python, but use functionality that conveniently exists as a Perl module.

In other words, which language "just works" with the most modules?

A: 

all 3 languages have very good, clear facilities for just calling any executable in a subprocess (including executables like python somethingelse.py or ruby somethingelse.rb).

use what you know best.

teepark
+6  A: 

The Parrot VM looks like the way to go for this purpose, since

Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator

It matters less, I think, which of these languages you use as the "main driver" and which one just as "guests" for this module or that -- just check that you pick one whose Parrot implementation is complete and mature (since Parrot's a rather new project, and so are some of these language implementations on top of it).

Alex Martelli
+1. I saw that a while ago and it seems to have matured a bit. Rather than passing commands out to the shell/interpreter using say `popen` do you know if you can access functions from other scripts cross script, if that makes sense? That's a different way of thinking to just running another script which is why I mention it.
Ninefingers
@Ninefingers, yes, in theory -- functions are supposed to be able to call each others in Parrot no matter what language they're coded in (much like it works in other cross-platform virtual machines such as JVM or .NET) -- but I have no practical experience with Parrot yet.
Alex Martelli
Recommending Parrot without having used it seems fishy to me. The current version of Python for Parrot, Pynie, is heavily incomplete (to give an idea, dict() was implemented a week ago). Cardinal, the Ruby implementation, is also under heavy development. At the moment the most developed language on Parrot, in terms of features and usability, is Rakudo Perl 6.
rjh
@Alex Aaah Ok that's quite interesting. Maybe as it matures further it'll become a viable platform for this sort of thing.
Ninefingers
+3  A: 

If you want to plug in a Perl module, the language which is best suited for this is Perl. Perl is able to represent the semantics and capabilities of code written in Perl correctly. This really shouldn't be a shock.

If you have a self-contained program you want to call from another program in its own process, not constantly interacting, any of these languages can do that with programs written in whatever language. At that point, you aren't really using other languages inside a program but just calling other problems.

There are several projects to combine various pairs and projects (like Parrot) that seek to provide a platform for a large range of languages for compatibility and projects (like .NET) that almost accidentally provide compatibility among previously-incompatible languages. However, I do not think most of these are as robust, mature, and suited for combining normal code as you would hope.

Mike Graham
For .NET, IronPython is production ready and has been shipped with at lease one Microsoft Dynamics product. IronRuby is current in release canidate status.
Jonathan Allen
A: 

I'm going to answer on a more architectural level here. The question is what are you trying to do... do you want to write your business logic in Python and call a Perl function from Python? Or are you looking to execute a script? If so, how will the two communicate?

I suspect, but don't know, that Parrot VM might allow you to do that, but as Mike points out, there are difficulties. Cross-language work is hard just like IPC across programs is hard unless you use some form of loose coupling (not so tied to the language). To that end, you might consider setting up the controller in one language and having everyone else talk via a dbus queue, or whatever mechanism you prefer for whichever platform you're on. It doesn't really matter how you do it (cue a debate on the best mechanism) but properly designed it makes talking across languages and building plug-ins very easy. For example, you might have a queue for process_new_user, for example. Any script who registers in that queue gets access to the data so a new developer can easily add functionality for their part of the program. Interpret that as: you can easily use a different scripting language to implement that bit.

Ninefingers
A: 

The Dynamic Language Runtime was specifically designed to allow one dynamic language to use objects and functions defined in another dynamic language. Currently Python and Ruby have DLR implementations, but I haven't heard anything about Perl.

To use the DLR you need either .NET or Mono.

Jonathan Allen
There is Perl.NET
Alexandr Ciornii
Is that being maintained? I don't see anything on it since 2002.
Jonathan Allen
+9  A: 

Perl has very good support for other languages via the Inline set of modules.

Inline::Python allows you to import Python modules, classes and functions into your Perl code and call them from Perl as if they were native - see Importing Functions.

Inline::Ruby works virtually the same way.

rjh
+1, I like this. I wonder if Python has similar functionality... time to go and look!
Ninefingers
A: 

Most scripting languages can handle this kind of thing (by running external programs written in other languages,) but it seems as if your best bet might be shell scripting of some kind (Windows users call this "batch scripting," but the DOS syntax is horrible and not recommended.) UNIX programmers have been freely mixing languages in this way for a long time. On Windows, you can install Cygwin to get a fully functional BASH shell.

The shell was originally intended as a user interface, used to launch other programs or combine them in interesting ways. However, many shells (notably the Bourne shell or its modern descendant, BASH) are also fully-fledged programming languages. Each of your "modules" can be created as separate, standalone programs which will be run by the shell script.

Max E.