Beginning Perl, 2nd Ed. 141
| Beginning Perl (Second Edition) | |
| author | James Lee with Simon Cozens and Peter Wainwright |
| pages | 429 |
| publisher | Apress |
| rating | 7 |
| reviewer | James Edward Gray II |
| ISBN | 159059391X |
| summary | A Solid First Perl Tutorial. |
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.
Re:Hold Crap! (Score:3, Interesting)
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.
Re:Hold Crap! (Score:5, Interesting)
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
Re:Hold Crap! (Score:2, Interesting)
@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
Re:Hold Crap! (Score:3, Interesting)
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.
Re:sorry, I hate perl. (Score:2, Interesting)
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.
Re:Hold Crap! (Score:1, Interesting)
You're kidding, right? Haskell doesn't have the support base perl does. It doesn't have the documentation that perl does. I found it horribly confusing when I last sank hours of my life into it, and I've got a degree in mathematics, and have been programming professionally since 1991.
Haskell sounded straightforward enough, but looks can be decieving. After writing my first program without a hitch, I spent several hours trying to code a simple proof-of-concept Sieve of Erostrathenes in Haskell, and kept getting a bizare "Unification would lead to Infinite Type" error.
There was no documentation on what Infinite Types were, or why they were a problem. Nothing in the documentation explained what set was being unified with what other set, nor why.
The function definiton I used was mathematically correct, and should have worked from a strictly mathematical basis. Haskell was unable to understand it correctly, and unable to tell me what went wrong in a reasonable way. I found this very, very frustrating.
The error appeared to be "haskell-speak" for some sort of error caused by taking the floor of a the square root of a number in a function that returned an integer. I worried that haskell wasn't able to handle the notion of a function that mapped an integer to an integer, but used as it's definition a real valued computation. This is certainly valid in mathematics.
At the time, the web site promoting Haskell (haskell.org?) had some wierd sort of precursor to a wikki, where anyone who wanted to could add, edit, or overwrite the page. No mention was ever made about whether the page was even backed up, and so I wondered if I should mess with it. All the postings were months, if not years old, so I didn't bother.
The newsgroup referenced wasn't even language specific (comp.languages.functional, rather than comp.languages.functional.haskell). Perhaps the language has matured a bit, but it's no where near as popular as perl.
Haskell, like all functional languages, is based upon the assumption that recursion is a good thing. This assumption is nearly universally false.
Recursive algorithms are complex, and hard to understand and maintain, so much so that an entire branch of mathematics is based on simplifying recurrance relations into a simple, closed form solution. Recursive algorithms must be made none recursive (using tail recursion, if possible) just to make them reasonably efficient.
And is the behavior of something like (3+2) x 4 something that should be clear to a beginner?
When you know that (3+2) is 5, and you know what the repetition operator "x" does, then yes, it's pretty darn clear. Repetition is a simple operation, and even a six year old can understand "do this four time".
But if you're talking about opaqueness of documenation, are terms like "fixity declaration", "non-terminating expression", "lamda abstraction", or "infinite data structure" (*boggle!!!*) really more clear? No. Your "Gentle Introduction to Haskell" is anything but.
Try explaining to a six year old how the infinite type definition of the fibbonacci sequence, using the wierd zip function on different parts of the same infinite string is supposed to work. Tell me if you manage it before the kid is ten.
Haskell is a fun toy language for academics; but perl gets work done. Teaching a beginner haskell is probably a good way to scar them for life.
--
AC
Re:Hold Crap! (Score:1, Interesting)
Chinese teaches more about eastern languages, latin, about western. Both are documented. Haskell wasn't documented. Undocumented languages are bad.
Wow... what were you doing? Sieve in (idiomatic) Haskell:
sieve
sieve [] = []
sieve (h:t) = h : sieve [x| x
I tried something like that: it didn't work. I tried several variations on syntax, nothing seemed to work, and there was no documentation to explain the error. No perlmonks, no perl.org, no thousands of people ready to help and explain. Just an error with no supporting context. No fun.
I suppose I could have tried to read the source code to the interpreter, but for all I knew it was bootstrapped in a native language and mostly written in Haskell.
Really? This is hard to understand (in OCaml)?:
let rec quicksort l =
match l with
[] -> []
| h::t ->
let less,greater = List.partition (fun x -> x
What's rec? What's l? What's h? What's t? What's fun? What's less? What's greater? It's not documented, and I don't want to read up on OCAML to find out that it isn't documented, either.
It's rare that a problem needs to be solved recursively, and the recursive solution is, as you admit, usually more expensive than a more iterative counterpart. Certainly a fibbonnaci series computed in a loop runs faster than the equivalent recursive solution.
Compare that to the iterative solution and the recursive solution is much cleaner and more direct (And yes, I know that this solution is less efficient that an in-place modification version of the algorithm, so spare me that old sawhorse... If you want to do that style, you're perfectly free to). There are entire classes of problems like this that are more naturally solved in a recursive fashion, like working with trees. The definition of a binary tree in Haskell:
Tree manipulation is generally a toy problem. The real world applications that really need trees usually don't have the luxury of an inefficient recursive solution.
What's more, I can write recursive solutions in perl if I really have to. I don't have to worry about the the whole ugly idiom being constantly rammed down my throat, though. I don't use recursion whenever I can avoid it, because I know recursion is confusing to maintenance programmers, (some of whom have never heard of the term) and thus likely to be misunderstood.
When a recursive solution does appear to be a good solution to a common problem, there's usually a highly optimized, non-recursive solution (for efficiency reasons) available as a module already.
In any case, as this discussion proves, Haskell is (or was) not for the novice. It's poorly supported, and relies too heavily on counterintuitive notions like recursion and currying. Novices need more support than Haskell has historically provided. If a professional programmer can't learn it in a small amount of time, do you really want some poor high school kid trying to struggle with it, getting bored, and going home?
Give him LOGO, BASIC, or something easy like that. Only give him a copy of Haskell after he's got a Masters degree in computers, and slip him a copy of the secret documentation, and then maybe he'll get it. Maybe.
Yeah, and there are people that have spent their lives working on the essentially simple concept of factoring integers. Just because a concept has a deep, dark, complex underbelly doesn't mean that it doesn't have a very simple face that is all most people need to see.
We're programmers. We do need to understand that complex underbelly. We often need to prove that we're using exactly the correct function, and that it operates in the smallest amount of time, using the fewest resources possible. That's the dark underbell
Re:Hold Crap! (Score:1, Interesting)
How many non-latin derived languages are made clear by studying latin? Very few, I'd warrant. Latin is important because latin was popular, and so were it's decendants.
Assembly Language (imperitive style) is the latin of programming. Functional programming is, what, esperanto? Useful in some limited circles, but generally unpopular?
rec indicates that the function is recursive (something covered in section 1.1 of the OCaml manual).
Showing off your mastery of OCaml doesn't help anyone understand Haskell better, nor does it advance the principle that Haskell is easy to learn. You're substituting arrogance in one language I don't know for another one, but not explaning much of use.
l, h, t, less, and greater are (prepare for shock and awe) variable names, representing the following values: l is the list being sorted, h is the head of that list, t is the tail of the list, less is the list of values that are less than the head of l and surprisingly greater is the list of values greater than (or equal to) h.
And basic programming in an imperative style requires that you document the names of your variables and choose meaningful names. This is especially helpful when presenting an algorithm in an unfamiliar language. It's the whole functional languages camp lack of documentation that I was protesting, and you didn't help the matter at all with undocumented variables. Again, not helpful to a novice.
If you have trouble telling what a variable is, it's no wonder Haskell befuddled you.
Please don't be so insulting! Of course I know what a variable is: but I can't tell a variable from a function call in an unfamilar language without any context or explanation. I found Haskell to be poorly documented, despite initial hype, (though I note that the situation has since improved), and I really didn't want to have to struggle to learn another new functional language just to discuss Haskell, and how hard I found it to learn.
(Do you look at a function like let f x = x + 3 and ask, "What's x? What's 3?").
In an unfamiliar language? I can guess that the meaning is the one that I assume, but I wouldn't expect that without a proper definition of the rules and operators of the language.
Even in mathematics, x could be a n by n matrix,and 3 an n by n matrix of the number 3. Or something more esoteric.
In a programming language, "+" could be string concatenation, for example, so that "hello" + 3 yields "hello3".
By the way, before you ask, List.partition is a function that partitions a list into two sublists according to some predicate. I'd apologize for it not being documented, but well... it is.
Yes, I'm sure it is, somewhere.
Where is the next obscure functional language that you're planning on discussing documented, so I can try to read ahead, and decipher what you're saying?
And that's hardly a reasonable description of a recursive procedure for counting backwards from n. A better recursive procedure for that is:
Is n 0? If yes then stop, else say n then count backwards from (n-1).
But yeah, I can see how that's real hard to undersand...
Actually, the example I gave was straight from the (minimal) introduction to functional programming I got in school. Which re-enforces my point that functional programming isn't so simple, if I got it wrong.
Gee, that's sweet... you came up with a recursive definition for squaring a number that no one would ever use. You do realize that there's nothing wrong with saying x * x in a functional language don't you?