Re: I want to know the problems in Perl

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:

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.
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.
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.
“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?

Replies are listed 'Best First'.
Re^2: I want to know the problems in Perl by chromatic (Archbishop) on Mar 30, 2011 at 21:57 UTC
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.	[reply]
Re^3: I want to know the problems in Perl by locked_user sundialsvc4 (Abbot) on Mar 30, 2011 at 22:18 UTC
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.”
Re^2: I want to know the problems in Perl by Jenda (Abbot) on Mar 31, 2011 at 08:21 UTC
Do a comprehensive, all-inclusive system design document first. Implement part of it. Show the result to the users/client. Find out what they said they need/want is not what they need/want. Scratch the comprehensive, all-inclusive system design document. Do a second comprehensive, all-inclusive system design document. Implement part of it. ... 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.	[reply]
Re^3: I want to know the problems in Perl by Your Mother (Archbishop) on Mar 31, 2011 at 13:25 UTC
But a comprehensive design document is the way to do code right.	[reply]