On Sun, 2009-08-23 at 12:54 -0700, Peng Yu wrote:
> I understand that the sames things can be done with both language.
>
> But I do think that certain applications can be done faster (in term
> of the coding & debugging time, I don't care runtime here) with one
> language than with another.
Yes, and usually that application is written in that language *or* the
other.
> Therefore, for any give problem, it is
> meaningful to decide, based on the time to write and debug the code,
> which part should be programmed with perl and which part should be
> programed with python. However, when I split the code in perl and
> python, the problem of the integration is introduced, which incur
> additional coding and maintenance cost.
>
Couldn't agree more.
> I am sure that somebody must has already encounter the similar
> situation like I described above. I am wondering whether there are any
> advices on how to take advantages of both languages to speed up the
> code development time and reduce maintenance cost.
Perhaps you need to give more specific criteria. I've worked on a few
projects where different languages are used, but in different "domains".
For example, the client may be written in Python but the server written
in Java or PHP. Or different subsystems written in different languages.
For example, the workflow engine may be written in Python but the batch
processor written in C. However in these cases, for the most part, the
systems themselves are monolingual though they communicate with each
other using well-defined, common interfaces (e.g. TCP/IP, XMLRPC, HL7,
etc.).
If, however, you are thinking of writing a sub-system in multiple
languages (ala permodule, for example), you are in for a world of hurt.
Not only will the code be difficult to maintain yourself, it will be
difficult for others to maintain/understand it. Most people don't say
things like "Well I'm going to write all the 'object' stuff in Python
but all the string processing in Perl. What usually motivates people to
write systems in multiple languages are:
* Availability of third-party libraries in a certain language.
* Combining separate systems written in different languages.
* Developer's capabilities in one language or the other
* External dependencies (e.g. need to to have a plugin system for
people to program in Python).
* Performance.
* Other types of "glue" (e.g. installation scripts need to be
written in Perl, test system is Java based so CI scripts need to
be in Java).
permodule is nice for "simple" or "one-off" kind of stuff (or for any of
the above reasons). But any reasonably-sized application using
something like that throughout is going to be a maintenance nightmare.
--
http://mail.python.org/mailman/listinfo/python-list
