Perl for Web Site Management 148
| Perl for Web Site Management | |
| author | John Callender |
| pages | 528 |
| publisher | O'Reilly and Associates |
| rating | 8 |
| reviewer | perldiver |
| ISBN | 1565926471 |
| summary | Superb introduction to Perl for "accidental programmers" |
In his preface, Callender describes his own transition from a writer and editor to the kind of one-man-band that, back in the '90's, we called a "webmaster". He characterizes himself and others in the same boat as "accidental programmers", and justly praises Larry Wall for creating a programming language that enables such novice coders to do useful things right away. "Like natural languages, one of the ways in which Perl makes easy things easy is that it is designed to let you get by using only a small subset of the language. As Larry puts it, Perl lets you talk baby talk, and in Perl such baby talk is officially okay."
For non-programmers, this is a better Learning Perl than Learning Perl. The latter title, by Schwartz and Phoenix, is explicitly intended for established programmers seeking to add Perl to their existing tool belt of languages. Perl for Web Site Management is for the folks Apple used to call "the rest of us". Callender assumes no knowledge on the part of his reader beyond some familiarity with HTML and the web; this starting-from-zero approach makes the book maximally inclusive, while his ability to convey a lot in a small space brings the newbies a long way in the space of a couple chapters. He provides thorough redirection to the standard sources of Perl and Internet lore (the perl* man pages, the standard Perl programming texts, and others).
Virgin programmers, when they're through with Perl for Web Site Management, will find themselves able to make effective use of Perl programs to automate a plethora of tasks, including mass manipulation and modification of a site's files; server log analysis (using Perl's powerful regular expression facility); link checking (using the LWP module); and auto-generating an annotated site map from the <META> tags in the site's HTML files. The latter part of the book introduces server-side web application programming using CGI (examples include coding a site Guestbook and integrating with the SWISH-E site search facility), along with more advanced lore like the CPAN code archive, Perl's object-oriented features, storing user data in DBM databases, and publishing modules for reuse by others. Along the way, the book teaches a respectable amount about UNIX, as well; the main text, as well as the many informative sidebars, contain concise and clear explanations of necessities like stdin/stdout redirection; chmod and file permissions; shell filename globbing; tab completion in bash; network troubleshooting with traceroute; and much more.
Callender's writing style provides the right mix of hand-holding, humor, and clarity for the book's target audience. He simplifies without dumbing down, and he proves that he picked up a considerable amount of hacker culture on his own journey up the learning curve, which he shares with his pupils, citing sources from Neal Stephenson's In the Beginning Was the Command Line to Jon Udell's Practical Internet Groupware. He also does a good job of evangelizing the culture of sharing and open systems that created Perl, Apache, and the Internet as we know it, giving abundant proper credit to the authors and creators of all the tools and references to which he refers his readers. He concludes by listing, and providing jumping-off points for, the wide variety of logical "next steps" that go beyond the scope of the book: Python and other programming languages for the web, Apache configuration, mod_perl, system administration, and relational database integration.
As you may have guessed by now, I recommend this book highly, especially for anyone who finds him- or herself with responsibility for maintaining a web site but feeling a bit underequipped to do so. The book has a limitation (which is not the same as a shortcoming): it's a tutorial, not a reference work; though the index is quite serviceable, this isn't the book to turn to when you need to remember the order of the arguments to substr. This is a book to sit down and read through, once or multiple times, to help build a framework of knowledge and begin populating it with pearls of wisdom that can be put to immediate use.
Additional information about the book, including code for the examples given, is available on the web at the author's web site, O'Reilly's page for the book, and at the online bookseller site of your choice. Table of Contents:
Preface
1. Getting Your Tools in Order
Open Source Versus Proprietary Software
Evaluating a Hosting Provider
Web Hosting Alternatives
Getting Started with SSH/Telnet
Meet the Unix Shell
Network Troubleshooting
A Suitable Text Editor
2. Getting Started with Perl
Finding Perl on Your System
Creating the "Hello, world!" Script
The Dot Slash Thing
Unix File Permissions
Running (and Debugging) the Script
Perl Documentation
Perl Variables
A Bit More About Quoting
"Hello, world!" as a CGI Script
3. Running a Form-to-Email Gateway
Checking for CGI.pm
Creating the HTML Form
The <FORM> Tag's ACTION Attribute
The mail_form.cgi Script
Warnings via Perl's -w Switch
The Configuration Section
Invoking CGI.pm
foreach Loops
if Statements
Filehandles and Piped Output
die Statements
Outputting the Message
Testing the Script
4. Power Editing with Perl
Being Careful
Renaming Files
Modifying HREF Attributes
Writing the Modified Files Back to Disk
5. Parsing Text Files
The "Dirty Data" Problem
Required Features
Obtaining the Data
Parsing the Data
Outputting Sample Data
Making the Script Smarter
Parsing the Category File
Testing the Script Again
6. Generating HTML
The Modified make_exhibit.plx Script
Changes to &parse_exhibitor
Adding Categories to the Company Listings
Creating Directories
Generating the HTML Pages
Generating the Top-level Page
7. Regular Expressions Demystified
Delimiters
Trailing Modifiers
The Search Pattern
Taking It for a Spin
Thinking Like a Computer
8. Parsing Web Access Logs
Log File Structure
Converting IP Addresses
The Log-Analysis Script
Different Log File Formats
Storing the Data
The "Visit" Data Structure
9. Date Arithmetic
Date/Time Conversions
Using the Time::Local Module
Caching Date Conversions
Scoping via Anonymous Blocks
Using a BEGIN Block
10. Generating a Web Access Report
The &new_visit and &add_to_visit Subroutines
Generating the Report
Showing the Details of Each Visit
Reporting the Most Popular Pages
Fancier Sorting
Mailing the Report
Using cron
11. Link Checking
Maintaining Links
Finding Files with File::Find
Looking for Links
Extracting
Putting It All Together
Using CPAN
Checking Remote Links
A Proper Link Checker
12. Running a CGI Guestbook
The Guestbook Script
Taint Mode
Guestbook Preliminaries
Untainting with Backreferences
File Locking
Guestbook File Permissions
13. Running a CGI Search Tool
Downloading and Compiling SWISH-E
Indexing with SWISH-E
Running SWISH-E from the Command Line
Running SWISH-E via a CGI Script
14. Using HTML Templates
Using Templates
Reading Fillings Back In
Rewriting an Entire Site
15. Generating Links
The Docbase Concept
The CyberFair Site's Architecture
The Script's Data Structure
Using Data::Dumper
Creating Anonymous Hashes and Arrays
Automatically Generating Links
Inserting the Links
16. Writing Perl Modules
A Simple Module Template
Installing the Module
The Cyberfair::Page Module
17. Adding Pages via CGI Script
Why Add Pages with a CGI Script?
A Script for Creating HTML Documents
Controlling a Multistage CGI Script
Using Parameterized Links
Building a Form
Posting Pages from the CGI Script
Running External Commands with system and Backticks
Race Conditions
File Locking
Adding Link Checking
18. Monitoring Search Engine Positioning
Installing WWW::Search
A Single-Search Results Tool
A Multisearch Results Tool
The map Function
19. Keeping Track of Users
Stateless Transactions
Identifying Individual Users
Basic Authentication
Automating User Registration
Storing Data on the Server
The Register Script
The Verification Script
20. Storing Data in DBM Files
Data Storage Options
The tie Function
A DBM Example Script
Blocking Versus Nonblocking Behavior
Storing Multilevel Data in DBM Files
An MLDBM-Using Registration Script
An MLDBM-Using Verification Script
21. Where to Go Next
Unix System Administration
Programming
Apache Server Administration and mod_perl
Relational Databases
Advocacy
Index
You can purchase Perl for Web Site Management from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Perl vs. PHP (Score:3, Insightful)
PHP is roughly Perl-based, and is probably a more appropriate language for beginning coders than Perl, IMHO. Having written website management tools in both languages, if I had to do it again, I'd do it in PHP.
Re:Perl vs. PHP (Score:1, Informative)
PHP is nice n'all, but it BEGS to be embedded in HTML (tho' templating modules are available, I know), and as to your "functionality" claim
Re:Perl vs. PHP (Score:1, Informative)
Don't get me wrong, I *like* PHP, but the original post speaks of much ignorance of the strengths of Perl.
Re:Perl vs. PHP (Score:1)
Re:Perl vs. PHP (Score:3, Insightful)
While Perl is certainly a much more powerful and flexible language, most website management functions can be carried out much more simply and in less time in PHP since it was designed with website management and database connectivity in mind.
That's interesting... I'd use Perl precisely because it is a more general-purpose language than PHP. It is very funny how we developers rationalize these things.
Re:Perl vs. PHP (Score:5, Interesting)
- It's more flexible for the random data munging that makes up a big part of the book (things like mass-editing a collection of documents, generating reports from the server's access logs, and so on).
- In the happy event that the non-programmers who are the book's target audience find themselves wanting to go beyond web-specific programming tasks, Perl will provide them a better platform for doing that.
- CPAN.
- I didn't know much (well, any) PHP when I started writing the book. When I started bugging my knowledgeable friends to tell me how to do web things more efficiently, PHP didn't exist yet. If it had, they might well have steered me toward it. As it was, they steered me towards Perl - and overall, I'm really happy that they did.
A book like mine that focused on PHP rather than Perl could be really useful for non-programmers looking to automate their web development. Unfortunately, someone else would have to write it. In the meantime, for someone willing to take on the challenge of learning a more powerful language like Perl, the potential rewards make it, in my view at least, a viable alternative.John
Re:Perl vs. PHP (Score:2)
If the collections become complex, then perhaps a database is in order. An array of array pointers is too hard to later change into database calls if things keep getting more complex. At least wrap the collection calls in API's of some sort so that the calling code is not hard-wired to any particular implementation (or at least traslatable at one or few spots.)
"Naked collections" are *not* a good thing in my book, and I cuss at programmers (behind their back if left) that use them too much.
Re:Perl vs. PHP (Score:2)
Aditionally, I think Perl is an excellent language for novice programmers. While the "line noise" may perpetuate the belief that Perl is overly complicated, it is in fact quite simple.
I cannot say the same for PHP. The rather large library of built-in functions, in my experience, makes it harder to learn, and when learned, harder to use for things like database interaction.
Re:Perl vs. PHP (Score:1)
Re:Perl vs. PHP (Score:2)
Re:Perl vs. PHP (Score:2)
Re:Perl vs. PHP (Score:2)
It uses plain Ruby code, but embeds it PHP-style, thought it uses rather than by defualt.
Just what I've been looking for (Score:1)
Re:Just what I've been looking for (Score:2)
I bought this book a few months ago, and if I hadn't been down with pneumonia for a few weeks, I'd probably be done with it. But my experience so far has been very positive. I've gone through Learning Perl, and had a few classes in C and Fortran (Hooray for university programing requirements: Fortran. Sheesh.), and PfWSM is the best so far - it is teaching me useful bits while showing me the larger language.
Now if I had more content to put in the websites I'm managing, that would make things easier to automate. It's kinda hard to automate when your two test runs do all of the conversion you need. :)
Re:Just what I've been looking for (Score:2)
Listen to your god, dont do it!
Cool (Score:5, Funny)
Nothing could possibly go wrong there...
Re:Cool (Score:1)
I just wonder how they fit all of that in 528 pages.
The true answer? Probably not.
Re:Cool (Score:5, Interesting)
Didn't happen. Once I got into the specifics of everything I needed to explain to get my target reader up to speed, I realized that there was no way to get there while being true to the needs of my intended audience. So I didn't try. Things like Apache installation, DNS, HTML, and graphic design I assumed that the reader either had somebody else to take care of or knew enough about for their current purposes already.
The TOC in Dave's review gives a pretty clear picture of what the book does and doesn't manage to cover. In the end, it's very much a beginner's book. It's a "See Dick code. Code, Dick, code!" type of book. It's about helping the reader make a good start, and doesn't pretend to take them all the way to the end of the journey. I like to think that that makes the book more honest, and more useful, at least for its intended audience, than all those brightly-colored ones crowding it off the bookstore shelves that do promise to teach all those things, but then fail to deliver.
Of course, I may be biased. :-)
John
Re:Cool (Score:1)
Perl DIY vs WebObjects (Score:2)
There's obviously going to be learning-time-cost-flexibility-power tradeoffs when evaluating, but the question I'm wondering: when is it worth more to do it yourself, and when is it worth more to use someone else's tools?
At my stage in my life, DIY is cheaper and easier. If I were running a for profit website with customers, privacy and security concerns, reliability concerns... is DIY still feasible for one person? For 10 programmers?
Is deploying a commercial product something to consider? When? What circumstances? Or are they complementary?
Re:Perl DIY vs WebObjects (Score:2)
At the same time, there's a philosophical position that says the Web in its basic design is not about shrink-wrapped commercial solutions that lock users into a particular set of proprietary file formats and menu choices. It's about doing exactly the opposite of that. It's about freeing up users to do their own thing, to design their own web-based applications free of the constraints that inevitably get imposed by commercial vendors' marketing research and closed implementations. It's about letting users stop functioning as "users" so much, and start functioning more as programmers, able to build their own tools and pioneer their own paths.
That said, I realize there is a counter-position that says I'm being naive; that there's absolutely no point in having a million accidental-programmer monkeys lamely re-inventing the same wheels over and over again. You want a database backend that is integrated with a template-based presentation layer? You buy it from a commercial vendor, so you get something that actually works, and you limit the users to going clickee, clickee on menus all day so won't put their eyes out.
Both positions have merit. The fact is, I've always operated in small-scale settings, where money was a real concern, and big, expensive web-development applications weren't really an option. And I've really enjoyed learning to do stuff myself, and have come to take for granted that I can be master of my own destiny when it comes to the features I'm going to implement and the way I'm going to implement them.
If I'd traveled a different path, I'd probably be singing the praises of tools like WebObjects. Realistically, I have no business offering a comparison of the two approaches, since I've only ever really used the one. When all you have is a hammer, and all that.
I think there's room for both approaches, but for the kinds of web development I've been involved with, I very much prefer the DIY one. For better or worse, that's the only approach I talk about in my book.
John
Other *nix books for "the rest of us"? (Score:1)
So that being said, what books do /. folk suggest? I'm not talking advocacy of anything in particular, just good books on basic administration.
Me, I started with the big purple book, the Unix System Administration Handbook. I found it incredibly useful for getting my feet wet.
Thoughts?
CC
Re:Other *nix books for "the rest of us"? (Score:3, Informative)
Is this a good thing? (Score:4, Insightful)
I hope I don't come off as an elitist, but don't we have enough "non-programmers" acting as programmers thanks to the
Compare to Hayes auto repair books (Score:5, Insightful)
Re:Compare to Hayes auto repair books (Score:1)
Sweet parody!
Re:Compare to Hayes auto repair books (Score:2)
Those are the yahoo's who break down on the on-ramp when you are late to work.
Also, if *other* people drove those cars for work reasons, then your analogy would fit better.
Compare to MP3.com (Score:1)
Re:Is this a good thing? (Score:1)
Re:Is this a good thing? (Score:3, Insightful)
You have to qualify what you mean by "programmer":
- Is someone going to hand you a detailed design which you then translate into code? In this case, just about any of the "programming xxx" books on the shelves at the bookstore will do fine.
- Or are you
responsible for analysis, architecture and design too? Will you be responsible for maintaining the databases? Will you interface to other systems? If so, try to take some courses or read books on architecture and design. If web
pages are part of the medium, look carefully
at the processes involved at other "good" succesful websites.
And don't ignore the failures either. Read the RISKS Digest [comp.risks] and Web Pages that Suck, too.Re:Is this a good thing? (Score:1)
Re:Is this a good thing? (Score:2)
This is certainly true. One can learn a programming or markup language easily and still not be a good programmer. However, for some people, as they learn the also begin to pickup the good programming habits that makes one a good programmer.
Not to be arguementative, but if you are a good programmer and an non-programmer came to you wishing to learn; what would you tell them? How does one learn to be a good programmer?
Re:Is this a good thing? (Score:3, Insightful)
I see your point, but there's a difference between a quick 20 line script to check for dead links and a million-line code base that has revision control and regression testing. In other words, the target audience does not want to write serious code -- they just want a few extra tools in the toolbox to help with some of the more mundane tasks. Sure, some might read this and try to write a sprawling custom order tracking backend and probably fail or introduce serious security issues, but I think it's a minority. The "I'm an editor not a programmer" types would probably agree that they want to write the minimum amount of code necessary to get the job done.
Or, put another way, most of the people who would need this book have only a few options: browse through code snippets and blindly cut+paste until something finally works, pay/beg someone else to do it, or read this book and get off on a running start to actually understanding the strange and bizarre world of perl.
Re:Is this a good thing? (Score:1)
I read the review, and as soon as I'm done typing this, I'm going to order the book.
Re: (Score:1)
Re:Is this a good thing? (Score:2)
Re:Is this a good thing? (Score:1)
Re:Is this a good thing? (Score:1)
re: Abstraction (Score:2)
What would be an example of one not being the other (assuming "good" abstraction)? I don't see why they would be different.
"Abstraction" is sort of an abused word that is in the eye of the beholder. Sometimes it means "hiding the nitty gritty details", but isn't that a pragmatic goal? (If not carred away)
Re: Abstraction (Score:1)
Anyway, I guess I probably didn't use abstraction in the way you expected. Here I meant "pragmatism" as the "tools to do the job," to paraphrase the parent, as opposed to "abstraction," which I meant here by the more colloquial usage as "lots of knowledge that is divorced (abstracted) from what you actually need to do."
It's not abstraction in the programming, data abstraction, "hiding the nitty gritty" sense of the word, but a kind of divorced knowledge that I associate with my early comp sci classes, which had us doing ridiculous things like implementing set theory with Scheme.(That had an absurd level of "hiding" kind of abstraction as well, but that's neither here nor there).
That's actually my problem with O'Reilly books, and why I can never get started in learning anything new from them--much too much theory too soon, and a bottom-up, start from "Hello world!" kind of approach to things. I'm surprised this one is a little different. I generally much prefer to start with something a little more goal-oriented and then, when I feel comfortable with "the tools," and start wondering, "Heh, tell me more about this language/whathaveyou," *then* I pick up an O'Reilly book, or some other good reference.
So yes, I like programming with practical goals. That was my point, and it only took me two posts to get to it!
Baby talk is fine.... until it gets out of hand. (Score:2, Insightful)
As a fulltime "baby talk" to "real code" translator, I have often found that "baby talk" doesn't usually have any documentation.
Perl is a kick-ass language but if written badly it wont scale properly and there are very few things in this world that suck more then sky-scraper built on top of a shanty.
huper
Re:Baby talk is fine.... until it gets out of hand (Score:2)
Yes, more than once. In each case, a rewrite into a more appropriate language was the answer. I'm a professional developer, and I can write decent Perl, but what I use it for are admin scripts and text processing (I first began using Perl as a more powerful replacement for Awk).
The Perl systems I've been asked to look at have been entire applications where the coder started small and grew without any architecture. Once you hit about 4,000 lines of code or so, the problems start to appear. By the time you reach about 10,000 lines of code, the seams are creaking. Systems that need much more than this should not be written in Perl.
Perl is a kick-ass scripting language with incredibly powerful features and an enormous set of really useful libraries, but in any application large enough to need an "architecture", it's not appropriate.
Yes, you can use discipline and write well-structured Perl, but that's like writing object-oriented code in C - the language isn't helping you. For serious software development, use a language that helps you write clean, modular, readable, self-documenting code.
Re:Baby talk is fine.... until it gets out of hand (Score:2)
{
package Foo;
sub new {
my $class = shift;
return bless {@_}, $class;
}
sub bar {
my $self = shift;
if (@_) {
$self->{bar} = shift;
}
return $self->{bar};
}
}
my $foo = new Foo(bar => "hello world!");
print $foo->bar;
# hello world!
See, that wasn't so hard.
And in some ways the underlying approach is little different that Python's(and PHP's... I think) much vaunted object model. OO code in C functions in much the same way as well. In all of them the object itself is the first argument passed to the function/subroutine, and syntactic sugar allows this to happen automagically.
Foo::bar($foo) == $foo->bar;
Re:Baby talk is fine.... until it gets out of hand (Score:2)
Re:Baby talk is fine.... until it gets out of hand (Score:2)
It isn't the job of a language syntax to make someone a good programmer. That's the job of the person teaching them. If it's that big a problem, get into the newbie communities and instill good practices from the very beginning.
Re:Baby talk is fine.... until it gets out of hand (Score:1)
As for encouraging good practices, a couple of things that can help are strict object-oriented languages, and static typing - which is exactly why you think Eiffel is a candidate. If Ada weren't so unnecessarily bloated, it might come close, but it fails because it doesn't have proper OO.
By "strict", I mean languages that aren't procedural with OO tacked on, that don't allow "backsliding" into pure procedural coding. Not that procedural coding is necessarily bad, but when it gets out of hand - big and without proper structure - it can be. Better to force people to use classes - any organization is better than no organization.
Static typing helps in team environments where multiple programmers have to work on the same body of code. It provides a kind of self-documenting of the code that's guaranteed to be accurate (enforced by the compiler). It also helps tools understand the code, and can actually help point out deficiencies in the design (which is part of why "refactoring" has become such a big deal in the Java world).
It isn't the job of a language syntax to make someone a good programmer.
Syntax isn't even remotely the issue. Semantics is. It's when you get to the semantics that the issue of how you're encouraged to write code comes into play. This is an issue that can affect newbies as well as experts, because humans tend to be lazy, and it's easy to fall into bad habits. Perl is a language that encourages bad habits - it actively rewards them. This can be a good thing if you're trying to get some fairly small thing done quickly, where elegance and long-term maintainability are not big issues - the hacky shortcuts can be useful. But hacky shortcuts don't usually scale.
Re:Baby talk is fine.... until it gets out of hand (Score:2)
print "$_\n" foreach @foo;
This is very easy for Perl to figure out, and can be optimized. A general loop, however, is much much harder for the bytecode compiler to optimize, since it introduces far greater potential complexity. The more concisely you can say something, the fewer different ways it can be taken.
A lot of the things that look ambiguous in Perl are in fact quite the opposite to the compiler/runtime. Using such things when appropriate is a good idea even in large projects.
Perl 6 should help quite a bit, as well. Optional strong typing, and a proper OO facilities. I even made a comment on the mailing list that it might be worth investigating whether or not Perl 6 could transcend the simple public/private/protected scheme and do something along the lines of Eiffel. Say...
class Hello {
method world is public {
print "Hello world!\n";
}
method foo is public(Bar) {
print "Hello foo!\n";
}
}
class Foo {
method main {
Hello.new.foo;
# throws an exception since
# method foo of class Hello
# is private to class Foo
}
}
Re:Baby talk is fine.... until it gets out of hand (Score:1)
If Perl were restricted to its OO bits, with some of the legacy eliminated, and the documentation were changed so that newbies aren't encouraged in bad habits, it could become a somewhat more well-suited language for serious development. You'd probably end up with something more like Python or Ruby (btw, why am I discussing Perl with someone named "PythonOrRuby", anyway?)
I suspect with or without projects like Parrot, the major scripting languages will tend to converge, since they already primarily differ in terms of syntax and convenience features, and not that much in semantics.
The typing scheme you suggest for Perl 6 looks similar to "friend" classes in C++ - although in C++ it is enforced statically, which is an advantage for this sort of thing.
Actually, public/private/protected scoping is rather simplistic and old-fashioned, but perhaps convenient. Strictly speaking, you're better off using types properly, a.k.a. interfaces. A class can have a private interface (set of methods), a protected interface, and a public interface. Each of these interfaces is actually a distinct type, and thus can benefit from the usual type-checking and inference rules, i.e. you don't have to have special logic to deal with public/private/protected. Each client simply uses the interface which it has access to, and you aren't restricted to three different kinds of interface.
In general, type issues in programming languages have been very well researched, so if you're interested in that sort of thing, I suggest you pick up some books on functional programming and type theory. Haskell, ML, or OCaml are good languages to learn in this area. Learning programming language theory by watching Larry Wall is as ill-advised as learning to program by reading the Perl docs...
Re:Baby talk is fine.... until it gets out of hand (Score:2)
At the urging of the same friend I learned Python, and grew to like it rather quickly as it helped me understand OO concepts.
I later moved onto Ruby, and for various reasons was alternating between the two languages heavily when I registered my username.
Since, in the excitement that Parrot has provided - it's the first time I haven't been "catching up" on something - I've returned to my Perl beginnings, doing it right this time around.
You'd be amazed the amount of programming theory you can soak up reading through the perl6 mailing lists.
When I help friends with picking up Perl, I generally start by emphasizing the separation of interface and implementation in a program, the go over basic I/O, then variables, then subroutines, then aggregate and nested data structures, then objects. All of the different control structures(conditionals, loops, etc.) are gradually covered in the context of building a trivial sample class. I save things like closures for a bit later, as I don't like to mix the "here's a data structure with access to some subroutines", and "here's a subroutine with access to some persistent data" messages.
Re:Baby talk is fine.... until it gets out of hand (Score:2)
I know what you mean, since I've picked up a lot of theory in similar ways over the years. Along those lines, Lambda the Ultimate [weblogs.com] is a good place to get pointers to a variety of current research. It's worth getting at least some of the theory closer to its source. Have you read SICP [mit.edu], for example? That was one of the books that got me back into theory after many years out of CS at university (the CS I did was pretty lame - mainly learnt Pascal, very little real CS theory).
If you're into that sort of thing, though, SICP is just a gateway drug. Lambda calculus, type inferencing, type theory [upenn.edu] in general, and much, much more [readscheme.org] follows, and pretty soon all the mainstream languages are looking pretty pale... It all does give some good criteria by which to compare languages, though, and helps avoid being limited in one's thinking by the language one happens to be using.
BTW, I agree about not teaching closures in Perl to newbies. Perl and Python both have enough hardcoded ways to do things that you don't need to rely on closures, except to be perverse [plover.com]. The more important concept for useful programming is higher-order functions, since they provide a capability that's directly useful in Perl (or any language), and closures can be introduced in that context.
You've probably come across this before, but here's a nice piece about ML's type system from a partly Perl perspective [plover.com].
Re:Baby talk is fine.... until it gets out of hand (Score:2)
I've found closures can be genuinely useful for complex looping behaviors that are used repeatedly throughout a program.
cool (Score:3, Interesting)
Re:cool (Score:2)
Re:cool (Score:2)
Re:cool (Score:1)
Re:cool (Score:2)
Re:cool (Score:1)
http://www.scriptbasic.com/html/index.html
it looks interesting.
Re:cool (Score:2)
Re:cool (Score:2)
You don't have to go to college to be a good programmer. For some people it helps, but it isn't necessary.
Re:cool (Score:1)
http://www.amazon.com/exec/obidos/ASIN/15716911
IMHO the best first Perl book out there for people without a background in unix scripting languages and / or C.
Re:cool (Score:1)
What is this world coming to?<br></haha>
Re:cool (Score:2)
This is a good thing (Score:2, Insightful)
Programming is more than just a job or a hobby; it's a lifestyle. The more people that can be drawn into the programming world, the better. People who may not have otherwise experimented with programming may do so in order to develop web based applications.
Furthermore, giving content developers a better sense of how Unix operates can only be a good thing. As a system administrator dealing with content developers, I know the woes of having to fix things when say, they can't get file permissions right from their ftp clients, and they don't know the first thing to do to fix it themselves.
Also, the more people understand Unix/Linux, the better chance it has of faring in the desktop.
The title is an understatement (Score:1)
Well, not quite. The book does see to teach to novice stuff about UNIX, but it's only stuff required for web site development (iow, to be able to use the book) - features that are included in every book worth its salt. Since teaching UNIX was never an intention of the book (it's not even a secondary purpose), the book's title seems just right.
The way things are, it wouldn't quite be right to mention UNIX in the title.
Just my $0.02
Website tools... (Score:4, Insightful)
Sure, some people can't afford a $700 package like WebObjects, but then, if you're worth $20 an hour, that's only 35 hours worth of time... or one week.
If you can get up in one hour what takes you one week 'learning from scratch'... as well as not having to write *or* maintain tools... isn't that money well spent?
Re:Website tools... (Score:1)
As Jamie Zawinski said: (Score:2)
The same is true with any "free" software. It's only a bargain some of the time. Too many people here don't realize that.
- A.P.
Re:As Jamie Zawinski said: (Score:5, Insightful)
I value my time a lot, thank you very much, and I use Linux almost exclusivly.
How long will it take you to learn WebObjects and be able to realize the $700 software investment in saved time. What about the upgrade treadmill? Why teach yourself a close source tool set when you can just as easly use an open source tool set? You would arguably recoup the cost in time, and therfore money, much sooner.
Also if you choose to invest your time in a propritary system, you are still bound to the whims of the company that developed it. Look at the people that invested time in Drumbeat 2000. Macromedia bought it, and promptly crushed it. You learned Drumbeat, you were screwed. I don't know about WebObjects, but can you garuntee that they will not have a simmilar fate?
You can choose to learn something that gives you total control over the tool, and you are much less likely to be screwed with your time investment.
Re:As Jamie Zawinski said: (Score:2)
I don't know, but a lot less than it would have taken to recoup the $50,000 it was going for up until about a year or so ago
Re:Website tools... (Score:1)
Re:Website tools... (Score:2)
At the end of the week, has the employee produced $700 worth of work? Or just consumed $700 worth of paycheck?
Whereas, with a tool, at the end of the week, $1400 was spent, but $700+ was produced because for 39 hours the employee was working on producing content?
In another analogy, is your time spent better that writing a new word processor, or is the boss's money better spent buying you Word?
Re:Website tools... (Score:1)
The question most people face is not "given infinite cash, what is the most efficient way to organize one's affairs", but "given a limited amount of cash, which isn't available all at once, how can I maximize my output?"
If someone really needs all or most of the features that Word provides, it would obviously be more sensible to purchase it rather than write it from scratch. On the other hand, one doesn't need to spend hundreds or thousands of dollars on some website log analysis tool to count up the number of unique visitor IP's for a website, or to check for broken links. Again, the question is not "what is the most efficient way to achieve Word's functionality?", but "what is the actual problem I need to solve, and how can I do that in an efficient, economical fashion?" If the problem to be solved is a search-and-replace over some text files, or counting words and lines, etc., then the easy thing to do is handle that with free tools like awk or perl or grep, rather than invest hundreds of dollars in some pig of a spyware application that's going to need updating in six months.
Re:Website tools... (Score:2)
But the issue is at what point is a $700 investment in tools worth more than learning how to create all the tools necessary to achieve the same thing?
The price of the book is quite obviously a no brainer, compared to the price of WebObjects.
But if you're trying to write up a web store and an account/login system, with integration into a site that offers online on site information, how much is a good programmatic application server and a set of libraries and development tools, as opposed to writing them all up from scratch in Perl?
Re:Website tools... (Score:1)
Apples are red, oranges are orange. Why would you write an application server, libraries, and development tools from scratch, when so many are already available for Perl?
hmm... what!? (Score:3, Informative)
Sure, off-the-shelf products may be great for basic cookie-cutter style websites, but learning how to program everything yourself is much more useful.
Different tools for different jobs.
Re:hmm... what!? (Score:2)
Quoted from http://www.apple.com/webobjects:
WebObjects efficiently generates HTML, XML, or SMIL from reusable templates, which are mapped directly into the object model. By cleanly separating the presentation layer from your logic and data, you never have to worry about corrupting your database. WebObjects will even handle all your session management needs, without using cookies.
Access data automatically
Our patented Object-Relational Mapping engine lets you write all your business logic using objects. WebObjects will automatically fetch, cache and update the data for you from any JDBC 2 database or JNDI service -- you may never need to write another line of SQL.
Create applications rapidly
WebObjects comes with a comprehensive suite of developer tools. One person can construct a prototype in seconds, or a team can manage a sophisticated e-commerce project. And when web pages aren't enough, WebObjects enables you to rapidly create full-featured, three-tier Java desktop applications, running on their own or in a browser.
Java CompatibleDeploy anywhere painlessly
The WebObjects runtime is written entirely in Java, allowing you to deploy your application to virtually any J2EE server or use Apple's scalable Java application server. And with low-cost licensing and smart load-balancing, it's a snap to add more machines to scale your application as necessary.
And quoting the review on what the book, with Perl, allows you to do:
Virgin programmers, when they're through with Perl for Web Site Management, will find themselves able to make effective use of Perl programs to automate a plethora of tasks, including mass manipulation and modification of a site's files; server log analysis (using Perl's powerful regular expression facility); link checking (using the LWP module); and auto-generating an annotated site map from the tags in the site's HTML files. The latter part of the book introduces server-side web application programming using CGI (examples include coding a site Guestbook and integrating with the SWISH-E site search facility), along with more advanced lore like the CPAN code archive, Perl's object-oriented features, storing user data in DBM databases, and publishing modules for reuse by others. Along the way, the book teaches a respectable amount about UNIX, as well; the main text, as well as the many informative sidebars, contain concise and clear explanations of necessities like stdin/stdout redirection; chmod and file permissions; shell filename globbing; tab completion in bash; network troubleshooting with traceroute; and much more.
WebObjects is not a 'cookie cutter' website management and creation tool.
It's a tool to allow for the programmatic creation and manipulation of a website, with the capability to create standalone or connected Java apps and applets to boot.
Re:Website tools... (Score:2)
1 week?
2 weeks?
2 months?
Re:Website tools... (Score:3, Informative)
The idea that tools like WebObjects will let you instantly build sites is a myth. Learning enough WebObjects to do anything even a little bit different from their sample applications will take you much more than a week, since it will involve learning Java (or Objective C), SQL, an object/relational mapping system, a suite of development tools, and a development framework that has been expanding for years. Most people want to do something relatively simple on their sites, and can get there a lot faster using a little perl code. Then there's the fact that many sites are hosted on shared web servers that allow CGI but do not allow things like WebObjects.
People who have equivalent knowledge in perl to what it would take to run WebObjects know that nearly everything they need is available for free from CPAN. There's no need to shell out a bunch of money for this stuff.
Re:Website tools... (Score:5, Insightful)
Ha, ha, only serious. No, really, work with me here.
So you've got a collection of programmers. You spend $700 per progger on WebObjects to get 'production quality'. And you expect the site to be up, when, exactly?
Let's see what now has to happen:
- The programmers have to learn or brush up on J2EE & Java.
- They need to learn how to interact with WebObjects, the APIs, the quirks, the bugs, the misfeatures.
- They need to learn to hack around WebObjects when it gets in the way of something they want to do, because they don't have the source code and even if they did they don't know it at all.
- The administrators need to learn how to keep it up and running, how to tune it, how to get specific logging, etc.
- Everyone has to wade through an enormous volume of typically low-quality documentation to filter out the 95% of the framework that they don't need.
- The admins need to figure out why WebObjects' "patented object-relational mapping" is absolutely destroying performance on the DB server and how to get around it.
None of these things are free; you will invest substantial time in learning an app if you go that route.Now let's say you have a collection of programmers who 1) prefer things other than Java, 2) aren't afraid of SQL, 3) know the web, and 4) like to intimate with their code? (Improbable, I know; there are only a few tens of thousands of us out there.) This team can roll from scratch their own system to do the smallest set of functionality they need, and work up from there. They can admin it in confidence because they wrote it and know how it operates. They can reliably say where performance hits are, and they can do it all in their language of choice.
The question is really: spend time trying to understand someone else's product, or spend time writing a product you understand implictly? For some (most) projects, the former is desirable, for some, the latter is a better choice. For writing an application in a rapidly evolving field, impenetrable closed-sourced middleware is frequently a loss in terms of time usage.
Re:Website tools... (Score:2)
Just because Java is what you know doesn't mean that it's the only thing going in computing. Nor does my dislike for it indicate that I have not spent the requisite years in Java purgatory. The rest of your message was similarly trite, so I won't bother with it. Come back when you can log in and avoid ad hominems. An actual meaty discussion is pointless until then.
another "perl for new programmers" book (Score:3, Informative)
man perl? (Score:3, Funny)
Ack! You'll Slashdot the book! (Score:1)
I also find it interesting that the links to purchase the book are generally to Amazon.com, a company who has been bashed around here numerous times. Never do you see a link to someone like Bookpool.com, who tends to be cheaper. I guess Amazon can probably take whatever load Slashdot sends along.
One more book to buy (Score:3, Informative)
MySQL and Perl for the Web
Paul DuBois
New Riders
It is an exellent book.
Re:One more book to buy (Score:2)
"...While we're at it: Why don't I just change my last name back to Hitler?" -- Garth Motherloving
Chapter 22 is missing (Score:3, Funny)
If there was such a thing as a readable and maintainable perl script longer than 8 lines they'd have to write a couple of chapters on that subject alone. Perl projects turn into unreadable spagetti code faster than red meat rots in the summer sun.
Perl and Complexity (Score:2)
I honestly don't know if there is really "a better way" (though of course there's more than one way to do it), but I just spent two days in utter frustration with various Perl problems. One of which I never actually got to the bottom of, and ended up coding around. I am now officially thinking of giving up Perl for Python or Ruby or Java or LISP or something.
I am not a perl newbie. I wouldn't consider myself an expert, but I've been using perl and doing web development (C,C++,Java,Perl, PHP, and once, on a crazy night, even Prolog) since 1996, and developing software since 1994. And yet almost every time I use perl for anything more than 30 lines or so -- especially if it involves OO and packages -- I get caught by some gotcha or another.
Take this, for example. Did you know that LWP::UserAgent traps non-HTTP errors and then gives you a Code 500? So if, like me, you didn't have HTML::HeadParser installed on your machine, rather than simply telling you this is the problem, you might spend two hours trying to figure out why in the world you're getting a server 500 error when looking up http://www.google.com fails with LWP::UserAgent when the rest of your browsers can load it just fine.
That's the one I figured out. The one I couldn't figure out is why URI::URL worked just fine when I used it in the "main" namespace, but when I tried to use it inside a package I wrote myself (called from the "main" namespace, subclassing HTML::Parser), it kept telling me it couldn't find the ->host() method. After about 5 hours of scanning documentation, changing various @INC-related and other things, I decided it would be easier to just write my own URL package that did the subset of things I needed it to do (very glad Gisle Aas included that very nice regexp at the end of the perldoc documentation for URI that helped out, but still....). It was.
Too many hours spent trying to figure out why the straightforward behavior you expect isn't the behavior you get. That's the problem with Perl. The semantics of Perl are built to be easy in a few cases, and very expressive indeed if you know exactly what you're doing, but horribly full of traps for even the wary. Is there a language with the flexibility of Perl, and a greater clarity of expression? I don't know. But I'm looking. And in the meanwhile, I'm going to hold off suggesting perl to those I know who are looking to cross from content to code.
Re:Perl and Complexity (Score:2, Interesting)
I'm a Perl guy, but there is a quote from the inventor of Python that goes something like this:
I agree completely that Perl is designed to function more like a natural language than Python, I'm just not sure why it's desirable. Natural languages are loaded with exceptional cases and special rules. Further subtle changes in context can induce subtle to massive changes in meaning. This is why it takes years to gain fluency in a natural language. Why would you want this in a computer language?
Organic languages (C on Unix, Perl on the Web, Basic on the CPM machines, COBOL on mainframes
Are you -insane-? (Score:1)
What kind of nutjob recommends -perl- as a first language?
For Pete's sake, use a real language, like lisp, ml, python, ruby, something like that. Forget about perl.
this book is good...... (Score:1)
Re:dead language (Score:1)
Perl will ONLY be dead when people stop using it.
Everything is Dying (Score:3, Insightful)
They probably will fall out of style. Almost every language does when new techniques or fads come along. It goes with the territory.
There are a few exceptions, though:
1. C/C++ - These have become the "new assembly language(s)". They are not really known for their software engineering and RAD qualities, and that is probably what saves them: the don't *have to* compete there where things change all the time. But, they have turned out to be fill the niche of assembly languages WRT speed, plus add some portability.
2. LISP - Never popular but never dead. While other languages tend to exaggerate and get carried away with the fads of their day, LISP's "meta" abilities has allowed it to adapt to the day's fads and trends. It's strategy (or ability) is to bend well rather than fit well. It was born in the 1950's as a math-like experiment and was not originally meant for application building.
Re:Everything is Dying (Score:2)
And still is. It was still more of a "lab language", especially for AI.
(* You say it as if programming languages were Hollywood celebrity, not tools meant to be used and adapted to one's needs. Programming languages are not carried around by hype, they *shouldn't* be atleast. They should be evaluated based on what they do and customized until they are deemed useable by its users. *)
"Usable" is not a very lofty goal. As far as fadishness, yes, they *are* like clothing fashions IMO. Where is the rational research that says OOP was "better" than what came before it before all the PHB's jumped on it when they saw it mentioned enuf in the trade rags?
(* Your sense of a programming langugage being "carried" away, only shows the dotcom what-will-sell "developer" you truely are. *)
Whipping the messenger, are we?
(* Lisp was the first language to include conditionals ("if else then") *)
As a library function and not a built-in construct like it is in Algo-derived langs. (That is one of its alleged benefits: everything is a function, so you can make your own language constructs rather than rely on say Larry Wall.)
(* Lisp predates Object Oriented Programming, and it was the first language to fully support all of OOP's requirements *)
This does not contradict anything I said.
(* Please point out ONE computing tool or concept, that was NOT born as a math experiment.... *)
Algo, COBOL, C, Pascal, Perl....
(* Look around you, no matter how much you try to run away from it, programming is still a mathematical excercise. *)
Perhaps we are using a different definition of "mathematical". Also, I think complex software is more like a pshycological problem than a math problem. Software is to communicate with humans as much as to communicate with machines. Humans make more reading errors than CPU's.
Re:dead language (Score:2)
Although I suppose you could be talking about Parrot assembly language.
Re:Will this help with design and usability? (Score:1)
Maybe I'm being too pessimistic: After all, there are real opportunities to introduce architecture, design, and maintainability through Perl scripts (or whatever your favorite automation tool is). And Perl is one of the best tools to use - its built in data structures (especially hashes and hashes tied to DB's) put it near the top of the heap for teaching design issues. PHP has similar elegance though maybe less generality. I hope this book not only exposes point-and-drool HTML makers to the automation possibilities, but that it also forces them to think about these bigger issues. Even something as trivial as forcing someone to think about what a unique key for database access should be is a huge education for too many in the web business.
Re:Will this help with design and usability? (Score:2, Insightful)
There needs to be a certain amount of cross-pollenation for the good of the gene pool: It's certainly got to be easier to turn designers into programmers than programmers into designers.