I would decide upon the language first and foremost based on the fact whether I know it already. To use a language that you don't know already will only lead to major problems later on, because you can't ask the important questions about a language before you know it.

The decision on the language cannot be as urgent as you make it out, because if you know neither language, you will need to learn either of them anyway, before the project can start. To start the project without knowing either language is foolish.

Basically I have come from a C-language background. I have to start the project for which we need to make a decision either to use Perl or Python. So we have to find the best between them. So we get answers in these high level cases. Please understand I dont have enough time to learn and get the solutions. thanks in advance

The relative similarities between perl and C in terms of syntax are likely to make a significant difference if this is going to be your first serious project in something other than C. (Be sure to look at the perl man page called perltrap, which contains a section with lots of details about differences between perl and C.)

If you have experience with Bourne shell and unix utilities, again perl will give you an easier, shorter learning curve, because it provides a lot of idioms and facilities from that domain that are common and familiar (and very useful).

For the kinds of tasks you have described, both languages would be equally good. Since your background is in C, you may find Perl's syntax more familiar than Pythons's (e.g. Perl has a very cool switch statement while Python doesn't even have one).

Pick Python. From the sound of the planning phase I'm guessing the project will be a train wreck. I'd rather see Python blamed since no one takes responsibility for their bad development practices when it's so easy to blame the tools.

And I thought *my* post needed a sarcasm disclaimer :)

fnord

I agree, 100%

And lets see if Python as is usually assumed magically transform all bad programmers to geniuses and converts their bad practices to best practices.

Python needs more of these sort of projects and people. Hype and fame sure attracts a lot of people, who often just learn languages(most of the times badly) for just job reasons and ultimately pollute and destroy the whole language ecosystem. Python is currently heading to that stage. Java is already infected badly.

I agree! Do it in Python!

1. Although both Perl and Python have a full range of interprocess communication and multiprocessing routines, Python's approach to threading is to provide a class with methods for managing processes in a way that I question is multi-threading. Reading the Python documentation makes my stomach churn because I feel that as comprehensive as the class looks, the authors don't really know the difference between a thread and a parallel subprocess. Perl documentation and practice make a more understandable distinction between forks and threads that tallies with what was understood by these concepts long before Perl or Python came into existence. In particular, although threads and classes seem at first sight to be incompatible techniques with Python not convincing me that this conceptual clash is even properly understood in Python land -- but Perl gets around this by allowing the programmer to define the code inside the thread in a procedural way while keeping the thread classware well under the hood and out of the way of the programmers multithreaded coding style.

2. For asynchronous (ie non-thread-style) parallel processes, Python has slightly more flexibility in the management of pipes, but broadly the languages are similar in this capacity. Python does provide thread capability but the interface is much harder to use and maintain than Perl's. BUT when using library modules, they have to be thread-safe in Perl, whereas although much more difficult to use, at least Python has no such limitation.

3. Both have message queue capabilities - But Perl's IPC::Msg module provides access to unix message queues more readily (IMO) than Python.

4. Both Perl and Python have about similar access to sendmail, but Perl's library has additional capabilities, most notably in the CGI module for example for accessing sendmail from within a webserver script.

1. It depends
2. It depends
3. It depends
4. You 'best the sendmail' by using something better than sendmail. If you mean 'best interface with sendmail', then, you guessed it, it depends

Both languages attempt to be as platform-independent as possible. Neither of these languages implement the actual operation of the features you ask about (except for the sendmail part, where it is an API issue). They provide a platform-independent API for performing the functionality you ask about, built on top of the various OSes. As such, 'better' is almost totally subjective, as it depends on how easily you understand one over the other. If you would like to see published results of the specific operations you ask about in terms of memory and CPU use, it can be summed up by the following linux command: 'cat /dev/null | more'

Corion gives the best answer (and, by the way, the answer that is almost always given when this question is asked here, which is often). However, having used both (but more Perl by far), I will offer the following additional insight, as from the phrasing of your question, I gather that you currently know neither all that well. I consider Perl to generally be the 'densest' language I have ever used. By 'densest', I mean that you can do the most in the fewest lines of code. It's highly symbol-intensive syntax is largely the reason for this. Python, in contrast, uses a more natural-language syntax. My experience has been that when people have to deal with non-trivial programs in either language, having little to no knowledge of them, that Python code is usually easier for them to figure out. However, this is hardly a good reason to choose one over the other. Beyond this, both have packages or built-in APIs that cover just about every generally-used feature or function available on the platforms where they run

Now, in the final analysis (keeping in mind you did not ask this question on PythonCharmers.org) The learning curve for Perl will most likely be a bit steeper than for Python, but is more than worth it. There are just so many non-trivial data manipulation tasks that can be done in just a couple of lines of Perl code that are used all the time, and have no parallel in any other language. That alone makes it worth using. And learning is also not that difficult. I found the Perl Cookbook to be a great learning tool to understand many of the aforementioned data manipulation techniques. Then, using Super Search here, you can find answers to just about anything you might want to know/do regarding things beyond the scope of the Cookbook.

Oh, and sorry for the sarcasm -- it comes with the territory...

fnord

Since you "... dont have enough time to learn and get the solutions" (sic), /me can help "very badly."

There are *NO* problems in perl (Well, maybe a few tiny little ones but nothing to worry about.) On the other hand, if you play with pythons, you make get snake-bit.

More seriously, it pretty much depends on what your project demands and if there's not a clear choice based on that, then develop in the one with which you're more comfortable.

I have done recent professional work in both languages, and I have tremendous respect for the implementors of each.   The tasks which you describe are fundamentally implemented by the operating-system; not by the language.   Customer satisfaction will be determined mostly by how they are used in your design.

I recommend:

1. Do a comprehensive, all-inclusive system design document first.   Describe exactly what the system will do, what load it will be required to handle, and how you will test it.
2. Do a thorough and deliberate search of the “prior art” in both languages.   For Perl, this means http://search.cpan.org.   Do not embark upon a “new” design before doing this, because in fact this system requirement is not “new” at all.
3. Build a detailed specification of how you would do the work in both systems, making the best possible use of “prior art” in both cases.   I also suggest that you do a search for commercial software that you can buy to do the work, thus avoiding purely-redundant effort completely.
4. “But that’s such a silly waste of time!   Why should I do all of that, when I could just start writing code, and thus be really productive?”   Heh.   When people build a building, how many times on average do they tear the whole thing down again until they finally get it right?

When people build a building, how many times on average do they tear the whole thing down again until they finally get it right?

When people build a building, they don't have the option of copying and pasting or refactoring or importing libraries from elsewhere.

Oh, buildings are constantly being built from sometimes extremely large blocks of prefabricated components.   But my point was not really along those lines at all.   It was just ... “plan the ending, and everything else from the start to the end, before you start.”   There is an excellent chance that the OP is jumping to a conclusion that, to solve this problem, it is necessary to “build” a rather complicated program.   It may well prove to be the case that nothing needs to be “built” at all.   That “buy vs. build” and/or “build vs. borrow” decision should be confronted as soon as possible ... recognizing also that the answer could be “partial,” in which both the scope and the nature of “what must be built” will change drastically from its present notion, and the choice-of-language will be driven by that finding.   That’s all.

“Laziness is a virtue...”   “Actum ne agas.”

1. Do a comprehensive, all-inclusive system design document first.
2. Implement part of it.
3. Show the result to the users/client.
4. Find out what they said they need/want is not what they need/want.
5. Scratch the comprehensive, all-inclusive system design document.
6. Do a second comprehensive, all-inclusive system design document.
7. Implement part of it.
8. ...

One of the fundamental rules of software development is that the clients never ever know what they want and the more detailed your plan is, the more you'll have to change it.

Jenda
Enoch was right!
Enjoy the last years of Rome.

But a comprehensive design document is the way to do code right.

Obviously my fellow monks seem to live in "ivory towers" if they can't imagine projects that either have time for learning a language included or were given by people who simply set an end date and expect to get something finished at that time, no matter how it is done.

But I can't give you any better advice. Probably this decision is the most unimportant you have to do for this project

What operating system will you be using?

How familiar are you with Object Orientation?

(I expect this question to be the answer ...)

but I want to share a bit about threading.

I do not know threading in Python, but I know that threading in Perl is bad - it is memory hungry and not stable.

I very much suspect that Python's threading is also bad.

Other than that, perl serves me much better compared to any other language - it rocks really much :)

Bad threading behaviour in perl isn't much of a problem these days. Listening to my managers/salespersons/cleaning staff, these days you do most stuff "in the cloud" (e.g. as webservice) anyway. And on webservers you don't thread, you fork 8-)

More seriously: I my opinion, the best way to choose is to learn the *basics* of both and try to code small routines you would need in your project. The language that causes the least hairloss (or grey strains, whatever rocks your genes) will be the language of choice.

And if you believe that, I have a bridge for you to sell

If I were you I would first try to understand all human beings are the same regardless of what programming language they use.