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