Slashdot Mirror
Perl for Web Site Management
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.
propz to all dead homiez
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.
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.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
I'm starting up our church's website (no WAY am I posting the link - no /.'ing for us!), and I need to know how to modify PERL scripts. Our budget is pretty thin ~$100/year, so most of this is DIY. Sounds like this should be helpful to me.
- Bill
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
# Important Stuff: Please try to keep posts on topic.
# Try to reply to other people comments instead of starting new threads.
# Read other people's messages before posting your own to avoid simply duplicating what has already been said.
# Use a clear subject that describes what your message is about.
# Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
Problems regarding accounts or comment posting should be sent to CowboyNeal.
Learning Perl and System Administration at the same time.
Nothing could possibly go wrong there...
The opposite of progress is congress
everybuddy knows that a handfull of felonious billyunheirs are gooing to .controll all the weebilly whoabilly wab fromnowon, write?
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^HPerl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.
GNU Emacs already has an elisp module that writes perl cgi for you. /usr/bin/emacs today!
No more late nights up coding!
Spend more time with your spouse/sig. other!
The lastest revision even includes better database support... but wait, there's more! It also brews coffee while it works!
Version 2.0 proposes to have important features such as making mixed drinks and mowing the lawn!
type
//radiotakeover.
Well it's 1 2 3 what are we fighting 4
Well it's 5 6 7 open up the PERLy gates
Here's the stuff that got edited out before the book made it to press (whew!)
Chapter 22: Appendices
Listing: PERL is better than every other language. A comprehensive set of comparisons.
Obfuscate code in your site. Common methods.
Being l337 with perl CGI's (and not getting caught) Effective $kr|p7 k|dDl3 methods.
Gaining root access to your ISP (The most effective local and remote exploits you can execute via perl)
PERL::Pr0n Syntax and HOW-TOs guide.
Thank god for editors!
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
I beleive that after 100 lines of perl code, no matter how cleanly written, all the source will become unmanagable.
This book seems to aim at people who don't code but need to start, and perl is not a very good first programming language....
Perl long and prosper!
If you were a bowl of hot grits, would you pour yourself down your pants?
...who have never programmed before, but who now find themselves with the need to create their own site-management tools, automated web clients, and web-based applications.
.COM boom? I have full respect for a manager or web designer wishing to learn programming and web development. However, teaching them the tools first is not going to make them a good programmer. I'm afraid that books like this will lead towards more poorly designed and written programs. A web application is software and should be treated as such. Is it just me, or does anyone else share this feeling?
I hope I don't come off as an elitist, but don't we have enough "non-programmers" acting as programmers thanks to the
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Have you ever been asked to clean-up really bad perl? Many times "clean-up" is a total re-write.
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
I'm sure it'll result in more complicated websites that are maintained by undocumented Perl scripts. It'll probably result in security holes via the scripts too, despite the effort put into taint mode.
Most importantly, will there be any net gain in design and usability? I realize that there are learning curves with all scripting/automation tools; the realization that automation may be applied to a previously point-and-drool editing task is, I'm sure, a huge step forward for most organizations. I don't pretend to be at the top of that learning curve myself; I'm just far enough up it that I look back at projects I did a few months ago and I want to hide my head in shame because of the little thought I put into design and usability when I did them.
I sure hope this review is accurate. As a computer savvy non-programmer, I've been having trouble wrapping my head around Learning Perl. I think a lack of formal education is really hindering me at this point (go to college, kids!). Maybe this book will help out, I used to be pretty good at C64 BASIC :)
jred
I'm not a mechanic but I play one in my garage...
I hope I don't come off as an elitist, but don't we have enough "non-mechanics" acting as mechanics? I have full respect for a farmer or tradesman wishing to learn auto repair and design. However, teaching them the tools first is not going to make them a good mechanic. I'm afraid that books like this will lead towards more poorly designed and built cars. A car is mechanical and should be treated as such. Is it just me, or does anyone else share this feeling?
Infuriate left and right
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.
Slashdot
/.'ing for us!), and I need to know how to modify PERL scripts. Our budget is pretty thin ~$100/year, so most of this is DIY. Sounds like this should be helpful to me.
/.
News for nerds, stuff that matters
[ faq | code | awards | journals | subscribe | older stuff | rob's page | preferences | submit story | advertising | supporters | past polls | topics | about | bugs | jobs | hof ]
Perl for Web Site Management
Perl | Posted by timothy on 10:45 AM -- Tuesday July 16 2002
from the do-stuff dept.
PerlDiver writes: "Perl for Web Site Management by John Callender is for web professionals -- designers, editors, HTML jockeys -- who have never programmed before, but who now find themselves with the need to create their own site-management tools, automated web clients, and web-based applications. The title is an understatement; the book covers not just Perl programming but the bulk of what a novice needs to learn to function in a UNIX environment, from pwd and man to installing software packages from source tarballs. If you or anyone you know wants to cross the chasm from 'content' to 'code,' get this book." Read on for the rest of his review.
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 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 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.
JismTroll (588456)
[ Preferences ]
Related Links
Learning Perl
SWISH-E
In the Beginning Was the Command Line
the author's web site
O'Reilly's page for the book
Perl for Web Site Management from bn.com
book review guidelines
submission page
PerlDiver
More on Perl
Also by timothy
Book Reviews
Slashdot's book review section is brimming with reader-submitted commentary on interesting books. Here's a sampling of recent reviews -- read below for how you can add yours to the list.
For programmers, check out reviews of the Zope Bible, Programming Jabber and other specialized books.
If you're just trying to manage programmers, grumpy's review of Managing Einsteins might be just what you're looking for. Meanwhile, keep the company afloat with lessons learned from The MouseDriver Chronicles and The Bombast Transcripts.
Science buff? Read Tal Cohen's reaction to Rare Earth, and Peter Wayner on Digital Biology. Don't forget the grain of salt in Voodoo Science, either. His Dark Materials is one of the many Science Fiction titles that Slashdot readers have praised or panned for your pleasure.
And somewhere between Sci-Fi and reality are books like Flesh and Machines, reporting from the intersection of yesterday's fiction and current technology.
It's easy to submit your own reviews for consideration, too. Just read the Slashdot book review guidelines, and then use the web submission form.
Update: 20020427 12:50 by timothy
Mac PVR Coming Soon Perl for Web Site Management | Preferences | Top | 4 comments | Search Discussion
Threshold: -1: 4 comments 0: 3 comments 1: 2 comments 2: 1 comments 3: 0 comments 4: 0 comments 5: 0 comments Flat Nested No Comments Threaded Oldest First Newest First Highest Scores First Oldest First (Ignore Threads) Newest First (Ignore Threads) Save:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Furst P0st
by Anonymous Coward on 10:46 AM -- Tuesday July 16 2002 (Score:-1, Offtopic) (#3894706)
propz to all dead homiez
[ Reply to This | Parent ]
Perl vs. PHP
by Bonker on 10:49 AM -- Tuesday July 16 2002 (Score:2) (#3894734)
(User #243350 Info) http://www.furinkan.net/ [ Neutral ]
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.
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.
--
- "Monitoring cable modems without a warrant is double-plus-ungood".
[ Reply to This | Parent ]
Just what I've been looking for
by Hee Hee Hee on 10:51 AM -- Tuesday July 16 2002 (Score:1) (#3894748)
(User #310695 Info) [ Neutral ]
I'm starting up our church's website (no WAY am I posting the link - no
--
- Bill
[ Reply to This | Parent ]
i luv
by anthrax_spork on 10:53 AM -- Tuesday July 16 2002 (Score:0) (#3894760)
(User #532086 Info) [ Neutral ]
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
You can only post nested lists and blockquotes 3 levels deep. Please fix your UL, OL, and BLOCKQUOTE tags.
# Important Stuff: Please try to keep posts on topic.
# Try to reply to other people comments instead of starting new threads.
# Read other people's messages before posting your own to avoid simply duplicating what has already been said.
# Use a clear subject that describes what your message is about.
# Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
Problems regarding accounts or comment posting should be sent to CowboyNeal.
[ Reply to This | Parent ]
[ faq | code | awards | journals | subscribe | older stuff | rob's page | preferences | submit story | advertising | supporters | past polls | topics | about | bugs | jobs | hof ]
"Ubi non accusator, ibi non judex." (Where there is no police, there is no speed limit.) -- Roman Law, trans. Petr Beckmann (1971)
All trademarks and copyrights on this page are owned by their respective companies. Comments are owned by the Poster. The Rest © 1997-2002 OSDN.
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
With profound apologies to whomsoever this sig originally belonged.
It just recently occurred to me; why are people always rolling their own, instead of using production quality stuff?
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?
GPL Deconstructed
I love you Afra.. i love you man....
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It's when you get distracted by the politickers that they sideline you. The tireless work that you perform keeping the system clean and building is what provides the platform for the obsessives and the prima donnas to have their moments in the sun. In the end, we need you all; in order to go forwards we must first avoid going backwards.
To the paranoid conspiracy theorists - yes, I work for Apple too. No, my resignation wasn't on Steve's direct orders, or in any way related to work I'm doing, may do, may not do, or indeed what was in the tea I had at lunchtime today. It's about real problems that the project faces, real problems that the project has brought upon itself. You can't escape them by inventing excuses about outside influence, the problem stems from within.
To the politically obsessed - give it a break, if you can. No, the project isn't a lemonade stand anymore, but it's not a world-spanning corporate juggernaut either and some of the more grandiose visions going around are in need of a solid dose of reality. Keep it simple, stupid.
To the grandstanders, the prima donnas, and anyone that thinks that they can hold the project to ransom for their own agenda - give it a break, if you can. When the current core were elected, we took a conscious stand against vigorous sanctions, and some of you have exploited that. A new core is going to have to decide whether to repeat this mistake or get tough. I hope they learn from our errors.
Future
I started work on FreeBSD because it was fun. If I'm going to continue, it has to be fun again. There are things I still feel obligated to do, and with any luck I'll find the time to meet those obligations.
However I don't feel an obligation to get involved in the political mess the project is in right now. I tried, I burnt out. I don't feel that my efforts were worthwhile. So I won't be standing for election, I won't be shouting from the sidelines, and I probably won't vote in the next round of ballots.
You could say I'm packing up my toys. I'm not going home just yet, but I'm not going to play unless you can work out how to make the project somewhere fun to be again.
= Mike
--
- posted by poopbot: the bot formerly known as pwpbot
L6yn80OsDo
Although the title gave the impression that it would cover very complex web-mastering techniques, the book actually is an excellent introduction to extending your website's usefulness by using Perl. Web designers that have conquered Javascript, and maybe explored some proprietary server-side techniques would benefit greatly from this clearly written task-based tutorial.
I would recommend the reader pickup Learning Perl and/or CGI Programming with Perl as well. They compliment each other well!
There is also the book "Elements of Programming with Perl" which has generally been well received. It is not a web-specific book, and assumes no previous programming knowledge.
I think it's because of lack of standard of both Perl and Python.
If Perl is dying - where to go? Ruby? Erlnag? Lisp? I stick with Lisp for while. At least it's very clean, very clear and has a lot of libraries - that's exactly what I need from a language for web management.
Less is more !
"Linux is only free if you don't value your time."
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.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Parrot huh? I hope you're joking because this was an April fools joke from a year ago.
(* I'm the kind of person who prefers pragmatism over abstraction, .... *)
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)
Table-ized A.I.
What joke? This page is official, isn't it?
(* Who cares about Perl? It's gonna dyi [perl.com] anyway soon along with Python. *)
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.
Table-ized A.I.
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.
Old April Fools Hoax
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.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
What's wrong with man perl?
www.cgisecurity.com/lib
As often as linked websites get Slashdotted from articles, I wonder how often the supply of a book suffers from this same effect. I know when A New Kind of Science was reviewed, that thing was completely unavailable. Whether or not that was related to Slashdot is unknown.
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.
I take it you're unaware that Perl 5 allows for modular, object-oriented code?
{
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;
it wasn't "Python for Web Site Management".
When you finish this one pick up:
MySQL and Perl for the Web
Paul DuBois
New Riders
It is an exellent book.
This
I hope I don't come off as an elitist, but don't we have enough "unsigned bands" acting as bands? I have full respect for a dj or singer wishing to learn jazz and deep house. However, teaching them the tools first is not going to make them a good musician. I'm afraid that websites like this will lead towards more poorly written and performed music. Music is Media and should be treated as such. Is it just me, or does anyone else share this feeling?
sulli
RTFJ.
You can write bad code in any language, and no language particularly encourages good coding practices. The only exceptions I can think of off the top of my head are Eiffel(http://smalleiffel.loria.fr), and perhaps Ada.
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.
(Silly me, posting as an AC before.. at work and too lazy to log in.)
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!
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.
Chapter 22 Writing A Maintainable And Readable Perl Script Longer Than 8 Lines
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.
oh boy, people developing web apps in PHP or Perl don't keep track of the latest developments in web land. try Java (JSP) or even better : Python (Zope).
Python would be a far better language for a complete newbie.
Can you comment on such tools as WebObjects, and how application server + application/web-service development tools compare to something like roll your own via Perl?
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?
GPL Deconstructed
Unleashing Perl on the newbie? This may not be the best idea.
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.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
In fact, Perl does reward quick hacks. Consider:
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
}
}
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...
Well.... I started with HTML and Javascript, then moved onto some very basic Perl at the urging of a friend, and did some pretty complex(and really stupid!) things with flat-file databases.
:-)
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.
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 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, 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 in general, and much, much more 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. 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.
Apparently you haven't found the spell-check option in emacs... once you do, try running your signature through it.
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.
Actually, I'm just beginning to dip my toes into the Scheme/Haskell/*ML waters. It doesn't help that most of the compilers are a pain to install on Mac OS X.
I've found closures can be genuinely useful for complex looping behaviors that are used repeatedly throughout a program.
for me to poop on
Karma: Terrible (mostly affected by moderation done to your comments)
Comment removed based on user account deletion