Which dynamic language can easily use libraries from other languages?

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?

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.

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).

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.

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.

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.

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.

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.