Slashdot Log In
Elements of Programming with Perl
from the bringing-competition-to-the-mix dept.
| Elements of Programming with Perl | |
| author | Andrew L. Johnson |
| pages | 352 |
| publisher | Manning Publications, 09/1999 |
| rating | 8/10 |
| reviewer | chromatic |
| ISBN | 1884777805 |
| summary | New to programming, and think Perl may be up your alley? Andrew Johnson's excellent Elements of Programming with Perl will teach you both disciplines. |
What's the Purpose?
Hundreds of books teach programming. Dozens of good books teach Perl. Where's a book for someone who wants to learn Perl and programming, at the same time? Thankfully, that's just what Elements of Programming with Perl does.What's Good?
From the start, Johnson's explanations are clean and clear. It's obvious that he's polished his didactic style through years of real world teaching. Also from the start, good programming practices receive due emphasis. Though it's not specifically mentioned until chapter 9, Johnson advocates and demonstrates good program design through a mixture of Donald Knuth's Literate Programming and his own code tangling style (mingling documentation, design notes, and code in a single source file, similar to POD on steroids).The teaching flow is logical and consistent, with chapters dividing the material into logical divisions. By the end of chapter flow, students should be capable of writing moderately complex programs. Subsequent chapters build on that foundation, and most provide a specific example program to tie things together. These programs all have a practical concentration.
On the Perl-specific side, Johnson does not shy away from recommending the copious Perl documentation, CPAN, other books like the Camel, and many other excellent resources. Much of the value of an education is learning where to go for further information.
What's not Great?
Some of Johnson's focus is on mathematical applications, which may distract some readers. Also, this book may not serve as a future reference after you've become more comfortable with the language. Look to the Camel or Perl in a Nutshell for that -- Johnson concentrates on teaching the basics rather than documenting the iotas and tittles of internal Perl functions.Finally, the example program in Chapter 19 may be hairy for novice programmers. Sit down in a very quiet room with a pad of note-paper and your beverage of choice. Consider it a final exam after you're familiar with everything preceding it.
Summary
This is a good introduction to Perl, and a very good introduction to programming in general. Johnson promotes good habits and discipline. Elements may not sit on your shelf as a reference, but it will help you to become an effective programmer. It's a rare book that teaches as well as it informs, so take the plunge and teach yourself Perl and programming.Pick this book up at ThinkGeek.
Table of Contents
- preface
- acknowledgments
- Introductory elements
- Introduction
- Writing code
- Writing programs
- Essential elements
- Data: types and variables
- Control structures
- Simple I/O and text processing
- Functions
- References and aggregate datastructures
- Documentation
- Practical elements
- Regular expressions
- Working with text
- Working with lists
- More I/O
- Using modules
- Debugging
- Advanced elements
- Modular programming
- Algorithms and data structuring
- Object-oriented programming and abstract data structures
- More OOP examples
- What's left?
- appendix A Command line switches
- appendix B Special variables
- appendix C Additional resources
- appendix D Numeric formats
- glossary
- index
This fills a void (Score:5)
Putting aside the (flamebait) arguments that Perl is or is not a good first language, I've seen several people turn to other languages that were less appropriate for their needs (like sysadmins) because of the lack of a good beginner book for Perl
Until now, it's been relatively easy to find books on C, C++, Java, etc for the non-programmer, but Perl has historically been supported by tomes that double as reference manuals, which are not really the best for first-time language instruction
Even the excellent Llama book (Learning Perl) assumes some familiarity with the use of logic and simple programming concepts (like variables). This makes it doubly difficult for a newcomer who wants to harness the text-processing power of Perl but quickly becomes lost in its (admittedly unique) syntax.
I'm glad to see a better entry point to perl for the programming newbie. Maybe now the c.l.p.m. s/n ratio will improve
Re:Books can be over rated (Score:3)
And besides that - theres an awful lot of crud code in the open source world (as there is in the closed source world - but you can't download and learn from that) and I'd hate to see someone learn object oriented techniques from that rather than a good book on the subject.
Re:Python? (Score:3)
If you post a perl program on /., it works. If you post a python program on /., it fails.
Indentation is important for readability, I'd consider a program badly written if it didn't have correct indentatation, but to to make it syntaxly significant is a mistake.
Perl as A First Language Is Scary (Score:3)
IMHO......
From a non system-admin point of view...Perl as a first language is scary.
Thats not to say Perl isn't useful or good, but I would not want to learn about programming by learning Perl as my first language. It has way to many oddities that, if you are interested in programming, don't make the conceptual leap, as it were, to other languages.
For example, in Perl (like most scripting languages) there is a single data type to represent everything from strings to characters to all sorts of numbers. Java/C++/C/Fortran/Basic etc...have different data types (short, long, char, String etc...) for very good reasons.
Having someone learn programming via Perl then have them get "more specific" is harder than going in the reverse direction. I can just imagine all these questions from students..."What do you mean there are specific types of variables? "What is strongly typed?" etc....
Perl also suffers from a syntax problem. Perl has chosen highly compact notation that can scare even the mosty hardy Perl programmer.
I say learn another language so you can see how Perl has generalized the problem space, not the reverse.
With these things in mind, I think the usefullness of this book is not as high as one might think.
Re:Perl as A First Language Is Scary (Score:5)
After reading it I built XML::XPath - an implementation of the XPath spec in perl. It uses lots of classes to do its work, and I feel it's coded very cleanly. And it remains pretty quick (Damian has a discussion of Perl's OO speed issues in the book). If you want to check it out see CPAN. If you don't or can't understand the code I feel I've done something really wrong.
Re:Python? (Score:3)
Can't say I was exactly thrilled with Programming Python. I came into Python already knowing Perl, and just didn't really get anywhere with Programming Python. The continuity just seemed all wrong, out of order, etc. So, I didn't do anything with Python for a couple of years.
On a whim (meaning one of those times when you're walking around a bookstore with a wad of cash burning a hole in your pocket), I decided to pick up Learning Python. Man, am I glad I did. Yeah, there's a lot of really basic programming stuff in there (which makes it an excellent book for complete newbies), but I found it to be a much better introduction to the Python way of doing things, possibly because it was such a fast read. Once I got the basics down, exploring the more advanced stuff just from the online and included docs was a breeze.
Stick with giving Python a try, though. You say you know OOP, but if your knowledge comes from using Perl, I think you'll be happy just how easy OOP is with Python in comparison. I like it enough that it's replaced Perl for me as my favorite quick-n-dirty language -- it just "feels" more correct when I'm using it. And yes, I know the degree to which Perl is a "write-only" language depends on the particular programmer, but it's been my experience every single time that when I've had to work with other people's code, the Python stuff was always easier to jump right into than the Perl stuff.
Anyway, that's just my opinion -- what prompted me to write was that I just purchased "Python and Tkinter Programming" from Manning Publication's website, then came to Slashdot to see a book review featuring a book from the same company. I've never read any of their books before, so am kind of curious.
Cheers,
ZicoKnows@hotmail.com
Fine way to waste your time (Score:3)
The fact is that this doesn't work. The act of seeking relevant information alone gradually takes more time than absorbing the information itself (as any graduate student can tell you). An instructor, whether at the podium of a lecture hall or at the typewriter, putting together a book, does the initial search for you.
If your time is worth nothing (and some people's time is worth nothing), then you can spend time working through library catalogues and search engine results. You can gain sufficient experience and knowledge to figure out a subject on your own, but it takes time. Most people, including myself, don't have that luxury; we could all reinvent the wheel, too, but why?
--
Perl does NOT have just one datatype (Score:4)
There are many reasons why Perl may or may not be a good first language, but this can't be one of them, since it just isn't true. TCL used to be the textbook example of a language that used the string as its representation for everything, but TCL isn't string only anymore, either.
Really, I don't know where people get this idea about Perl, which certainly isn't the most typeful language on the block, but is hardly short of interesting types. I suppose it comes from the fact that Perl does provide a lot of automagical operators and conversions (although the fact that conversions are involved should make it clear that Perl has more than one underlying type).
But one thing I'd like to point out in particular:
Says somebody who clearly hasn't ever had to justify the difference between a short and long to a beginning (or non-)programmer. I would actually argue that the short/long difference is exactly the kind of "people working for the computer" stuff that doesn't belong anywhere near somebody's first exposure to programming.
If you want to teach the importance of types at the same time you teach programming, you would do better to use a language that has a more interesting and flexible type system; one obvious candidate would be Haskell, or it's interpreted cousin Hugs [haskell.org].
What's the best thing about C? (Score:4)
What's the worst thing about Perl? The biggest complaint I hear is that Perl is cryptic; however I think this is bit of a bum rap. It isn't hard to make C programs that rival the worst Perl examples. Also, I've found some largish Perl systems that were a breeze to maintain, very clear and well organized.
I think a lot of this complaint really can be traced to the Camel book, which while generally admirable and clear in its explanations is a bit too hung up on the Perl motto: "There's more than one way to do it". It is an interesting, and perhaps essential element of the Perl philosophy (I haven't decided which), but unfortunately every new Perl programmer who uses the Camel book to learn makes up his own idioms, and they don't always choose well.
I'd be interested in the consistency and quality of the Perl style in the book. It may be time for an "elements of Perl style" handbook.
Insightful (Score:3)
but that's because they just don't get it.
That is a very insightful statement(ignoring the surrounding flamebait). Gung-ho Perl programmers do have the same mentality and viewpoint as VB programmers.
But the reason Perl is so quick is the same reason that VB is so quick. They both let you get away with almost anything. While this is fine for small scripting solutions, it breaks down as your application becomes more complex.
Perl is useful, but only for small scripting problems. As your problem grows, Perl becomes less and less useful and no amount of burying your head in the sand will change that.
One of the most important and valuable skills a developer can have is knowing what tools to use for what job. I use Perl to bang out a simple script in a day or two. For anything more complicated I use C or C++.
--GnrcMan--
Re:This fills a void (Score:3)
Of course, the -d in Perl comes from a certain "school" as well. The test function from Unix shells.
For a experienced perl programmer at the end of the day he/she will use what's more convenient, which is good. But for someone who's learning the ropes it can be exasperating.
And this is different from learning the libraries in C (or Python) in which way?
-- Abigail
Re:Perl does NOT have just one datatype (Score:3)
No, it doesn't. == and eq are different operators, doing different things. They aren't the same operator giving different answers depending on the type of the operands, like / does in C. == and eq are different, just like + and * are.
-- Abigail