Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

How bad it is to learn Perl?

by Chady (Priest)
on Jul 20, 2002 at 06:38 UTC ( #183560=perlmeditation: print w/replies, xml ) Need Help??

I've been wondering lately, is it bad to learn Perl first?

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.

Chady |

Replies are listed 'Best First'.
Re: How bad it is to learn Perl?
by hossman (Prior) on Jul 20, 2002 at 07:32 UTC
    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


Re: How bad it is to learn Perl?
by atcroft (Abbot) on Jul 20, 2002 at 07:52 UTC

    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?

Re: How bad it is to learn Perl?
by shotgunefx (Parson) on Jul 20, 2002 at 10:04 UTC
    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.


    "To be civilized is to deny one's nature."
Re: How bad it is to learn Perl?
by Albannach (Prior) on Jul 20, 2002 at 20:01 UTC
    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 all the oddball little languages 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.

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

Re: How bad it is to learn Perl?
by BUU (Prior) on Jul 20, 2002 at 18:07 UTC
    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).
Re: How bad it is to learn Perl?
by Desdinova (Friar) on Jul 20, 2002 at 20:07 UTC
    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.
Re: How bad it is to learn Perl?
by ehdonhon (Curate) on Jul 21, 2002 at 03:24 UTC

    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. :)

Re: How bad it is to learn Perl?
by toma (Vicar) on Jul 21, 2002 at 16:23 UTC
    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.

    It should work perfectly the first time! - toma

Re: How bad it is to learn Perl?
by Anonymous Monk on Jul 20, 2002 at 16:33 UTC
    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...

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://183560]
Approved by Jazz
Front-paged by rinceWind
[Your Mother]: A-Team.
[LanX]: never liked it, but a friend of my mother was a big "fan" of Mr T xD
[LanX]: (talking about minority chicks)
[LanX]: Hollywood is built on stereotypes which sell, this includes stereotypes about English, French, russians and ... Americans
[Your Mother]: I think to some degree, maybe a large one, the stereotypes are purely products OF Hollywood and not what would sell best.
[LanX]: well those products which sold best are replicated
[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.

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (9)
As of 2018-03-19 14:54 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (240 votes). Check out past polls.