Slashdot Mirror
Beginning Perl, 2nd Ed.
Beginning Perl is a conversational-style tutorial that will guide you through your first steps into the Perl world and even a little beyond. The first two-thirds of the book cover the basics of programming with Perl including data types, flow control and IO.
The casual flow through here will help prevent fledgling programmers from suffering information overload. The authors handle the need to provide enough information, though, by revisiting topics repeatedly, going a little deeper each time. Unfortunately, this hurts the volume's use as a reference, as it's quite a challenge to go right to something. (Example: The built-in join() is covered in the chapter on "Regular Expressions," which is certainly not the first place I would look.) The index is decent and can guide you through these problems, if you remember to start there.
In keeping with the book's tone, side-trips and diversions are fairly common. Early on, these center around topics like "How to Think Like a Programmer" and "What Exactly is a Binary Number." I mention this because I know some readers appreciate this level of detail, while the interruptions annoy others. I found many of the discussions insightful, but it did occasionally get carried away with itself. (Example: There is a whole page on Perl's versioning scheme that goes so far as to discuss what a "patch pumpkin" is. Interesting or not, it seems out of place in here.)
One of Beginning Perl's real strengths is its constant encouragement of the programmer in training to experiment as a means of further learning. The text often suggests things to try and each chapter ends with a set of exercises. Answers to exercises are provided in an appendix. The only way to really learn programming is to program, so I was glad to see this push in the right direction.
The final third of the book digs a little deeper, examining references, object oriented programming, the CGI protocol and interfacing with an external database. Make no mistake, these are only introductions, but they are a nice addition to a beginner's book that will have you doing a little practical programming quickly. The "Introduction to CGI" and "Perl and DBI" (database interface) chapters really stood out here.
Two chapters were rocky enough to mention. "Regular Expressions" does not handle its content well, I'm afraid. You spend most of the chapter seeing if a pattern matched, but not what it matched. That's an important distinction for me. Learning regular expressions can be tricky and you need to see exactly what's going on. This issue is finally address near the end of the chapter, but it needed to come sooner. True beginners will likely need considerable experimentation of another book to really catch on to regular expressions.
"Object-Oriented Perl" was also problematic. Frankly the chapter bit off more than it could chew and doesn't really manage to teach much because of it. (Example: Inheritance isn't even addressed.) I think a better use of the chapter would have been to outline only the use of objects as a setup for later chapters, leaving the creation of objects to a volume that could spare the space to do the topic justice. Again, beginners will definitely need more material to be comfortable with object oriented programming.
To summarize, if you've wanted to learn Perl but haven't yet taken the plunge, you could do a lot worse than to start with this book. It's a casual tour of the basics with a few teasers for further study opportunities.
You can purchase Beginning Perl, 2nd Ed. from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page.
I think the reason perl was the easiest language for me to grasp from the get-go was because variables were just that
Perl just seems to connect better with me, in that any given variable can be any given thing. A number. A string. An array. A hash. A reference to any of these things. It can even be an object, or subroutine. All things are mutable and transient.
Now if this makes perl a good starting language or not I don't know -- maybe it makes learning other languages harder, because you always with that the other language was more like perl.
At least I do.
d. Taylor Singletary,
reality technician techra.el
HTML? Isn't that a markup language, and not a programming language? How does HTML teach you any programming concepts?
... which was a revelation for me, and for many others. In my case, at least, cobbling together my first pointless, amateurish "this is my homepage hope you like it" Web page led, slowly but quite directly, to a programming career. And I don't think I'm unique in this.
Actually, HTML is a very good thing for people who have never done any programming in their lives to learn, because it does teach what I consider not only a "programming language concept," but the very idea of programming: giving the computer a series of instructions which produce an output noticeably different from the input. This is fundamentally different from the way most people use computers, in which output immediately follows input, and one is obviously a product of the other.
No, HTML isn't Turing-complete, and no, learning it won't teach you any of the theoretical basis of programming. But it will teach you how to write something that can meaningfully be called "code," and let you see the results of your work
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
Perl's a great beginner's language until you go beyond single-dimensional arrays.
l ).
@b=((0.8,0.9,1),2,3,4);
$b[0] => 0.8
because it flattened out the list for some reason.
Gotta love those at-signs and dollar-signs.
You have to say
@b = ([(0.8, 0.9, 1)], 2, 3, 4);
So the inner list needs brackets.
Why didn't the outer list need brackets?
Then you can say $b[0] and get ARRAY(0xb75eb0).
Well, maybe @b[0] will work, no that gives
ARRAY(0xb75eb0) also.
What you have to say is @($b[0]). Of course, how could I have missed that??
(The preceding cribbed from http://www.garshol.priv.no/download/text/perl.htm
As to compiling, beginner's aren't developers. Perl's ability to chew through bad code makes it *more* educational because you get to see what the bad code did. It also makes it a lot less frustrating when users don't have to pass syntax checks before they even try to run their code. (Developers, on the other hand, can test syntax with commandline switches.)
In Perl, a number is a string and a string is a number. How the value contained in a scalar is interperated is a context matter. So to say Perl makes it hard to tell what is a number and what is a string, is to misunderstand what a perl scalar is.
And as far as security goes, perl doesn't crash its own stack nor will it munge data of nearby variables due to a miscast. I would never trust a newbie coder to write secure code, but then, if I did, it had sure as hell be in a higher level language to avoid buffer overflows.
I like C, too, and I do think using it leads to a better understanding of the actual data manipluations a program performs. But the question is in the merits of teaching programming concepts, and that understanding is only one concept among many. C can't be beat for speed. But when you are learning how to program from scratch, speed is of no concern.
Someone had to do it.
What really pisses me off is that you were modded BELOW this obvious troll.
And for the record OOP in Perl is NOT bolted on, it is just that Perl is so damn flexable that you can do OOP in man ways. This is a VAST difference.. You can get into the meat of OOP with Perl and not have to depend on what someone's idea of OOP is.