My programming languages experience started with BASIC, then VB and then I quickly moved
on to Perl. I loved the language and everyday I get a little bit more involved in it.

This year I switched majors and went into Computer Science, I took
Programming I in C++ and I'm dreading it. Now, everytime the teacher is
explaining something I think, "well, why all the fuss? I can do that in two lines of
perl." and I can't seem to appreciate any other language as I do with Perl.

So I'm currently thinking, is it a bad thing to learn Perl first? Should one keep this
gem of a language till a later stage to meditate upon?

Do you agree? Disagree? please share your thoughts about this.

He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.

It's important to allways remember that there is a
distinction between learning about a concept, and learning
about a language. This is something a lot of people don't
pick up on when studying Computer Science /
Computer Programming / Software Engineering.(*)

When you sit in a class, that just so happens to
be using C/C++ for all of the examples/assignments,
learning about Sorting Algorithms -- don't
focus on the syntax of the C++ code, or how many lines it is,
or how many lines it could be in Perl -- focus on the concept
and the general algorithm. because that's what's important.

In order to understand any concept a person is trying to
teach you, it's allways neccessary to understand the langauge
the person is speaking in -- so that's where it becomes important to
learn about a language. You don't have to like every language
you learn about -- but you should try to understand their
syntax, grammer, strengths, weaknesses, and conventions.
That way, you can understand concepts explained to you using
those languages. (And probably more important: the more languages
you understand the easier it is to understand new languages
in the future).

Typically, I find that whenever people with a lot of
experience using High Level langauges take classes that teach
low level concepts using C, they look at problems like
"write a method that converts an int foo into a char[] that
displays that int as a string." and say "this is stupid! I
could do this in one line of java:
String.valueOf(foo)" thereby missing the
whole point of the assignment: how do you think java
does it? (it's kind of like complaining about having to
learn how to do long division, because you can do it
really easily with a calculator.)

(*) This is why i really like text books that
invent their
own psuedo-code langauge (with a very limited
library of functions) in the first chapter, and then
use it for every algorithm/example/problem -- it keeps
people from thinking of the class as a "C class" or a
"java class" when they should really be thinking of
it as a "functional programming" or an "algorithms class"

Somewhere in the introduction of "Mastering Algorithms with Perl",
the authors point out that many text-books use pseudo-code to teach
algorithms. The authors prefer to use a real language, they think
pseude code has not much to do with reality.

I think "Mastering Algorithms with Perl" is an excellent example of
why you should prefer boooks using pseudo-code. MAP gets side tracked
over and over again, having to explain syntax, showing cute tricks,
discussing language specific efficiency, or promoting CPAN modules,
discussing API's instead of algorithms.

It might be good to quote Knuth:

Many readers are no doubt thinking, ``Why does Knuth replace MIX by
another machine instead of just sticking to a high-level programming
language? Hardly anybody uses assemblers these days.''

Such people are entitled to their opinions, and they need not bother
reading the machine-language parts of my books. But the reasons for
machine language that I gave in the preface to Volume 1, written in the
early 1960s, remain valid today:

One of the principal goals of my books is to show how high-level
constructions are actually implemented in machines, not simply to show
how they are applied. I explain coroutine linkage, tree structures,
random number generation, high-precision arithmetic, radix conversion,
packing of data, combinatorial searching, recursion, etc., from the
ground up.

The programs needed in my books are generally so short that their
main points can be grasped easily.

People who are more than casually interested in computers should have
at least some idea of what the underlying hardware is like. Otherwise
the programs they write will be pretty weird.

Machine language is necessary in any case, as output of many of the
software programs I describe.

Expressing basic methods like algorithms for sorting and searching in
machine language makes it possible to carry out meaningful studies of
the effects of cache and RAM size and other hardware characteristics
(memory speed, pipelining, multiple issue, lookaside buffers, the
size of cache blocks, etc.) when comparing different schemes.

Moreover, if I did use a high-level language, what language should it
be? In the 1960s I would probably have chosen Algol W; in the 1970s,
I would then have had to rewrite my books using Pascal; in the 1980s,
I would surely have changed everything to C; in the 1990s, I would
have had to switch to C++ and then probably to Java. In the 2000s, yet
another language will no doubt be de rigueur. I cannot afford the time
to rewrite my books as languages go in and out of fashion; languages
aren't the point of my books, the point is rather what you can do in
your favorite language. My books focus on timeless truths.

Therefore I will continue to use English as the high-level language in
TAOCP, and I will continue to use a low-level language to indicate how
machines actually compute. Readers who only want to see algorithms that
are already packaged in a plug-in way, using a trendy language, should
buy other people's books.

The good news is that programming for RISC machines is pleasant and
simple, when the RISC machine has a nice clean design. So I need not dwell
on arcane, fiddly little details that distract from the main points. In
this respect MMIX will be significantly better than MIX

I'm sure others will chime in on this (at least, I hope so), but my opinion is that it depends on the person, because there are some who can appreciate the variety and strengths of various languages, while others will find perl to be the language they have dreamed of (or feared, depending on their personality), and look no further.

My own experience was that I was first introduced to perl in a Unix course after having encountered BASIC, Pascal, FORTRAN, C, COBOL, two flavors of assembly-level languages, and several flavors of *nix shell scripting. At the time, I didn't know what I didn't realize how powerful a tool I was being handed, and didn't start to use and appreciate it until a later course in which the instructor said the students could use any language available on the school's computer system. I digressed into that so you see where I came from. At that point, I started using (and appreciating) perl, and when I later took a C++ class, I found the "pseudocode" I was using to document assignments was more and more frequently the perl code I would have used. Now, in my job, I primarily use perl, occasionally some form of shell scripting, with a little SQL, HTML, and PHP, to make things interesting, with once in a while being called upon to look at something in other languages as well, or to be asked to look at something to provide an alternate perspective.

Perl is a "swiss army-chainsaw," as someone put it, and very nice to have, but learning other languages will give you a more balanced perspective on perl's strengths (and yes, weaknesses), and a better understanding/insight (and appreciation) of the features you enjoy and their costs. To do so, though, you must give the other languages a "fair shake." The question is, can you let go and appreciate the IDIC of the languages and algorithms you study?

I'm self taught. Started using Basic in the late 80's, moved onto C (out of neccassity. Wanted to make games and Basic wasn't going to give a good frame rate at 16MHZ). Then for more speed and to handle the graphics went to assembler and writing self-modifying code. It was good but large projects took forever.

I stopped programming for a couple of years and then I met Perl. Thought it looked funky with all the sigils and way to much context. Very confusing for a C programmer. "This does that unless it's Tuesday or High Tide". Then I started spending some time with it and was amazed at how fast it was to develop things that were really difficult in the lower levels. I'm a Perl disciple and proud of it. I'm still amazed at how much can be done in so little. I think my beginnings really help me appreciate how much Perl rocks.

The point of all this is personally, I think everyone should spend some time in the bowels of their computer. It gives you a much better handle on the overall picture and IMHO makes you a more competent programmer. Learning Perl first isn't neccassarily a bad thing but I could see how going from Perl to C (or ASM) would seem like a huge step back. Like going from a BMW to a kid's bicycle. So on the surface, it seems that starting on the lower rungs is a good thing. On the other hand, the monotony of trying to do anything interesting in C or ASM could also turn off some who might otherwise thrive with a higher level language. So I guess the answer is Yes and No IMHO.

First off, to respond to you title, I have to say it's never a bad thing to learn Perl ;-)

But don't take that to mean that Perl is the be-all and end-all of languages. It is
constantly being reinvented itself, so it obvously isn't perfect (yet). It is
indeed fabulous and my language of choice (when I have a choice). You however
seem to be arranging languages in a hierarchy of quality, and while this
is a fairly natural response, I think you will soon realise that
there is no one scale upon which to measure language quality.

I'd also like to suggest that you will
have a hard time finding a language that doesn't offer you something
new and beneficial, even if is just a new way at looking at other
languages. As examples, consider
alltheoddballlittlelanguages
people invent for fun (where fun is more often than not defined as
intellectual curiosity). And don't forget that there are plenty of
embedded systems and proprietary systems out there that have
(almost) hopelessly inadequate languages, with which one can work wonders
if one has sufficiently broad background.

So with each new language, you should explore, test, push the
limits, and find out what is different from what you know, and some of that will
inevitably be better than what you know. It has been said before, but I'll
repeat it because it is right: being a good
programmer will mean knowing not just how to use your tools, but how to
choose the right ones for each job.

First off let me say i sympathize with you completely, as i am in a very similar boat (learned a lot of perl, taking c++ classes, etc), and while all the arguements about learning a low level language, or just a different one certainly are valid, i think the biggest problem is that you tend to get assignments that are more perl oriented, such as string processing and so forth, so you get to see first hand all of c++'s weaknesses (i think the state of strings in C counts as a weakness), but you never see any of the strenghts (super fast low level code).

I am also self taught, and the way got to different languages was simply based on need. I started with BASIC, and used that until I found a problem I couldnt solve well with it. So i learned something else. I used this to work my my way through learning the basics of shell scripting, VB, C, SQL. Then one day while working on a shel script I couldnt figure out how to do something so I popped on an IRC chanel for advice and someone replied with an answer that was like 3 lines of PERL code. So I started learning PERL.

My point is that i have always had a problem that drove me to one language or another once I started learning PERL, I havent come up with a need for another lang. Everytime I think there is something I can't do in PERL I find another module or coding trick that lets me get the job done. So in that sence it can be bad if your goal is to learn every computer programming language if your goal is to get your work done then it is a great day when you find PERL.

As for your case, I would just consider doing my homework a problem requiring the need for a new langauge. It never hurts to learn another way of doing things.

When I first started learning to drive, my Dad insisted that I learn to drive a vehicle with a standard transmission first before learning to drive an automatic. The reason is that once you get the standard down, the automatic is easy to learn. When you try it in the other way, its like having to learn things twice. Not only that, learning to drive on a standard teaches you more about how your car works.

I think Perl is the automatic car. It is a great language, very fast and convenient to use and also well supported. But, if its all you know, it becomes hard later on when you have to start looking under the hood.

I originally moved in the opposite direction as you. I started with c++ and then moved into Perl. I can say that having the c++ background not only made the migration to Perl very easy, but it has also helped me countless times where I have been forced to "look under the hood" and find out the exact way that perl does something (here, for example).

So, do I think people should avoid perl until they've seen something like c? Ehh, that might be a bit overboard. But I would say that perl is not the best primary language for a CS undergrad.

Go forth and learn ye some C, then when you return, a greater perl monk you shall be. :)

If you are interested in doing a little extra work,
your perl experience will be of great value.

When you get an assignment, code it in perl first.
Write tests for your code in perl, so that you can
run make test to verify it. Write your
perl code the cool way, using objects if it makes
sense to do so.

Next write your C++ code, and hook it up to your
perl tests.

You will write fanstastic code because you won't be
spending any time on the "does it work yet?" phase,
where so many other students will be floundering.
Also, the insight and clean design from your
excellent perl program will show through as clean
C++ code.

If your professor has a sense of humor, use the perl
code as comments to help explain the C++ code. This is
analogous to much assembly code that I have seen,
which used the equivalent C code as comments.

In a nutshell keep in mind that every language has it's purpose (maybe even COBAL). While you can do a lot in a few lines of Perl, it's important to consider what exactly Perl is hiding and doing for you. Many lower level optimizations for C++ also work for Perl, but can easily be glossed over if you don't understand what's going on in the guts. -- Well if optimization is important to you anyway :) Keep in mind that learning an approach in one language, can teach you a lot about other languages too. Learning Lisp for instance, gives you a pretty good understanding of recursion fairly quick.

in our country (Lithuania/Europe) we learn PASCAL at
scool (well not me anymore ;))

yes i agree that perl is a very siple to learn (at least
the basics) ... but if we talk about my country
there no (almoast no) realy good perl programmers...
and it would be difficult for every scool to have
a teacher who knows at least the same basic's of perl
he would teach...

[Your Mother]:They get almost everything wrong on every level. I think they create and restrict the market and fundamentally misunderstand audiences.

[Your Mother]:Consider how long, for example, superhero movies were kept at bay because they weren't commercially viable. They always were, just Hollywood couldn't see it or understand how to make one because there is no management talent in the town.

[LanX]:Erich von Strohheim built his career on beeing the most hated guy (The man you love to hate)

[Your Mother]:You see these amazing set, costumes, performances, etc, etc, etc all ruined by production and script decisions from the top down.