To be good at perl you need to be good at programming, which takes about ten years :) You don't need to know C++ :) but if you did "know" C++, you'd already have ten years under your belt, and picking up perl wouldn't be too hard then

Teach Yourself Programming in Ten Years, What is the best way to master perl, Whats the average time taken to learn Perl?,

Common Perl Pitfalls / perltrap

Tutorials: Basic debugging checklist , brian's Guide to Solving Any Perl Problem

perlintro, http://learn.perl.org/books/beginning-perl/, http://perl-tutorial.org/, Tutorials: Basic debugging checklist , brian's Guide to Solving Any Perl Problem, Modern Perl book, a loose description of how experienced and effective Perl 5 programmers work....You can learn this too.

The Perl Monks Guide to the Monastery, Re^8: How to use wxHtmlEasyPrinting (On debugging, verify everything, talk to teddybear ... and links and links

Thank you for the reply. I clicked the link Teach yourself programming in Ten Years. It had this as one of the things you needed to do: Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal). Can you please comment? Ostra

Learning any of those languages and techniques can change the way you think about programming and solving problems. Learning new things that challenge you is often worthwhile.

You don't have to know any of those things to write good Perl that solves real problems for real people. It will help, but practical experience in programming—not just writing the same toy programs over and over again—in any form is the best way to become a better programmer.

Can you please comment?

Sure, spend the next week read all the links and links and links of links I linked :)

He is talking about programming paradigms, a particular way to design and write programs , a particular way to speak/think about and solve problems

Its like eating a cow (or eating a horse), the goal is food in your employers belly, but how you go about it depends on how you think (what is humane? which cuts are kosher? ... ), what kind of hardware you have ( stone , steel, electric,... ), taste preference (steak? hamburger? sausage? bbq? ... ) ... some programming languages come with a really sharp and shiny meat slicer, while others only allow chainsaws

Its like fighting, or mixed martial arts, there is long range, short range, standup, takedown, ground, clinch, grappling, ... your might be a ground submission expert, but your opponent won't let you go to ground, keeps you standing ... you can win a lot of fights with just a ground game , but its best to have a plan/skills/vocabulary/technique for fighting at all ranges/stages -- even if your current opponent limits your choices

In all three cases, practice by solving real problems yields best results, allows you to adapt to any challenge .... but it's not like I consider myself there :)

• The Architecture of Open Source Applications
• How to Design Programs

  Programming is far more than the mechanics of language acquisition. It is about reading problem statements, extracting the important concepts. It is about figuring out what is really wanted. It is about exploring examples to strengthen your intuitive understanding of the problem. It is about organizing knowledge and it is about knowing what you don’t know yet. It is about filling those last few gaps. It is about making sure that you know how and why your code works, and that you and your readers will do so in the future. In short, it is really about solving problems systematically.

• Structure and Interpretation of Computer Programs
• Teaching Kids To Code - YouTube
• So You Want To Be A Programming Rock Star? - YouTube
• How to Write Clean, Testable Code - YouTube
• Larry Wall Speaks at Google - YouTube
• Tangible Functional Programming - YouTube
• JavaScript: The Good Parts - YouTube
• Design Tech Talk Series Presents: OO Design for Testability - YouTube
• "The Clean Code Talks -- Inheritance, Polymorphism, & Testing" - YouTube
• The Little JavaScripter
• The Little Schemer
• Object Oriented Programming in JavaScript
• Designing Objects and Systems - Live Design Session - YouTube

You certainly don't need to know C++ to be good at Perl.

Having a true object-oriented language in your background might help, but C++ is nowhere near object-oriented enough to make any significant difference in that regard (especially if you learned C first and then moved to C++, which will lead you to write mostly procedural C++ code); and a functional language (e.g., Lisp) would help a lot more, IMO; and in any case if your goal is to be good at Perl no other language will help you more than Perl itself.

Anything more than a cursory knowledge of C is actively detrimental (at first), because it leads to bad habits. This can be overcome, simply by working with Perl more, but there's no advantage to it (from a Perl perspective) until you reach the point (years down the road) where you're ready to start digging into the perl internals.

If your goal is to learn Perl, then you should study Perl. Write code in Perl that does useful things. Hang out on Perlmonks and read more than you post. Go back over your old code that you wrote in Perl a few months ago and notice which kinds of things that you did make it easy to understand and modify and which kinds of things make it difficult. Study Perl, use Perl, learn Perl.

You certainly don't need to know C++ to be good at Perl.

Having a true object-oriented language in your background might help, but C++ is nowhere near object-oriented enough to make any significant difference in that regard (especially if you learned C first and then moved to C++, which will lead you to write mostly procedural C++ code); and a functional language (e.g., Lisp) would help a lot more, IMO; and in any case if your goal is to be good at Perl no other language will help you more than Perl itself.

I could not agree more.

PS: No, you don't need any knowledge in C++ to learn Perl!

update

added smiley.

I don't think so.

Once you are a good programmer in any language you may be able to get productive in a different one of the same family (for instance, in Perl case, imperative object oriented languages) in a very short time.

Becoming a very good programmer in the other language is a completely different matter. It may take a long time because you will have to learn the idioms, quirks, libraries, culture, etc. For instance, becoming a very good C++ programmer even if you know Perl well would probably be a years task.

If the language is of a different kind, as for instance Haskell, then you know mostly nothing.

I wasn't too serious. Sorry for forgetting the emoticon!

edit

But my point is the definition of "very good Perl programmer", opinions may vary... =)

Some people don't know how to use any OO or FP techniques, but think knowing all features of pack by heart qualifies them to be a very good Perl programmer.

Cheers Rolf

( addicted to the Perl Programming Language)

update

typo: s/map/pack/

My objective is to know PERL very well.

Son: How do I get to Carnegie Hall?
Father: Practice. Lots of practice.

The point of that old saw is that to be good at anything requires practice. It doesn't matter if it is Tae Kwon Do, baseball, riding a bike, carpentry, brewing beer or writing code. You start off at a particular skill and get better with practice. How much progress over a delta of time depends on your inborn aptitude for that skill. I'll never be a Major League baseball player because I don't have the aptitude (nor interest) in achieving that level of skill.

One of my passionate pursuits in in the realm of culinary arts. I am a crappy baker (aptitude and interest strike again) but can cook seven course dinners that cause people that have experienced them to question why I never opened a restaurant. Yet I remember 40 years ago some of the stuff I cooked being barely edible.

So.. keep coding... keep practicing. It also might hep to track down someone to mentor you and critique your code.

Knowing perl well and writting good perl programs are not at all the same thing. A person can know a small subset of perl, but use it well. Another person may clutter his program with poor use of obscure features. Try to be one of the first. Then learn new features and modules. Use them as needed to make your programs clearer, smaller, faster, or more robust. This process should never end.