That rather depends on your mindset.

What might cause a problem is that with Perl, you get used to solving several classes of problems quickly. Particularly text processing problems, or problems involving networked clients or servers. When you start getting into a second lanaguage, you're going to hit a frustration barrier when you realize just how much stuff you have to build yourself, by hand, to get to the point of attacking a problem that would take a few dozen lines of Perl.

This frustration can generate a secondary problem: If the other folks in your class see you as the guy/gal who is always complaining about how much better the world would be if everyone would just use Perl, it's going to put some of them off. Whining is not effective advocacy. Try to limit yourself to one "I could have done this in 10 lines of Perl" remark per week.

That aside, one issue you'll run into by moving from Perl (or Java) to C is garbage collection. In Perl and Java, it's mostly automagic. Drop the last reference to something, and it magically goes away. In C, and to some extent in C++, you have to manage dynamically allocated memory yourself. In some systems, a lot of effort goes into bookkeeping on memory. You might not run into this in CS unless you take a course in Software Engineering that tackles a large project.

   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

The essence of a degree in computer science is the second word in the course title - science. I was told once that the purpose of a university education is that the uiversity teaches you how to learn. You can then apply that knowledge to teach yourself other skills.

Let me expand on this. Those of us that studied computer science in the 1970's were taught Fortran, Cobol, Pascal, Algol, or C; and maybe APL or Simula, or some of the more esoteric languages. My first programming language was Fortran IV, my second was Pascal, my third C. DEC PDP-11 assembler was thrown in for good measure. What was the most important thing imparted to me was to approach a programming situation as an analysis situation. How to look for the real requirements. How to break the overall problem into discrete elements. How to use data structures, how to design algorithms. Somewhere along the way was formal grammars, lexical analysis, compiler design, Chomsky classification. Operating system theory - taught by one of the early Unix gurus, John Lions.

The result is, using that foundation that a good computer science education gives, you can continue to update your technical skills as new languages and technologies come and go. I have taught myself other languages, including Perl. I am sure there are many new things to learn in the coming years.

The fact that you know a modern language is a definite plus, since you understand how to design and structure programs. You will - or you should, at least - learn other programming languages as part of your studies. Approach each new language with an open mind. Each language will have some elements that you will find clumsy compared to Perl, each may approach design situations from a different perspective, each many have aspects that are superior to Perl.

You will have an edge over people with no programming language experience, if you use your knowledge correctly. You will not have to waste time understanding basic concepts (variable types, data structures, flow control, structured programming, and so on). You already know how to design a program that will be easy to maintain, easy to test and debug. But don't waste your energy saying "this would be so much easier if I did it in Perl". Spend your time thinking about why there are differences, and what aspects of various languages suit particular applications.

To sum up, Perl may well be the "swiss army penknife" in the developer's tool set (or was that swiss army chainsaw?). However, just as in any good toolbox, there are specialised tools - well honed chisels, allen keys, taps and dies - that are designed for only one job, but do that job to perfection; so you will need additional specialised tools within your knowledge set. What you should get from your university educations is not just the ability to handle some of these tools - but knowing what tool to use in a particular situation, and how to learn to use new tools as the need arises.

Update: some spelling mistakes corrected. Thanks Albannach

-><- -><- -><- -><- -><-
All things are Perfect
    To every last Flaw
    And bound in accord
         With Eris's Law
 - HBT; The Book of Advice, 1:7

A similar question would be.. If I learn how to use a table saw, will that make learning other woodworking tools easier or harder?

Though that's a little exagerated, the point is that a language is a tool. And if you're going to study computer science, you're going to want to know quite a few tools. The science behind it is as Maclir described. Just as studying woodworking is much more than how to cut a piece of wood.

Someone wiser than myself once told me that if you're a good programmer, language doesn't matter. Learning the syntax is the easy part. Using it well is the hard part.

Rich

When learning your second language, you are comparing it a lot with your first one, and sometimes you can get confused. When learning the third language, it is easier, because you can see patterns. And you can see also that it is rather easy to start reading in language and understand text written by others, but creating your own correct sentences is much harder, and need practice. Even with mistakes, is important to try to express yourself.

I read somewhere that learning (human) language is easier for children, because children are not afraid to make mistakes. We are taught in school to avoid mistakes, so we are waiting to express thinking in new language until we will master it, and it slows learning.

My only hope is that computer languages are much simpler than human languages, because mastering just one human language takes years!

silimonk

Two pieces of trivia about learning languages.

The first is that if you kind of know another language, the fastest way to become more fluent is to get drunk or angry. Doing that drops your normal barriers to looking foolish and you are willing to try. And it probably works. (Of course too much drink or too much anger causes even experienced speakers to become incoherent in time...)

The second is an interesting theory about why children are so good at learning languages, but adults find it much harder. The reason is that parents and children both desperately want to communicate. If mothers could meet their children half-way, they would. But that would result in a private shared culture and language, and the children would never learn to talk properly. So while both sides desperately want to make communication work, it is important that the kids are the ones who have to come all of the way and learn to talk like grown-ups do. And so the parents inability to learn is necessary for language and culture to get transmitted to the next generation.

I don't know if the theory is right or not, but it sure sounds plausible to every parent I have mentioned it to...

Learning any language will help you to learn others. With most languages you have the for loop, the do loop, the while loop, the foreach loop, if statements, case statements, declaring variables, etc. After you learn how these things work in one language, you have an idea of how they work in general.

Once you learn the basic structure of programming, learning a new language is a matter of learning new syntax.

Although, the more languages you know, the more likely that some of your efforts will look as if you had invented Visual Perl++...

-OzzyOsbourne

I somewhat disagree.

While there are a lot of things that work the same across languages, there are concepts which are supported in some languages but not in others. For instance when I have to work in a language which dos not have closures, I feel handcuffed. Yet you could have a tremendous amount of experience with C, Pascal, VB, Java and so on without ever having a clue that something like closures exist, let alone how you might use them.

Don't get me wrong. Learning languages is good. If you know several others, you can be productive in a new language once you learn the syntax. However every time you learn a new language you should be prepared to encounter new concepts which don't fit into your previous programming background. It isn't just about syntax.

Perhaps a more down-to-earth example are the many procedural programmers who had to struggle to learn what OO programming was about. A C programmer could quickly write programs in C++ or Java. But they wouldn't be writing programs the same way that someone experienced in those languages would...

--
I'd like to be able to assign to an luser

It gives you another perspective.

When solving computer problem, it is important to distinguish which issues are inherent to problem being solved, which are part of method (algorithm) used, and which are inherent to used language.

Sometimes we are tempted to use constructions which look elegant in selected language, without thinking if they are relevant or appropriate to a problem. Or, sometimes idioms good for one language are used in other language (C++like for in perl: for ($i; $i<=$#array, $i++) instead of: foreach $i (@array), and worse).

In other words, to be able to think about using proper tool for the problem, we need to distinguish what is a tool and what is a problem.

Learning new languages gives you this perspective - and understanding that there is no perfect tool. Not even perl is perfect. (downvotes coming...) Then you can really start to appreciate decent tool for rather wide range of problems, as perl is - and you have better feeling what you are talking about.

And you can also decide, where perl is not a good tool for a job, and why.

When you know only one (programming) language, you are like a person looking to his first sunset: sure colors are different than during the day, but is this the real thing, or just hurricane coming my way?

pmas
To make errors is human. But to make million errors per second, you need a computer.

I'm one of those guys who started with ALGOL in the 1970's. That was shortly followed by TUTOR (on PLATO), which gave me a deep appreciation for user-interface issues (guess why Macintosh clicked so well with me...). I'll not detail the half-dozen or so languages in which I have done significant work over the years, but skip to C (a bit), SQL (Sybase flavored), and (duh) Perl.

I did have the need to write programs in C to work against a Sybase database. Then I started using Perl and Sybperl. Perl spoiled me big time... The level of abstraction cut out so much niggling bits of code that my productivity want way up, and the frustration went way down. Now I could focus on the "what", not the "how". Tk helped make OO programming more obvious in useful ways.

How does this ramble answer the question? I guess that in the long run it won't matter that much which language you learn first, so long as you get properly exposed to a range of languages. Done right, you should be well equipped to take on a new language as circumstances require. Try not to become a language bigot (no matter how "perfect" the language).

yours,
Michael

UPDATE :
1) this post is supposed to be an answer to the main thread.
(Sorry herveus, I goofed when answering...)
2) Thanx dragonchild for pointing out an error (when I switch from hash to array, I should also remove 'keys' ;-)
IMHO you can/should learn from every language.
(Even with COBOL I learnt a lot about file IO, Indexed files, EBCDIC prob...)

I believe that each new language may give you another way to see (and thus solve) problems...
Pascal taught procedural programming, and OO basic programming (it was an object pascal).
C taught me to use memory and loops eficiently and gave me a first contact with "Unix semantic".
<UPDATE>>
Smalltalk influenced the coding of a lot of experienced coders here...
Ruby influenced the coding of another experienced coder here...
</UPDATE>>
Prolog taught me to think in term of predicate, recursivity and backtracking.
Lisp taught list processing, but I didn't understand/like them util I've found Perl...
(Btw in my mind Lisp will always be more about lambda calculus than about list)

I really discovered list with Perl (Lovely map and grep...).
I hardly imagine using other structure as efficient and evolutive as hashes...
the for my $var (@mytab) definitly took over my old C for(my $i=0;$i<=$#mydata;$i++)
It's not only a matter of syntax, it's a way to 'see' your structure, to 'think' your interface
(to be always evolutive, using hashes..) and your looping differently...

So, to be short a new language will often bring you new solutions/point of view
(in the 'old time' people were saying 'paradigm' ;-)
which can only enhance your ability to solve problem cleanly and efficiently (ie: enhance your programming skill)

"Only Bad Coders Code Badly In Perl" (OBC2BIP)

While Smalltalk did strongly affect merlyn and many others (eg dws), I have only been exposed to it second hand.