Re: How bad it is to learn Perl?

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"

Comment on Re: How bad it is to learn Perl? Download Code

Replies are listed 'Best First'.

Re: How bad it is to learn Perl?
by Abigail-II (Bishop) on Jul 22, 2002 at 09:52 UTC

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

Abigail

[reply]


Problems? Is your data what you think it is?
	PerlMonks