Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Perl Books Media Programming Book Reviews

Mastering Algorithms with Perl 225

Posted by Hemos from the getting-to-know-your-perl dept.
John Regehr sent us an excellent review of Mastering Algorithims with Perl, another O'Reilly & Associates effort. Written by Jon Orwant, Jarkko Hietaniemi, and John Macdonald, this is a book designed to take your Perl to a new level of wizardery.
Mastering Algo
author Jon Orwant, Jarkko Hietaniemi, and John Macdonald
pages 704
publisher O'Reilly, 08/1999
rating 8/10
reviewer John Regehr
ISBN 1-56592-398-7
summary The intended audience is programmers who don't have a background incomputer science, who know at least some Perl. However, experiencedprogrammers who don't know Perl should have no trouble picking up thebasics of the language with this book and a copy of ProgrammingPerl.
In The New Hacker's Dictionary under "superprogrammer," we read that "productivity can vary from one programmer to another by three orders of magnitude." I would argue that at least one of these factors of ten comes from the ability to quickly recognize what algorithms should be used to solve different parts of a problem and to find or write implementations of those algorithms that will result in an efficient program, given the available time and the characteristics of the problem. This ability is developed through experience and by understanding the highlights of the large body of algorithms and analysis of algorithms that has been developed to solve problems that occur over and over again in computer programs.

Mastering Algorithms with Perl is designed to provide the necessary background. It's structured like a traditional algorithms textbook: after describing some basic and advanced data structures (linked lists, trees, heaps, etc.), it has chapters about searching, sorting, sets, matrices, graphs, strings, and some related topics. After the introduction and discussion of data structures, the chapters are relatively independent and could be read in any order. The authors provide plenty of cross-references as well as pointers to books that describe individual subjects in more detail.

The intended audience is programmers who don't have a background in computer science, who know at least some Perl. However, experienced programmers who don't know Perl should have no trouble picking up the basics of the language with this book and a copy of Programming Perl. Also, computer scientists can often use a review of algorithms, and the CPAN pointers are very useful. So, I would go so far as to say that this book would enrich any programmer's bookshelf. A stringent test of the merit of a new technical book is to ask if it adds some value, given the best existing books in its area? I think that Mastering Algorithms with Perl definitely does. It is a well-written introduction to algorithms that is more accessible, practical, and entertaining than standard algorithm books. It leverages off of the strengths of a powerful language and a large base of reusable code.

The rest of this review will evaluate the strengths and weaknesses of Mastering Algorithms with Perl in more depth. The central issue that I will consider is why the reader might or might not prefer an algorithms book that concentrates on a single language, as opposed to a general algorithms book. I will try to be up-front about my biases: as a computer scientist, I consider this book to be a compromise between an algorithms book and a how-to manual. This compromise makes it much more useful to Perl programmers, but it sometimes causes the algorithms content to be too watered down.

It is traditional in algorithms books to describe algorithms in pseudocode, which often superficially resembles Pascal. The difference between pseudocode and real code is that pseudocode is not compilable - it ignores implementation details that are not helpful to understanding a particular example. This is considered to be an advantage: without the clutter, the core of the algorithm is easier to see and understand. At the beginning of the book the authors make the point that the Perl code for a binary search is actually shorter than the corresponding pseudocode. And it's true! The advantage of the Perl program is that we have a readable description of the algorithm, and it's executable too. (Unfortunately, it's often nontrivial to convert pseudocode into real source code - the devil is in the details.) The binary search example is slightly misleading, however, because in this case a native Perl data structure (the array) matches the semantics of the problem extremely well, leading to a clear and concise implementation. Later in the book, particularly in the chapter on graphs, we see examples where Perl's built-in data structures are less well suited to the problems. The executable Perl code for graph operations are much longer than the corresponding pseudocode, and are often so syntactically cluttered that they are difficult to read. Is this a flaw in the book or in Perl? No - it's a consequence of giving examples in runnable code instead of pseudocode. Is the tradeoff worth it? Probably, but it depends on what you're trying to get out of the book.

Another consequence of basing an algorithms book on a real language is that the authors can point readers to existing implementations of the algorithms, in CPAN. It's hard to overstate how big of a win this is. Perl is a powerful language to begin with, but it becomes far more powerful when programmers are able to take advantage of the large body of existing code modules. An unfortunate side effect of the fact that the book talks about specific versions of Perl and about specific CPAN packages is that this information will become outdated much more quickly than the algorithms will. Unless the Perl language and CPAN are exceptionally stable in the future, I would not expect most of this information to be valid for more than a few years - hopefully a new version of the book will be available before this one becomes too out of date.

Because the book provides executable code for the algorithms, it's possible to evaluate the performance of the example code (which is available at the O'Reilly site). The authors benchmark a number of the algorithms that they present, and compare the results. This is a nice change from the discussion of asymptotic running times found in traditional algorithm books, which generally ignore the constant factors that often make the difference between an algorithm being useful in practice or not.

The design and analysis of algorithms is a highly mathematical discipline. A sophisticated set of tools has been developed to evaluate the tradeoffs between various algorithms: How efficiently do they use memory and processor cycles? What is the best, average, and worst case running time of various operations? How does the algorithm scale as the size of the input grows? As it turns out, programmers need to understand a few of these formalisms, particularly the "big O" notation for describing asymptotic running time. I think that Mastering Algorithms with Perl uses theory in just the right way: as an aid to programmers' intuition about algorithms, rather than beating us over the head with formulae and proofs. That said, I think there is one area of theory that this book should have spent more time on: NP completeness. NP-complete problems are solvable, but are believed to be inherently hard: no efficient algorithm has been discovered to solve them. There are a wide variety of NP-complete problems, and they do come up in practice. For programmers, the important thing is first to recognize that an NP-complete problem has been encountered, and that it cannot be solved exactly except in small instances. Then, a heuristic that comes up with a good enough approximation of the solution needs to be found and implemented. This is a practical and well-studied part of algorithm design, and in a 650-page book I would expect more than a page or two to be devoted to it.

Several chapters of Mastering Algorithms with Perl are too shallow to be considered good introductions to the associated areas of algorithms. For example, the chapter on matrices only shows code for some of the more trivial matrix operations; for complex tasks, it tells the reader how to use PDL - the Perl Data Language. Although PDL looks like a useful and powerful package, readers should not confuse knowing how to use it with understanding matrix algorithms. In other words, the matrix chapter is too much of a how-to manual. Other chapters such as the ones on searching and sorting are excellent and avoid falling into this trap. Algorithms is a huge area, and it can't all be covered well in 650 pages. The later chapters are a lot of fun to read, but some of them should probably have been scrapped in favor of more depth in core areas.

In conclusion, this is a well-written, useful book. Viewed as a Perl book it's superb; it complements the strengths of Programming Perl and The Perl Cookbook, and I think most or all Perl programmers would benefit from having a copy. Viewed as a computer science book, it has made a number of compromises in order to focus on a specific language; this is not necessarily a problem but it is something that readers should be aware of.

Acknowledgments: Thanks to Tom Christiansen, Dave Coppit, Bill Pearson, and Jamie Raymond for helpful comments on previous drafts of this review.

Purchase this book at fatbrain.
This discussion has been archived. No new comments can be posted.

Mastering Algorithms with Perl More

Mastering Algorithms with Perl

Comments Filter:
  • This looks like the perfect gift for that PERL nut in your life for X-Mas ;)

    --
  • So if we don't know Perl, or any other language (yet) then we're screwed in reading it?
    Argh. Can anybody recommend a good basic book for those of us not from a Computer Science background (my degree is in theatre) but who are trying to get into programming, albiet slowly?

  • Agreed - I know the fundamentals of things like VBScript and have used Visual Basic and C++ and Pascal (yes really!) to a limited extent. Anyone got any pointers for any good online resources for learning things like CGI and Perl?
  • If you are looking to get into programming, perhaps you should look into "Learning Perl" by OReilly, it's the llama book. I would say that Perl is sufficiently easy as a beginning language.
  • First, I'd like to say that this book is probably *not* for the beginner (as in, read one of the other Perl books first, and write in it for a while, I still have to read Learning Perl sometime...)

    Second, I'd like to ask why a good, pseudo-code, readable language *isn't* more popular nowadays. There are many books written like this (my Operating Systems text in school, and many of the examples, are written in something that looks like Pascal with support for multiple processes, although I've never seen such a beast) and their code is very readable.

    I used to write in Turbo Pascal 7, and I enjoyed writing classes ("objects") with it. All my code was inherently pretty readable, even when I used nasty tricks, unlike my C code (or most Perl code that I've seen). Later, I did convert some of it to C and C++ with p2c and some hacking on my own, but it would be nice to maintain the readable version of the code. :)
    ---
    pb Reply or e-mail rather than vaguely moderate [152.7.41.11].
  • Learning Perl by O'Reilly. Or you could make the mistake I did, and buy Programming Perl instead. Of course, the O'Reilly books are so clear, it helped me quite a bit.

    I don't really have any programming background, just batch files and shell scripts. The best thing I have found to do is find a piece of code, play with it, and look up what you don't understand.

    Guess I have to add yet another O'Reilly book to the collection...
  • provides very little that you can't get in a basic data structures class. I finished the entire book at a swim meet one day because there really wasn't anything that revolutionary behind it. Aside from pseudo-hashes, which look pretty nifty, I don't see much value in investing in this book if you already know data structures/sorting algorithms. I suppose if you didn't have a basis in those it would be a wise investment but even then most of the concepts are fairly simple and fairly intuative. My advice would be to buy an office copy and keep it around as a reference for your programmers if they have a brain freeze, but don't bother with a personal copy. .agrippa.

  • I would recommend Learning Perl also by O'Reilly & Associates. When I first started learning Perl, this book was invaluable. Perl was also, for me anyway, a good first programming language to learn on. Prior to that, the only other language I had learned was BASIC, and only very little. Most people will recommend not starting with a language like C, due to its complexity. Perl seems to be a good starter.

    I now use Programming Perl and Perl Cookbook. Both are from O'Reilly & Associates. This book also sounds like a good reference to have once you have the basics down.

    Ryan

    P.S. My major was also theater (design).

  • I have this book and have skimmed through it. This is basically computer science algorithms (zillion of different sorts, graph representation, etc.) implemented in Perl. The problem is that this book has limited relevance to real life. "Perl Cookbook" is much, much more useful in this regard.

    So, if you are collecting all Perl book, or are really interested in how to implement red-black trees in Perl, do buy it. On the other hand, if you are looking for snippets of code to solve small-to-medium-sized problems you meet all the time, "Perl Cookbook" is a much better choice.

    Kaa
  • I've seen some suggestions for "Learning Perl" here, and I'd agree. But you might also want to think about "Learning Python", also from O'Reilly.

    This is straying onto religious war territory, but Python's possibly an "easier" language to learn than Perl for a newcomer to programming, and it's certainly as powerful (and anyway, they have a lot in common).

    Hope This Helps,

    Andy
  • Can anybody recommend a good basic book for those of us not from a Computer Science background (my degree is in theatre) but who are trying to get into programming, albiet slowly?

    You don't necessarily need a book. Although I like having a peice of paper to reference (call me old-fashioned), there are many resources you can access for free on the internet (and print out if you're like me). Just hop over to http://www.google.com and enter the words "Perl Tutorial" for lots of good links.



  • "it ignores the very interchangeability of languages at the heart of such things as the open- source movement"

    Errr.. ?

    I think you are missing the point. There are plenty of books on Algorithms. Loads. Really, lots and lots and lots. However, until now there were few that focussed on Perl.

    Some consider Perl to have outgrown its old 'Unix scripting language' roots, and so a book that looks at a strong foundation of programming principles for Perl is welcome.

    If this book is shelved with 'Algorithms' then it has been misshelved, I'll grant you. If it is shelved with 'Perl' then it is a very useful contribution.

    I don't think the author's were trying to promote greater understanding of algorithms and forcing people to learn Perl while they did it.
  • I would disagree that perl is a good beginners language. It has way to many hacks and gimmics in it. (This is not always a bad thing. Just that it lets beginners get away with too many things. At one point I inherited some horrid perl code that a decent grounding in CS would have helped immeasurably.) I'd suggest a cleaner, strongly typed language like python or java. Both have active development groups, and there's lots of documentation and examples out there. And ORA has books for both languages.
  • "Mastering Algorithms" talks about implementing solutions to generic problems. "Cookbook" is a hodge-podge of code tailored to common problems.

    For an algorithms book, Wolf is quite nice. It has some wonderful discussions of queues, stacks and their relatives. This far from a so-so book for what the book intends to discuss. Ram is quite nice too for that "how do I find the difference of two arrays again"? type problems.

    Please DO NOT compare apples to oranges.

  • I think you've hit the nail on the head.

    Perl has been unusual in being a language that started in a small niche were it was used by non-computer-science folk (Unix sysadmin), moved into ANOTHER niche of the same kind (simple CGI), and is now widening its usage into a general applications programming language.

    That's why these kinds of books are very useful - so many Perl programmers such as me never went near a CompSci class.

  • There is one part of the review which doesn't make much sense

    That said, I think there is one area of theory that this book should have spent more time on: NP completeness. NP-complete problems are solvable, but are believed to be inherently hard: no efficient algorithm has been discovered to solve them. For programmers, the important thing is first to recognize that an NP-complete problem has been encountered, and that it cannot be solved exactly except in small instances.

    A big part of this is simply wrong. Problems are NP-complete if it is proven that there is no algorithm which solves it in polynomial time. What he describes is NP-hard. His basic requirement, finding out if a problem is NP-hard needs some literature research. To recognize an NP-complete problem one can read about it if it is known. If no literature is found, showing that the problem is NP-complete will take skills on highly advanced levels.

    RSA crypto is a good examples: It relies on factorization being NP which has not been proven. It uses so calld strong primes to avoid polynomial factorization algorithms.

  • If it's Perl you're looking to get into, the Great O'Reilly offers up a number of books, including Learning Perl, Programming Perl, Advanced Perl Programming, the Perl Cookbook, etc. Start out with Learning Perl. Some other posts mention Python, which is also good for CGI, and you can pick up O'Reilly's Learning Python and Programming Python. Be forewarned, though. I've used both for CGI programming. And when I'm using Python (powerful though it is), I find myself longing for the regexps of Perl.

    If you'd like an online tutorial, you might want to check out The CGI Resource Index [resourceindex.com], which is made by the same guy as Matt's Script Archive [worldwidemart.com]. Between the tutorials on the Resource Index, looking at the source of Matt's script, and reading the O'Reilly books, you can learn just about anything you want to know about Perl.

    Of course, if you get stuck, you can always go to ng's, irc, or your local Perl nut.

  • Excerpt available on line (Score:4)

    by Pope Slackman ( 13727 ) on Wednesday December 08, 1999 @06:09AM (#1475781) Homepage Journal
    Chapter 10, 'Geometric Algorithms' is available in PDF format, here. [oreilly.com]

    --Kevin

    =-=-=-=-=-=
    "I think the P-Funk Mothership just landed in my back yard!"
  • I've been looking for the same thing. Seems every book on programming (regardless of language) I've seen assumes some background in programming. If I could get a good introduction to programming, I might be convinced to take some CS classes. But untill then, I can't afford to spend the time/money on something I might have no aptitude for.
  • Mastering Perl Device Drivers? :-)

  • Why Perl? Perl's day is over (Score:2)

    by Anonymous Coward
    I have some experience developing server applications in Perl. In short, as the app got more complex, I found Perl increasingly more difficult to use. The OO model seemed like a big hack, not unlike the rest of the language. It's very unreadable to me. Readable Perl can be written with some effort. More often than not, its overly flexible syntax leads to a lot of terse or confusing code, especially when non Perl experts try to write it. e.g. everything is done with regular expressions Don't get me wrong -- when I learned Perl, it was the coolest thing. It was great for quick hacks, very powerful. But as an application language it just seems way too loose. Yeah -w, use strict, etc. It was just not designed from the ground up to deal with modules very well. Java's package system is much better. I would much rather use Java (or Python or Smalltalk) for anything other than utility scripts (which Perl is really good for). I notice that even a lot of web sites are moving away from Perl CGI scripts to use JSP and so on. I suspect they found the same thing I did - Perl isn't a very good language for developing _large_ maintainable apps. So what does this have do with with the review? Well, I'm trying to figure out why someone would be studying algorithms in Perl. I guess O'Reilly has to capitalize on the Perl wave and suck every last buck they can from it. I suppose Perl's expressiveness makes it okay for expressing algorithms. Indeed it is easy to do some complex things (though data structures are a big hack too). I think Perl has seen its day, and will quickly be relegated to a system utility scripting language.
  • It *is* possible to write readable, maintainable C and Perl. But it's a discipline. You have to resist some of the fancy tricks and place the value of readability over the value of squeezing your code onto a single line.

    But of course, obfuscated code is cool, etc. :-(

    Andy
  • I believe the reviewer wasn't trying to be precise, but rather to give the gist of NP-Complete. For example, many non-cs people would think that the problem of "bin packing" is easy.
    Learning that there are distinct classes of problems, and being able to have a gut feeling that one problem is intrinsically harder than another is an important skill.

  • No, YOU are wrong (Score:4)

    by FascDot Killed My Pr ( 24021 ) on Wednesday December 08, 1999 @06:32AM (#1475788)
    Problems are NP-complete if it is proven that there is no algorithm which solves it in polynomial time.

    Wrong. Problem A is NP-complete if there are no problems in the set NP that are harder than A.

    Furthermore, no one has yet proved that NP problems cannot be solved in polynomial time, although it is widely suspected this is true.

    What he describes is NP-hard.

    The classes *I* took used "NP-complete", "NP-hard" and "hard for NP" synonymously.

    ...factorization being NP which has not been proven

    Again, just plain wrong. Prime Factorization is known to be NP (NP-complete, in fact). What is NOT known is whether PF can be solved in polynomial time.

    It sounds very much like you picked up your Computation Theory knowledge by reading posts on Slashdot. I don't recommend that for people who enjoy flaming.
    ---
  • There is one part of the review which doesn't make much sense

    No, it's your post which doesn't make much sense.

    A big part of this is simply wrong.

    No, it's not.

    Problems are NP-complete if it is proven that there is no algorithm which solves it in polynomial time.

    No. A problem is NP complete if it is in NP (i.e it is an decision problem whose solution can be verified in polynomial time) and if every other problem in NP reduces to it. It is believed that there is no polynomial time algorithms for NP complete problem, but this has not been proved.

    A problem is NP hard is every problem in NP reduces to it (i.e it need not necessarily be in NP)

    If no literature is found, showing that the problem is NP-complete will take skills on highly advanced levels.

    I'm not sure what you mean by "highly advanced". We teach it to second year undergraduate CS-students.

    My (limited) experience with real-life examples is that they are either trivial or quite difficult to prove NP-complete.

  • In my opion this some book's algorithms are on the useless. Linked lists, while nessecary in some languages, are incredibly useless in perl. Hashes and dynamicly sized arrays eliminate the need for this. Sorting is covered, but perl has builtin sorting, and builtins are always faster than anything you'll write in perl. This is only the first 150 pages of the book. Those pages also include things like heaps and binary trees.

    I have this book in my library, but don't think I'd buy it again if I had to rebuild it. It's one of the few perl books that collects any dust on my self.

  • Python and Java are great beginner languages, but for somewhat different reasons. Java is a conceptually simple language, stressing object re-use (and interfaces) with strong typing. Code written in Java is often quite readable with a mediocrum of care and if something compiles, you can be reasonably sure it'll run with only a logic bug or ten.

    Python is also conceptually simple, but it stresses operator overloading over object re-use and inheritance trees are typically pretty shallow. Lack of types make for code that's quick to write, not too hard to read, but you have to check them well because your arguments could be anything.

    Maybe there should be an "Algorithms in Python" book. The language is ideal for beginners - even moreso than Java because of built-in lists and hashes.

    Just my minor nit about typing :)

  • Try reading "Object Oriented Perl" (Score:3)

    by Matts ( 1628 ) on Wednesday December 08, 1999 @06:53AM (#1475793) Homepage
    Seriously - read the subject. OOPerl is an amazing book - perhaps the only perl book you'll need. It's very concise, very clear, and the code you end up producing is clean code, not unlike Java or Python code.

    Really though you're trolling. Sure there are things wrong with perl (like the fact that the second argument to bless isn't mandatory), but you can create crap code in any language. If you have experience of building a large app in perl and it all went horribly wrong because it got too large - you only have yourself to blame.
  • Oh, yeah. Everyone in comp.lang.perl loves Matt Wright's work.

    Buy an O'Reilly book.
  • First, I'm not a CS type person. My most valuable book for programming, especially linux is Beginning Linux Programming. This little jewel covers a wide range of topics and languages used on linux systems. Everything from bash to c to perl/cgi to tcl/tk to x. There is a new edition out (2nd) which appears to cover gtk+ for gnome as well. I've not looked at this one. I think that every Beginning Linux Programmer need Beginning Linux Programming. Andrew N.

  • Re:ahem - Microsoft- sponsored trolling (Score:1)

    by Anonymous Coward
    Some of the strongest proponents of free software are completely against the GPL. It's not free of restrictions. That's why it's not free. However, most of them don't bother to show up to this den of Linuxness and GPL flag-waving. Tom does. But now than anyone who blasphemes against the Holy Father, the great Richard "I can pontificate if I want to" Stallman gets robomoderated into oblivion here, the real thinkers don't bother. Plus, they've been through those arguments before. Tom should just realize that the GPL cultists will never see what he's talking about and give up.
  • As someone who learned most of his high school and up till second year college mathematics reading books on Pascal algorithms, I enjoyed this book.

    I've always found it easier to understand mathematic concepts transcribed to code because of the lack of vagueness allowed by computer languages. The author can't skip a step(s), refer broadly to previous concepts that may or may not have been explained/understood, or hide ideas necessary for full understanding by invoking the classic "you don't need to know this yet" mantra extolled in most lower level mathematic books.

    I find also that because computer languages have been engineered from the ground up to reuse previously mastered concepts ( functions & | objects) they lend themselves well to explaining very complex ideas.

    Higher level mathematics can and are expressed as proofs, lower level mathematics should be expressed as computer algorithms..? Written in perl? Works for me!

    This book is just fun. :)

  • I picked up Lutz & Ascher's Learning Python just over a week ago, and I already love it. One of the great things about Python as a learning language is its "interactive" mode; run the interpreter without a program file ("module" in Python terminology), and you get an interactive prompt. Just start typing in statements; you can define functions, set variables, load modules, etc. Anything with a return value displays that value. It's a lot easier for experimenting with different statements than the usual cycle of edit a file, run it, edit it again, run it again, etc.

    I've seen Python described as "pseudocode that runs", and so far, I have to agree; it pushes you toward writing more readable code. Yeah, yeah, yeah, "you can write readable or unreadable code in any language", and that's true. But where Perl seems to require additional effort to write readable code, Python seems to require extra effort to write unreadable code.

  • For specific complaints about Matt Wright's code, search comp.lang.perl.misc. Gripes include code that will break in about 3 weeks (e.g. "19$year" will change from '1999' to '19100'), security holes, and bad code in general.


    Kurumi http://www.kurumi.com [kurumi.com]

  • Another algorithms text recommendation (Score:3)

    by DiningPhilosopher ( 17036 ) on Wednesday December 08, 1999 @07:18AM (#1475814)
    Introduction to Algorithms [fatbrain.com], Cormen, Leiserson and Rivest (yes, Ron Rivest, the R in RSA).

    Far more mathematically rigorous than the O'Reilly book (from what I read of the O'Reilly book in the bookstore - I didn't buy it because it didn't look like much I didn't already have). No actual code, just pseudocode. I think this is the book you want if you really want to learn about algorithms (but not if you just want to get stuff done in Perl).

    It's expensive, but it's a tome (>1000 pages). It was a good class textbook and still makes a very good reference. Check out the Table of Contents [fatbrain.com].

  • Re:Summary (Score:1)

    by Anonymous Coward
    Basically, get the O'Reilly books on Perl:

    Get the camel book. You cannot go wrong with that. -
    "Programming Perl, 2nd Edition" by Larry Wall, Tom Christiansen and Randal L. Schwartz
    ISBN 1-56592-149-6

    "Perl in a Nutshell" ISBN 2-56592-286-7 is a handy companion volume organised for quick reference
    I haven't got a copy myself, but I will when I get organised enough to get it.

    I also recommend "The Perl Cookbook" ISBN 1-56592-243-3, which contains a load of useful code snippets to do all sorts of things. I found it very useful for "learning by example".

    I think one of the major reasons for the popularity of Perl has been the availability of well-written documentation such as these three books. Another reason is the CPAN code repository, which makes code reuse easy.
  • No, it's not the best code in the world. But it's a nice starting point. A newbie sure doesn't want to try to read my code.
  • Doesn't Larry Wall (creator of Perl) work at O'Reilly now? If I'm remembering correctly, why is it that we haven't seen any Perl books written by him except the Camel book? I'm knocking the man, he rocks, but I'm just wondering. All the Perl books seem to be written by Christensen and the other Perl luminaries.

    Maybe he's spending all his time on the next State of The Onion...
    • BASIC, check. Unfortunately, that includes VB, QBasic, and VBscript.
    • Modula, no, though I've heard it's a bastard child of Pascal (check) or vice-versa.
    • Fortan, check. Hate it, but I can see why scientists love its math features.
    • C, check.
    • Java, half-check, since I've only done textbook exercises in it.
    • C++, check.
    • awk, half-check.
    • Lisp, check.
    • Prolog, half-check.
    • ML: is there an actual language named ML, or is this shorthand for machine language? Never touched the former, done 68000 assembly and machine code down to the bit-twiddling level.
    • Perl, working on it; there is a llama in my backpack.
    • sh, check.
    • Python, working on it. Hopefully, the rat and the llama won't start fighting.
    • Cobol, nope, nobody's put a gun to my head yet.

    What, no mention of Smalltalk (check), Ada(check), or Dylan^WButt-Head Musician (nope)? After the first three or four languages you learn, the next twenty become easier. Not that I remember most of these languages, but I did assimilate the basic principles once upon a time. I keep telling myself that I could pick them up again pretty quick if anyone ever did take my resume seriously.

  • I have written Server Apps from the ground up in Perl consisting of several thousands lines of Perl (~5000) and did not encounter the same issues you did. Perls modules provide good encapsulation if you use them correctly and data scope is up to you to define.

    The thing I like about Perl is that it gives you _freedom_. You just need to have discpline for large scale projects. (not really different then in any other language).

    Reg Exp are condensed code and I find if used properly they increase code readability since a single line of reg exp contains a complete thought in one concise statement - instead of spreading the purpose over several loops of code.
  • A big part of this is simply wrong. Problems are NP-complete if it is proven that there is no algorithm which solves it in polynomial time.

    If you can prove the nonexistance of a polynomial time algorithm for any NP-complete problem, you'll get a Turing Award.

  • Yeah, you definitely won't want to start your programming experience with algorithms if you're new to programming.

    I would also really suggest that your first programming language be something (anything! ;-) ) other than Perl. It's really easy to use, but it makes it so easy to fall into bad programming habits. This is a good thing if you already know what you're doing, but a horrible way to start programming. This is one of the main reason why Perl gets no respect in academia -- it's still pretty much viewed as a toy language. That said, I probably have written more code in Perl than I have in any other language by an order of magnitude. I'm serious, though, don't let Perl be the first language you learn.

    Something I'm really starting to enjoy is Python, and it seems to be picking up steam, so I'd strongly recommend O'Reilly's Learning Python, which seems to be about a gentle introduction to a programming language as it gets. (I'd give Learning Perl 2nd-place honors here. I still don't recommend you start with Perl, but I'm not sure why so many people dislike this book as an introductory text -- it lets you do useful things pretty much right away.) I wasn't too pleased with Programming Python, especially compared to Programming Perl, so I ended up learning the language from the Learning book and then using the great online documentation.

    If I had a gentle Java book to recommend, I'd give you that as well, because despite all the troubles, I think a lot of people will eventually use it, or at least variations of it. Like Python, it'll help get you acclimated to object-oriented principles, which I recommend, and there is plenty of sample code out there for both. Not as much sample code as Perl, but you don't want to get your feet wet with Perl, do you? (Sensing a theme yet? ;-). Also, it's pretty much taken for granted that the Python folks seem like great guys and very helpful, and that the Perl guys are, well, not the friendliest people around. Jon Orwant (a Perl guy who, along with Larry Wall, I do like) was even quoted in this month's Linux Journal that the Python guys seemed nicer. Considering the dim view that many in academia have of Perl, I'm not quite sure exactly how so many in the Perl community turned out to be egotistical/self-righteous dicks, but it sure seems like it's happened. (And no, this isn't why I'm urging you from starting out with Perl -- I still use it all the time myself.)

    Cheers,
    ZicoKnows@hotmail.com

  • This Week's Programming Bestsellers

    1.
    Programming Perl
    2.Extreme Programming Explained: Embrace Change
    3.Beginning Linux Programming 2nd Edition
    4.Professional Java Server Programming
    5.The Complete Java 2 Certification Study Guide
    6.Learning Perl
    7.Beginning Java 2
    8.Just Java 2.0
    9.Mastering Enterprise JavaBeans and the Java 2 Platform
    10.Perl Cookbook
  • Not to defend AllAdvantage (I think "get paid to watch advertising" gimmicks are crass), but I don't consider a link in a sig to be "spamming". If this person were posting repeatedly for no reason other than to get his/her sig seen, yes, that would be "spamming". But a URL in a sig is commonly-accepted Usenet practice, and I think the same should apply to Slashdot.

    Apologies for the topic drift, back to the regular discussion.
    -----
    The real meaning of the GNU GPL:

  • Beginners don't think anything until they're told or they find out for themselves. The nice thing about being a beginner is a lack of predefined notions. How often do beginners actually need copies of things? For numerical values it's helpful, but those copy anyway. Typically if you have a some list of things (an item that doesn't copy by default), you don't care whether it's a copy or not. You just cycle through the list, do something to the elements and move on.

    As for the whitespace issue, it can be annoying, but minimized with the use of a decent text editor. Python has quirks, certainly, but seems more consistant than Perl in general. Consistancy is good for beginners (maybe not for everybody, but certainly for beginners).

  • You might be right. I don't have that one here at work so he might have.
  • The classes *I* took used "NP-complete", "NP-hard" and "hard for NP" synonymously.

    NP-complete is a subset of NP-hard.

    NP-complete problems are all as hard as each other in the sense that either all of them or none of them can be solved by a polynomial-time
    algorithm.

    NP-hard problems are at least as hard as NP-complete problems. So, for example, the halting problem is NP-hard, but it is not NP-complete.

    Anyway, this is not the part of NP-completeness theory that I think programmers need to know. What they need to be able to do is recognize that, for example, the way they are attempting to optimally put outgoing mail messages into the proper queue is equivalent to bin-packing, and therefore takes exponential time in the worst case. They can then go find one of the excellent bin-packing heuristics that has been developed, implement it, and then move on.
  • What a relief, a good textbook. The CLR text is required for my algorithms course next term. I'm so sick of awful CS textbooks and hated the thought of investing in another expensive book I'd never use again. Thanks for the recommendation.

    P.S. Have you been able to get enough time with a second fork to keep from starving?

  • > The classes *I* took used "NP-complete", "NP-hard" and "hard for NP" synonymously.

    NP-hard : every problem in NP can be reduced to this problem.

    NP-complete : NP and NP-hard.

    > Prime Factorization is known to be NP (NP-complete, in fact).

    Do you have a reference for this? How do you reduce Satisfiability to factorization?

  • Ok, ay caramba. Slashdot is really showing it's stuff, today.

    Yes, NP-complete and NP-hard are not synonymous.

    So:

    NP means "polynomial-time verifier".
    NP-hard means "reduce to NP in polynomial-time".
    NP-complete means "NP and NP-hard".

    But, these all refer to classes of computable problems.

    The halting problem is the prototypical "not computable" problem. Thus, it is not in NP-hard.

    Hehe, I hope I got that right :)

    nick

  • Well (Score:2)

    by ransom ( 115658 )
    I think that this was the best Perl book I have ever read (Programming Perl and all the other ORA Perl books coming in close, but then again I've only read Perl books by ORA so Ihave to broaden my horizons), but it is a first printing of it. It has a lot of major errors. I highly reccomend that you visit the author's errata page [mit.edu] before reading it and fix at least all of the major errors (there are a few). The author's errata page is more complete and will be updated as errors are found more than I would expect the ORA site is, so I reccomend that you use his site instead of ORA's site for errata concerning this book. Don't make the list of errata scare you though it is a great read and I myself am halfway through reading it in full for the third time.

    If you think you know what the hell is going on you're probably full of shit.
  • The emphasis there should be on "I". For group projects, this freedom can become a big problem as every programmer may adopt completely different (and maybe incompatible) ways of doing things. At the very least, you need to do a lot more work defining and enforcing coding standards than in more constrained languages.

    "TIMTOWTDI" may be fun and even productive for individual programming, but there are lots of different contexts in which programming happens, and, not surprisingly, they all have different tools and languages.

  • NP-completeness explained (Score:5)

    by raph ( 3148 ) on Wednesday December 08, 1999 @08:52AM (#1475847) Homepage
    Ok, this comment has a lot of inaccuracies. Let me try to clarify.

    NP stands for "nondeterministic polynomial", and is probably most easily understood as the class of problems for which the solution can be verified in polynomial time. It includes P, the class of problems that can be solved in polynomial time.

    A nice example of a problem that is in NP but not known to be in P is satisfiability. This problem is given as a list of predicates of the form (x1 or x2 or not x3). The problem is finding a set of xi such that all of the predicates are satisfied.

    So, it should be obvious that you can verify a solution in polynomial time - just start with the values of xi and check that all the predicates turn out true. However, there is no known general technique for solving this problem than enumerating all the possibilities, which takes exponential time.

    NP-completeness takes this idea one step further. It is a large an interesting class of problems that are basically equivalent in difficulty. If you solve one, you've solved them all. Thus, if a problem is NP-complete, there's no known efficient algorithm.

    The way people analyze NP completeness is do define reductions, ie show how instances of one problem can be reduced into instances of another NP-complete problem, and vice versa. Maybe this takes "highly advanced skills," but it's actually fairly routine for algorithmicists.

    The class of NP-complete problems includes the travelling salesman problem, the Hamiltonian path problem, the knapsack problem, determining collisions of 3D objects, and many others.

    NP-hardness is when you can reduce an NP-complete problem into the NP-hard problem, but not necessarily vice versa. Many integer optimization problems are NP-hard.

    Factoring is clearly NP, but is not known to be NP-hard. It's entirely plausible that someone (Arjen Lenstra, for example) will come up with a polynomial factoring algorithm, but leave the rest
    of the NP pantheon untouched.

    There are some crypto algorithms that are based on NP-completeness, but NP-completeness is not in and of itself enough for strong crypto. Even if the problem is hard in general, a specific instance may be easy to solve. Unless you can prove that this never happens, you're hosed. IBM has done some excellent work in this direction with randomized self-reductions for their lattice-based crypto algorithm.

    Complexity theory is one of the most beautiful areas in computer science, and NP-completeness is one of the most striking results, as it illuminates a fundamental unity across many seemingly disparate subfields of computer science. It is indeed a shame that this book skimps on its coverage of NP-completeness.
  • Call me a sentimental fogie, but the first programming laguage I ever learned was Scheme. (for those who don't know, Scheme is a LISP derivative) Scheme is syntactically simpler than most programming languages, and lends itself easily to developing a working knowledge of theoretical computer science (i.e. data structures and abstraction, recursion, and algorithm fundamentals). The "bible" of Scheme is called Structure and Interpretation of Computer Programs, by Harold Abelson, Gerald Jay Sussman, and Julie Sussman.

    The reason that Scheme is not as well known as a programming language is that it is sort of the "learning beater car" of programming languages. Scheme's main utility advocates are in AI and its sub-disciplines, so commercial applications will not be written in Scheme. There is no great market for Scheme programmers, but there is a market for programmers who can understand the fundamentals behind great programming. I think that this book especially lends itself to the beginning programmer- and for web support of all kinds the Scheme Repository [indiana.edu] of Indiana University is rivalled only by the Schem Underground [mit.edu] at MIT.

    Good luck in your programming endeavors!

  • > ML: is there an actual language named ML, or is this shorthand for machine language?

    There is. Or rather it stands for a family of languages, the most proeminent ones being Standard ML (SML) and Objective Caml (O'Caml). ML itself is a shorthand for "Meta Language" and was designed in the 70's as an implementation language for a theorem prover at the university of Edimburgh.

    ML languages are functional, strongly typed, have type inference, are mostly interpreted but can be compiled to native code. The syntax is very expressive. They also support imperative programming, and object-oriented programming in O'Caml case.

    And to be a little more on-topic, they are very well-suited to study algorithms (and actually used to teach classes), though the functional semantics can be mind-boggling to those used to imperative languages.

    Xavier
  • No, I don't have a reference handy. But I could swear we did this in a senior level computation theory class about 4 years ago.

    I'm not angling to repeat the nightmares that were my attempts to reduce problems to other NP-complete problems, but it seems pretty obvious that PF is in NP. I can definitely verify a solution in polynomial time. All that would remain is to show that the number of primes increases at the same rate as the number of possible solutions to a SAT problem. Now that I think about it, I don't think the number of primes grows exponentially, so maybe PF isn't NP-complete. Huh.
    ---

  • Re:GO TO SCHOOL!!! (Score:1)

    by Anonymous Coward
    I resent your telling me to go to school just to program. It's a waste. High school is plenty.
  • I hate to say this, but I hate the CRL book. I really expected it to be a lot better than it was. Just this morning I told someone that if you halved the content and put in more English it would be a vastly better volume. I would also like to see C instead of pseudocode, but I can understand why pseudocode.

    Also, the book is not the expensive, I think I only paid $55. And for a book of its size and content, it is a very attractive price.
  • Okay, I know that this is probably a catch 22 question, but what do you want to program for?
    There are plenty of amazingly well written books on the subject.
    Personally I guess I would suggest trying to pick up a Kernigan (Programming C), Any of the O'Reilly 'Learning' books, and if you feel adventurous you might even try Knuth's Art of Computer Programming series.
    If you've got a clear idea of what you would like to learn though the best thing to do would be to go to the book store and just start flipping through books and see what you like.

    Good luck!

  • I even said that Perl is really easy to use, that you can get useful things done right away while reading Learning Perl, and that I've written a lot more code with it than any other programming language. Why would you think I'd want to ban it? (Yeah, I know you were exaggerating, but still.)

    The guy to whom I replied said that he was looking to learn programming, not to learn Perl, or had some specific thing that he needed to get done. I just don't think that learning Perl is very helpful if you're looking to learn programming in general or plan to use other languages later. I definitely wasn't attacking Perl.

    As to the other person who replied to me: The Perl Cookbook is great (I own the Perl CD Bookshelf which has it and I have the dead-tree version at work), but I wouldn't recommend it to someone who, like the person whose post I answered, has never done any programming before. I'd suggest checking out Learning Perl first so that he isn't totally lost by things like all those expletives in the language ($@_!#%) ;-).

    Cheers,
    ZicoKnows@hotmail.com

  • The best introductory Java book I've seen is Beginning Java from Wrox Press (can't remember the author). Don't know how good it would be for a rank newbie, but every other Java book I've seen has been even more newbie-unfriendly. Bruce Eckel's Thinking in Java [eckelobjects.com] might be better for an experienced programmer trying to pick up a new language, but might cause a porr non-programmer's head to explode.
  • The more programming languages you learn, the better off you are. Good for you to learn Python. Everyone should.

    The older I get, the further away I get from this attitude. Currently, my feeling is the fewer things you need to learn to get the job done, the better off you are. I know Perl pretty well (if you already know Unix, Perl comes easy), the documentation for it is excellent (arguably the best of any language, ever), and there's a huge base of written code on CPAN for me to draw on. I'm not going to learn Python because some math geeks think it's more elegant. In fact, I will learn another scripting language if, and only if, someone holds a gun to my head. I will be perfectly happy if I can spend the rest of my life learning in more depth the things that I already know something about (on my personal shortlist is perl, SQL, C++ and elisp).

    For you newbies, I'd suggest that you consider the fact that you're probably not going to be able to get by without learning some Perl, but you *can* probably get by without learning any Python. Perl has a reputation for being difficult to learn in some circles, but I think that this is grossly exaggerated. There's a school of thought that says that languages should be stripped to their essentials, and have nothing in them but the absolute core set of things that they need... but in practice this never works, they always accumulate complications, and Perl has always just ignored that "elegance through oversimplification" philosophy. I'm actually beginning to think that Larry Wall is right about Perl being more "language-like" than most computer languages... it appeals to a different kind of head, with a different style of thinking.

    In many ways, I think the book Mastering Algorithms with Perl is a blow in this war with the academic CS geeks. It *assumes* that you're someone who's learned Perl on the street without any formal CS background, and lets you in on the secrets using what may be the "lingua franca" of the software world: Perl.


  • Yup. I have a secret - I put the forks in my pocket while I think. :-)

    Pisses off the other philosophers, but what do I care?
  • Really? That surprises me. Do you just think it's unnecessarily mathematically involved?

    Granted, the course I took was both a CS and a math course, and if you don't care about the math you'll end up skimming some of the text. It is fairly formal and academic.
  • As someone who has taught introductory programming, my FIRST recommendation is STAY AWAY FROM Perl as a first language, unless that's the only thing you ever want to learn.


    I'm not knocking Perl as a language - I use it all the time - but it's not suitable as an introduction to programming. I've not used Python, but the reasons that other posters have put forward suggest to me that it may be appropriate.

    At our school we teach the functional language
    Haskell in our first course, then C. Java, C++, and even a little Prolog and Assembler are taught along the way through. Haskell is a great teaching language, partly because it knocks the smart-alecs who know C++ before they get in to university back on their arse, partly because it's a great introduction to some pretty clever concepts like strong typing and recursion.
    However, for someone having a taste of programming to see if they like it, it's probably a little intimidating and not easy to immediately write useful programs.

  • John came to talk to the October meeting of the Toronto Perl Mongers [willcam.com], and gave a short talk on his experiences writing the book.

    He was a really nice guy, and he told quite a few interesting stories.

  • But, these all refer to classes of computable problems.

    The halting problem is the prototypical "not computable" problem. Thus, it is not in NP-hard


    Nope. NP-hard and NP-complete refer to decision problems.

    The halting problem is a decision problem, and it's at least as hard as satisfiability. Therefore, it is NP-hard.
  • Call me old fashioned, but I think that C is probably one of the best languages to learn first because the language itself is very simple unlike perl, it forces you to think about memory management (which IMO is a good thing, if only to gain an understanding of how it works). Books that I have found good for learning are "the C Programming Language" by Kernighan and Ritchie, and "Practical C Programming" from O'Reilly.
  • I believe that the number of primes grows logarithmically [utm.edu]. Fortunately, I found a link, too! :)

    ---
    pb Reply or e-mail rather than vaguely moderate [152.7.41.11].

  • (if you already know Unix, Perl comes easy)

    I think you mean 'C'. If you know Unix shell programming, Tcl comes easy. Perl remains excessively incoherent.

    For you newbies, I'd suggest that you consider the fact that you're probably not going to be able to get by without learning some Perl,

    Care to elaborate? What can you do in Perl that you cannot do in Python? Apart from

    1. Overuse the characters %&@$ etc. that you hardly need to touch in Python, and
    2. Pretend the tacked-on hack of an OO system is useful, as opposed to a real OO language like Python.

    It *assumes* that you're someone who's learned Perl on the street without any formal CS background, and lets you in on the secrets using what may be the "lingua franca" of the software world: Perl.

    I can probably find someone who feels the same about Visual Basic. Doesn't make it any more true. Perl has a head start: But so did Cobol.

    I wish Python had been around when I learned Perl - I wouldn't have chosen as wrongly.

  • Java is a TERRIBLE beginner language. TERRIBLE!

    Yes, but that's just because any language derived from C is a terrible beginner language.

  • When I started learning perl, I figured a good way to do it would be to a) read the camel, b) look at lots of code. Matt's stuff is all over the place so I started reading it. It took me ages to weed out the bad habits I acquired.

    Except as an excercise in correcting other people's mistakes, don't touch the stuff.

  • Yes. I also think the entire book is over kill for a semester course. We got through some 10 out of the 40 odd chapters :) If you are interested in discussing the book at greater length, feel free to email me at howardjp@wam.umd.edu.
  • Second, I'd like to ask why a good, pseudo-code, readable language *isn't* more popular nowadays.

    It is -- Python is actually quite popular. It's nowhere near as popular as Perl, but its community is well past critical mass (so to speak), and is also much, much nicer.

    -Billy
  • If you'd like an online tutorial, you might want to check out The CGI Resource Index, which is made by the same guy as Matt's Script Archive.

    That's worse than looking at Microsoft on how to design Operating Systems - at least Windows works for certain values of "work", which is more that you can say from Matts scripts. There are daily complaints in comp.lang.perl.misc about people having problems with his scripts.

    -- Abigail

  • No, it's not the best code in the world. But it's a nice starting point.

    No, it's not. It's bad code, and because it's bad code, it's a very bad starting point.

    -- Abigail

  • I think you mean 'C'. If you know Unix shell programming, Tcl comes easy. Perl remains excessively incoherent.

    I've never been much of a C programmer, and have more experience with shell programming. Yet, Perl was quite easy for me, and I might say, I can code a thing or two in Perl.

    What can you do in Perl that you cannot do in Python?

    Nothing of course. Just like you cannot do anything in Python you can't do in Perl. Or VB for that matter - they're all Turing equivalent.

    • Overuse the characters %&@$ etc. that you hardly need to touch in Python, and
    • Pretend the tacked-on hack of an OO system is useful, as opposed to a real OO language like Python.

    But you need far less parens in Perl, and because of the use of $ and friends, you can interpolate variables in strings, leading to less punctuation characters. In the end, it evens out. (Now, why doesn't anyone complain about English? All those comma's, periods, question marks, parens, etc, etc?)

    As for the OO system in Perl, it sucks. But then, it's copied from Pythons.

    There's one thing that makes it hard to learn Python, and that are the extremely cryptic error messages. Specially compared to Perls.

    Now, why does anything remotely Perl related on Slashdot always ends up in Perl bashing? The topic here is the book "Mastering Algorithms in Perl", not "my favourite pet language is Python and Perl sucks".

    -- Abigail

  • Call me old fashioned, but I think that C is probably one of the best languages to learn first because the language itself is very simple unlike perl, it forces you to think about memory management (which IMO is a good thing, if only to gain an understanding of how it works).

    It's lack of memory management is one of the reasons C sucks as a first language. It makes the beginning programmer get lost in details better left to the computer; taking away his/her time from focussing on the problem. Perl as a first language sucks too, but for different reasons. Python, Java, LPC, Ada or something from the ML family are much more suitable.

    -- Abigail

  • Problem A is NP-complete if there are no problems in the set NP that are harder than A.

    You're all wrong.

    The set of NP problems consists of a set of problems in NP which are all P reducable to each other. Hence, if one problem of the set of NP-complete problems is found to be in P, they all are. NP-hard problems are "harder". One can P reduce an NP-complete problem to an NP-hard problem, but not the other way around. Hence, discovering that NP-complete == P doesn't solve the P ?= NP question; as it doesn't prove that the NP-hard problems are in P.

    The classes *I* took used "NP-complete", "NP-hard" and "hard for NP" synonymously.

    You should ask your money back.

    -- Abigail

  • When you can buy the book, plus several others, on a single CD!

    Dr. Dobbs has it as part of their Algorithms CD. It has full text searching, too!

    Not only that, but the price is lower than you would normally pay for the CRS book alone.

    My only complaints are:

    - the interface was a bit weird and buggy
    - you can only browse it using the supplied Windows app (I think; I lent it to someone and never got it back).

    Graham
  • NP means "polynomial-time verifier".
    NP-hard means "reduce to NP in polynomial-time".
    NP-complete means "NP and NP-hard".

    That would mean that NP-hard == N-complete, yet you write:

    NP-complete and NP-hard are not synonymous.

    -- Abigail

  • The halting problem is a decision problem, and it's at least as hard as satisfiability. Therefore, it is NP-hard.

    No, it's not. The halting problem isn't computable.

    -- Abigail

  • The CLR text is required for my algorithms course next term.

    Good for you. I've teached grad students from this book, and it's a very good textbook on algorithms and datastructures. I need to get myself a new copy as well - mine is falling apart.

    -- Abigail

  • Doesn't Larry Wall (creator of Perl) work at O'Reilly now? If I'm remembering correctly, why is it that we haven't seen any Perl books written by him except the Camel book?

    Perhaps because he isn't employed as an author?

    -- Abigail

  • Wow... I'm still sad about his death. I never heard how he ( Richard Stevens ) passed away. Does anybody know what the cause of death was?
  • Being one of the technical reviewers of the book, I wish I could recommend this book. However, I don't think this books is worth its money. The problem I see with this book is that it's trying to be 3 things at once: an introduction to algorithms, a manual of some modules found on CPAN, and a bag of tricks. By trying so, it failed on all accounts.

    Some parts of the book don't contain more than "if you want to do `foo', just call the function (or method) called `foo' in this package". I really, really don't need a book to state what I can find easily in a manual as well.

    In the parts they do discuss algorithms, they often get side-tracked, by either explaining language features, or showing a trick that saves 0.5% of your execution time. The important things get burried in the details. It has been argued that having "real code" and not pseudo-code is a feature. In my opinion, this books makes an excellent argument in favour of pseudo-code. Pseudo code doesn't have to bother with language details, and people writing pseudo-code have to waste time wondering whether an alternative construct saves 1% of time. An algorithms book should focus on algorithms, not on the language.

    If you want a bag of tricks, get Effective Perl Programming, if you want a bag of useful code snippets, get The Perl Cookbook, if you want to know modules, read their man pages, and if you want to learn algorithms, get a real algorithms book, like Cormen, Leierson, Rivest, Knuth's The Art of Computer Programming, or something from Wirth or Mehlhorn.

    -- Abigail

  • and is also much, much nicer.

    My apologies. That was VERY unclear, and is not what I meant to say.

    I meant to say that the Python community is very nice. I've mingled very little with the Perl community, so I have no qualification for calling them meanies ;-), and I did not mean to do so.

    However, I have mingled with the Python community, and there are some great guys there.

    -Billy
  • Back when Perl had has few users as Python, everyone was nice there, too.

    I apologise for the comparative -- I didn't mean it. I was just saying that the Python community is helpful.

    I'm rather frightened by the fact that my slip of the pen was correct. I'm sorry about that.

    In both cases, popularity destroyed that community.

    No offence meant, but look at the size of the Python community. It's by no means as huge as Perl's, but it still gets a lot of newbies. Somehow they all wind up contributing to the community.

    Perhaps Perl's and C++'s problems are that they're not easy languages to learn. Perhaps the problem IS the sheer size of the crowd. We'll see. You do have to notice, though, that Perl and C++ are not seperate cases; they're both very complex languages with highly non-orthogonal syntax.

    -Billy
  • I've heard that. I've never believed it. I know only one Unix system programmer, and he HATES Perl.

    Perhaps that's true for system administrators, though. Before Perl, they had to use AWK, grep, ed, and many other awkward tools. Perl slaps all those together MUCH better than the Unix command line could.

    Even there, though, there's no reason for a programmer to prefer Perl to Python (unless they only know Perl, of course). Their programming abilities are about equivalent, except that Perl throws a lot of sysadmin stuff your way whether you ask for it or not.

    -Billy

  • Algorithm Book (Score:3)

    by banfield ( 68678 ) on Wednesday December 08, 1999 @05:25PM (#1475928)
    If it is an algorithm book you are looking for, I highly recommend
    • Computer Algorithms: Introduction to Design and Analysis 3rd Ed
    by Baase and Gelder. I just took my intro to algo course in which this was used as a text; it is very much readable and the examples really do illustrate the principles they claim to. It spans every thing from a base level introduction to NP-complete.

  • Oops. I had the Dylan programming language mixed up with some other Apple product code-named "Sagan". Carl Sagan sued Apple over the name, and lost. Apple changed the development name anyway, to "BHA". When word got out that it stood for "Butt-Head Astronomer", Carl sued again, and lost again. Later, when Apple began work on its Dylan (dynamic language) programming language, Bob Dylan sued. I don't know how (or if) the suit was resolved, but I don't think Apple has had to rename it to "BHM". Yet.
  • If you'd like an online tutorial, you might want to check out The CGI Resource Index, which is made by the same guy as Matt's Script Archive. Between the tutorials on the Resource Index, looking at the source of Matt's script, and reading the O'Reilly books, you can learn just about anything you want to know about Perl.

    Others have responded that Matt's scripts aren't really a good source of information on how to program perl idiomatically, or maybe even correctly. :-)

    But to add something to this thread, I'd like to point out that you really, truly can learn much more about Perl than you'd ever get from Matt's Script Archive by going to the Perl home page at www.perl.com [perl.com]

    After you've spent a couple of weeks digesting that, it is possible that you would want to know even more, so you can go to Tom Christiansen's Far More Than Everything You've Ever Wanted to Know About... [perl.com] web page, if you haven't already. Oh yeah, and you can buy O'Reilly books, too. :-)

  • I'm surprised you made a claim like this without backing it up...

    R is definitely for Rivest. Check the "What is RSA? [rsasecurity.com]" section of RSA's cryptography FAQ. I quote directly:

    RSA is a public-key cryptosystem that offers both encryption and digital signatures (authentication). Ron Rivest, Adi Shamir, and Leonard Adleman developed RSA in 1977 [RSA78]; RSA stands for the first letter in each of its inventors' last names.
  • it appeals to a different kind of head, with a different style of thinking.

    That's probably the biggest truth in this whole thread. Perl and Python just appeal to different people. Sure, you can write structured code in Perl, but if that's what you want to do, you'll probably use Python because it was designed with that in mind. Likewise, you can make efforts towards writing code that follows your own thought process in Python, but it's not going to be nearly as easy.

    And a really good programmer with a style somewhere in between could write code that was just as good in both languages (it might run faster in Perl as a result of the more mature interpreter). They just appeal to different mindsets.

    I suspect one of the greatest problems Python advocates have (and I have to count myself in that group) is that since Perl came out first and became very popular, a lot of people to whom Perl's way of doing things doesn't particularly appeal and still programming in it anyway because they learned it first. Slightly more valid is the argument that Perl is better because CPAN exists---yeah, that's good, but it's not really talking about the language and is partly a benefit of age. As a result, Python advocates exagerrate the flaws of Perl and the pros of Python. It's a lot like Free Unices vs. the rest of the world. You know there are people out there who would be better off on your side---certainly not all---but they're stuck over there and unless you scream your head off they won't look at you (not that I advocate this procedure).

    One final comment is that I think that the spirit behind the creation of the language is also something to be considered. Both are certainly general purpose, but Perl has had a lot of influence from the need to process text, hence a lot of choices that are unpopular with people who don't want to do this. Its syntax reflects this. Python has a lot of influence from the desire to make it easy for nonprogrammers to learn, hence a lot of things (whitespace) that others don't like. But Guido is doing all he can to make sure Python 2.0 (whenever it comes out!) will be newbie-friendly, and I'm sure Perl will never lose its roots either.
  • In http://slashdot.org/comments.pl?sid=99/12/08/10412 49&cid=224 [slashdot.org], zarkov@netnitco.net [mailto] wrote:
    read(STDIN, $bfr, $ENV{'CONTENT_LENGTH'});
    foreach (split(/&/,$bfr)) {
    $kv = [split(/=/,$_)];
    foreach (0...1) {
    $kv->[$_] =~ tr/+/ /;
    $kv->[$_] =~ s/%([0-9a-fA-F][0-9a-fA-F]) /pack("C", hex($1))/eg;
    }
    $form->[0]{$kv->[0]} = $kv->[1];
    }
    foreach (split(/&/,$ENV{'QUERY_STRING'}) {
    $kv = [split(/=/,$_)];
    foreach (0...1) {
    $kv->[$_] =~ tr/+/ /;
    $kv->[$_] =~ s/%([0-9a-fA-F][0-9a-fA-F]) /pack("C", hex($1))/eg;
    }
    $form->[1]{$kv->[0]} = $kv->[1];
    }
    Here's what you did that was dubious (nits) or wrong (bugs):
    • You have a bug in your read: you failed to check the return value of your system call. That's a supermajor bug, an automatic disqualification.

    • You have a bug in your split. You need to supply a third argument of 2, or else you fail on URLs such as http://somewhere/cgi-bin/dumpreq?this=good=stuff&t hat=bad=stuff

    • Are you aware that the new CGI spec from W3C deprecates the use of & and insists on semicolon? In fact, the W3C validator now insists on semicolons. Your split doesn't know better. This could easily be a bug soon enough.

    • You didn't test for whether you had a HEAD request and react accordingly. That means spiders will trigger your program's full effects. That's a bug.

    • Your code can only handle trivial forms. It not only screws up on file uploads, it has no contingency for a name that occurs more than once, as occurs in related groups of related widgets--thing likes checkbox groups, select widgets, or multipart hidden data. This comes up all time times, as in http://somewhere/cgi-bin/pickit?cheese=swiss&chees e=cheddar&bread=rye.

      Without seeing the code for those important parts, I can't say for sure, but given the rest of the non-industrial strength code, one can easily imagine the worst.

    • You didn't test for whether you had a GET or a POST request. You just forge ahead.

    • You have duplicate code. That's a very bad. It means you might get an update problem.

    • You didn't guard against a denial-of-service attack through too much data for your memory to hold coming from a huge POST.

    • You never declared any of your variables. Is this code use strict and use warnings clean?

    • Your use a magic numbers, 0 and 1, is confusing. Sometimes you use them for a key versus a value; other times you use them for the form data from STDIN versus the form data from the environment.

    • You have duplicate code. That's a very bad. It means you might get an update problem. (Why yes, Virginia, this is a repeat. So is yours. See the problem? :-)

    • This code:

      $kv = [split(/=/,$_)];
      foreach (0...1) {
      $kv->[$_] =~ tr/+/ /;
      $kv->[$_] =~ s/%([0-9a-fA-F][0-9a-fA-F])/pack("C", hex($1) )/eg;
      }
      This very nonperlishly awkward. It doesn't have to be this bad. Why aren't you using the foreach better?

      That would read better like this:

      foreach (@$kv) { tr/+/ /;
      s/%([0-9a-fA-F][0-9a-fA-F])/pack("C", hex($1))/eg; }
      Because otherwise you have too much needlessly duplicated information.

      Better yet, you should just split into my ($key, $value) and loop across those in the same way. The anonymous array just seems to hurt legibility.

    That should be far more than enough nits and gnats to keep you thinking for a while.

    As I said, I write CGI programs all day long. That's how I make a living. And I've never had a problem with this.
    Absence of evidence does not imply evidence of absence.

    Here's my suggestion: read the CGI.pm source very, very carefully. There's a lot to learn. Good luck. Hopefully, you'll repent of your hackish ways that help give Perl a bad name by spreading bad CGI code around the world.

    And since you're advocating we not show people how to do something because it might be "complicated", do you suppose we ought just to close the source of Linux?
    I shan't be tilting at any straw windmills.

    I shall, however be patiently awaiting your public apology and contrition.

  • Both here:
    You have a bug in your split....

    This code is not all-purpose. It is about the simplest parsing I would put in the beginning of one program. If I know the form's going to hand me something funky, I'll handle it. Since I write the code for the form, I can do that.

    and here:
    You didn't guard against a denial-of-service attack through too much data...

    Again, a simple parser for a form I know will be simple. I'd write something better if I had something bigger.

    In both these cases, you have committed the same incredibly stupid blunder. The root cause is that you seem to think it reasonable to expect to get back from the form only that data which you yourself provided in it. Nothing could be further from the truth. Nothing! And this misunderstanding is the cause of innumerable bugs and security violations. You the programmer do not control the form. Not one darned bit of it. One is at the complete mercy of the user. You obviously are relying upon the user's good will. That's a fatal mistake!

    As for the matters of strict, your disdain for robust coding should scare the hell out of any employer or co-worker. And symbolic reference are 99% of the time used because someone had no clue how to build a proper data structure.

    You have a long ways to go yet in becoming a competent software engineer. And you don't seem to be on that path right now.

    There's much more to CGI than you seem to realize. For example, do you even understand the critical semantic difference between GET and POST? They're hardly interchangeable.

    If I should ever write a book on low-level CGI internals (which I hope to avoid), I shall be sure to include all this. Meanwhile, you should abandon your attempts at wheel re-implementation, because you're doing it in a dangerously cavalier and often completely wrong fashion. I stand by my work: the module is going to get things right that 98% of the script kiddies will never even understand. So use it.

  • You the programmer do not control the form.

    Actually, the web developers are about five feet away from me, so I know exactly what the forms look like. No, wait. Actually, most of my CGI scripts create the form themselves. I do control the form.

    You are deeply self-deceived. I can hack on your form till the cows come home, and by the time you see its results, they'll be nothing like what you think they can possibly be. And you'll be screwed. I can't wait to see your real form code, one that does files and cookies and selects, etc. Strike that. I'm sure it's more of the same.

    Pay attention. You are dangerous. This is the horribly stupid perl code that people trash the language about, and you're part of the cause!

  • The Perl books cover, surprisingly enough, Perl. Are you asking for a good book to learn about HTTP, CGI, and HTML from?
  • Why in the world would you expect to find the intricate details of, say, SQL, in a book that says it's going to teach you Perl? It's no different here. The Perl books also don't teach about various tricky TCP/IP issues, either, even though Perl allows you to create sockets.

    This is part of being a glue language. We glue to everything. We can only teach you how to attach the glue. You need to understand what you're gluing to.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close