|Syntactic Confectionery Delight|
I tried that four different times. (Well, technically it was C++ two of those times.) It... didn't take. These languages are so feature-impoverished, you absolutely cannot believe it. You do not want to program in C or C++. It's not fun.
For one thing, they don't have anything that *resembles* a high-level data type. Seriously, just the plain old string data type, which *every* high-level language has, is a half-baked not-really-first-class type in C, and if you ever forget it you end up with bugs, which are hard to track down and fix, most of which can cause crashes, and some of which have security implications. Arrays have to be dimensioned when created and cannot grow to accommodate new entries. Forget about lists or hashes, much less real objects. This would be forgivable in assembly language, which is intended to be closely tied to one hardware platform and so only has the data types that hardware supports natively. That makes sense. But this reasoning does not apply to C and C++, so I'm not sure what possible excuse could be offered on their behalf. Even Fortran (in recent incarnations) has better data types than C. I mean, at least it's got native bignums.
You can't do *squat* in C or C++ without including a library, not even extremely basic things like print text to standard output. Granted, there are standard libraries for these things (kind of like core modules in Perl in principle, although their functionality is less advanced than the builtins in Perl). However, the standard library functions were named by letting Dennis Ritchie's pet hamster play on his keyboard, running the results through an anagram generator, and then using grep and a spellcheck dictionary to exclude anything that looked like a word. (All the really bizarroid function names in Perl, like sprintf, come from C, and in C these are some of the tamest and most sensible names. Examples that Perl had the good sense not to copy include strtoul, mbrtowc, strcspn, and iswcntrl, and I am not making any of those up.)
There's no CPAN equivalent for C or C++.
Also, the available documentation is inferior. This is true both in terms of the documentation that comes with, as well as available online documentation and books. The most popular C book is probably still the K&R2. I have it, and have attempted to read it. I've also tried to read Bjajrjne Straustrupp's book on C++. When somebody writes about Perl and does that poor of a job, we lambast their work without mercy and tell people not to waste money on it, but that's because there are *good* books available for learning Perl.
Pain, pain, and more pain. All the advanced high-level features of assembly language combined with all the simplicity of Intercal.
Do yourself a favor: pick a language to learn that sometimes gets positive reactions from people who have previously used Perl. Ruby, for instance.