Perl for Web Site Management

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. 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.

Comments

Perl vs. PHP

[Bonker]

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.

Re:Perl vs. PHP

[Camulus]

I would have to absolutely agree that PHP is better for web based tools. Perl is an excellent tool for scripting etc. How ever PHP is much more functional not to mention it has integration with MySQL built in. PHP + MySQL has always been a winning combonation for me. I know I wouldn't want to have to recode it in Perl.

Re:Perl vs. PHP

[Art_XIV]

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

[Anonymous Coward]

Please, speak not in this fashion of things with which you have no experience. Access to a database with Perl DBI is also very easy.

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 ... I really have no idea what you might mean by that .. PHP can't (yet) compete with CPAN.

Re:Perl vs. PHP

[jbc]

I talk about PHP (albeit very briefly) toward the end of the book, in the "Where to Go Next" chapter. While PHP's relative simplicity obviously makes it a great choice for a non-programmer needing to automate web stuff, I was driven to make Perl the focus of the book by several factors:

• 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

[RickySilk]

Yes, php has mysql functions but a good developer would use a db abstraction layer such as PEAR:DB or adoDB which is basicly what DBI provides perl. So there really is no difference in this respect.

Re:Perl vs. PHP

[Anonymous Coward]

I don't know know what you think PHP is, but I do know that it's best used to create templates. For the most part, you're just wasting the language when you embed it in HTML.

Re:Perl vs. PHP

[Anonymous Coward]

For a non-programmer, or someone that just wants to add a little bit of dynamic content into a web page, I think php would be better - the .php file can be primarily html with inline php where needed.

Perl is a general purpose language, with modules to make website/html generating easier, but you're coding perl first, writing html second.

For total web site management, perl is probably better (check freshmeat, every day there's 10 new perl scripts to reformat your apache logs) since perl was designed for doing command-line text processing, php wasn't.

Re:Perl vs. PHP

[Anonymous Coward]

I did not deny that you can create templates in PHP, and do so effectively; it's just that the very nature of the language tends to encourage beginners, at whom the book is targetted to mix up their code and their presentation. It's wicked easy to create PHP pages that are essentially souped-up, DB backed server-side include pages that are hard to maintain. If you plan ahead and create templates, well then you're doing well, but your code starts looking a *lot* like Perl templating code.

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

[Tablizer]

(* 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). *)

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

[Anonymous Coward]

I don't know what you think PHP is but I
certainly know you haven't a clue what an
HTML template is.

And the only "wasted language" in all this
is your clueless posting.

Re:Perl vs. PHP

[Anonymous Coward]

a good programmer would use a language abstraction layer.

Re:Perl vs. PHP

[PythonOrRuby]

While less mature than PHP, if you're interested in a powerful general purpose language that can be embedded in HTML, you might want to check out eRuby(http://www.modruby.net).

It uses plain Ruby code, but embeds it PHP-style, thought it uses rather than by defualt.

Re:Perl vs. PHP

[PythonOrRuby]

Maybe it's just me, but aside from the $ sigil, which can be traced back to shell scripting, PHP borrows far more from C/C++ than it does from Perl.

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

[gorilla]

The Mason enviroment offers a heck of a lot that 'bare' perl doesn't. I use it for all my websites nowadays.

Re:Perl vs. PHP

[Cheetah86]

It borrows its string interpolation styles from perl. Single quotes(') mean literal translation, while double quotes(") mean interpolate variables.

Re:Perl vs. PHP

[PythonOrRuby]

That's merely a side-effect of the $ sigil, whose primary purpose is to effectively put variables and functions into separate namespaces.

Just what I've been looking for

[Hee Hee Hee]

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.

Re:Just what I've been looking for

[Louis_Wu]

You have a budget? Wow, I'm working on our church group's site, and I plan on hosting it on my own site. :)

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

[mgblst]

if I hadn't been down with pneumonia for a few weeks

Listen to your god, dont do it!

Cool

[baldass_newbie]

Learning Perl and System Administration at the same time.
Nothing could possibly go wrong there...

Re:Cool

[rocket97]

does it teach you how to install linux?

Re:Cool

[Kazir]

Sure it does. Along with teaching you database administration, SQL, installation of apache, HTML, XML, CSS, graphic design, security, DNS, Bind, and how to use the print statement in Perl.

I just wonder how they fit all of that in 528 pages.

The true answer? Probably not.

Re:cool

[Neil Watson]

Don't loose heart. I worked my way up from basic in high school to a little C in college. I read Learning Perl 3 times before it really started to sink in.

Re:cool

[peterpi]

I used to be pretty good at C64 BASIC

Then there's no reason why you shouldn't be just as good at perl after a bit of practice. Coding is coding is coding. :)

Re:Cool

[jbc]

When I started writing the book, I believed (naively) that I would indeed be able to cover some of those things. I at least thought I'd be able to get far enough to talk about some database administration and SQL.

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

[jred]

Yeah, but that was a looooong time ago. Now I'm pretty much limited to basic html and minor modification of javascripts. I try, though :)

Re:cool

[Pfhreakaz0id]

well, I'll probably get reamed on slashdot for this, but if you know BASIC, why not use vbscript or visual basic for such things. If you're linux, I'm sure there are BASIC's right? Start with what you know to get back into programming. That's what I did, and now I do Java, dHTML, Javascript, SQL, etc. Hell, you can't even claim money. If you have Windows, VBscript comes with the OS, and the .NET compiler is free (beer).

Re:cool

[PythonOrRuby]

Spend more time coding than reading books about coding. Experiment with other languages than just Perl. I know I had to learn Python, or at least aggressively dabble in it, before some of the more advanced Perl concepts made even the slightest bit of sense.

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

[Hee Hee Hee]

I'm sold. I just ordered one from bookpool.com. I'll send you my thoughts once I've gotten into it.

Re:cool

[jbolden]

You might want to try
http://www.amazon.com/exec/obidos/ASIN/157169113 8/ qid=1026857812/sr=1-6/ref=sr_1_6/102-7090612-62569 39

IMHO the best first Perl book out there for people without a background in unix scripting languages and / or C.

Re:cool

[reallocate]

Ya know, like many folks, my first language was BASIC. I always thought Micrsoft's QuickBasic 4.5 was a pretty decent DOS implementation. (They also marketed a more expensive developers version.) I lost interest when they conjured up Visual Basic. Given the fact that it was so blinkin' easy to use, it would be kinda nice to see a grown-up BASIC for Linux. Add some regular expression capability and a new file handling scheme, tho.

Re:cool

[Pfhreakaz0id]

http://www.qbasic.com/

Re:cool

[rapidweather]

What? You mean there is more to writing web pages than gnotepad and Opera 6.02 for Linux?
What is this world coming to?<br></haha>

Re:cool

[Anonymous Coward]

No, don't learn Perl. Go out and get a Common Lisp book, thank me later.

I don't know what to say about perl, all its plus points are already in Lisp,
and ten folds that much, except for CPAN (look at telenet.com/cliki/index.html) for
Lisp packages.

If you insist on learning Perl, good luck to you, but I gave all my perl books
to the local library (also my C++ books) and just started anew as a one man Lisp shop.

I use a 100% Free Lisp environement and am familiar with the tools. But if you want,
you can get a free (as in beer) copy of Allegro Common Lisp, which has more features
than Visual Studio and play with it. There is also LispWorks which has comparable features,
is cheaper, but has a crapy trial version. If you wanna create Standalone Windows binaries,
including COM objects, and DLLs, then get Corman Lisp.

On Unix, you can ofcourse you Allegro Lisp and LispWorks, but there are also free Lisps,
CMUCL (which generates native binaries and has truck loads of docs) and CLISP (which has a
portable VM executable format, and runs on almost EVERY platform in common use, probably on
your C64 too ;-)

I really hate recommending non-solutions to will-be developers. Programming has been reduced
to a moronic arms race. "Technologies" are being pushed, NOT because of their technical merit
and their usability, but based on corporate agenda. I have personally quit the rat race, and
have given up the chase. I decided to learn something solid, something that works, something
that saves me time and ALOT of it, and something I can be proud of. Lisp offers me all of these,
I don't have much time to sit behind the terminal all day. I only have 2 to 3 hours (at most)
for coding, everyday. So, in that short time, I want to do something useful and get results.
Lisp gives me that; I no longer design interfaces and spend days implementing the modules, just
to find them incompatible later on. No, I just sit and type as I think, I can always come back
to refine the spec. The code is executable at the EXPRESSION level, and I am not required to
write stupid templates and empty main() function just to test a few functions.

To make a long story short, coding in Lisp is like having the computer plugged into your brain.
Sometimes, I am surprised at how far I have come in the implementation. I write about 20
functions in an hour, and everything works the moment I am done typing. I never get to notice
the corrections I am making and the period of trial and error.

If you really value your time, if you have a family, friends, a pet, a favorite sports team, etc.
and don't really wanna bother to sit behind the damn console, get a copy of a Lisp tutorial and
download Lisp. You will spend MONTHS going through the tutorials, reference, and the "philosophy"
books. But there will come a point were something will HIT you and you will get everything That is
the moment of zen, and the point of no return. When you reach that step, you will become a Lisper
and end up preaching everyone, trying to tell them the value of what you have found.

You said you are not a developer, so I will not bother telling you about the other technical stuff,
but if a coder is interested in Lisp, but is not sure wether to make the investment or not, then
feel free to ask me. Also, if you have an interesting piece of code that you wanna see implemented,
or if you wanna see how a given solution is implemented in Lisp, then post the spec or the code
and I will write in Lisp. I will not tolerate any perenthesis cliches, show me a piece of code that
looks cluttered with prenths, and I will rewrite properly and show you how it is done in idiomatic
practical Lisp.

Re:cool

[Requiem]

I'd ream you for that, but you know, then I'd have to put my cock in your ass.

Re:cool

[truefluke]

There is one, its called scriptbasic.

http://www.scriptbasic.com/html/index.html

it looks interesting.

Obsolete

[Ramuh]

GNU Emacs already has an elisp module that writes perl cgi for you.
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 /usr/bin/emacs today!

Re:Obsolete

[peterpi]

But I'm 22, which means that even if I'm lucky, I've probably only got about 40 or 50 years left to live.

How could I possibly learn emacs in such a short space of time? ;P

What's (thankfully) missing...

[llamalicious]

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!

Other *nix books for "the rest of us"?

[heychris]

Interesting that this book is mentioned now, as many of the Apple lists that I'm on have a number of questions from Mac admins as to what are the essential books for getting up to speed on all the *nix-y goodness. It sound's like something many on those lists will be interested in.

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"?

[Neil Watson]

Try this thread

Is this a good thing?

[tshak]

...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.

I hope I don't come off as an elitist, but don't we have enough "non-programmers" acting as programmers thanks to the .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?

Re:Is this a good thing?

[nege]

Could you reccomend some books to those folks that are interested in not becomming a bad programmer, if their intention is only to write perl as cgi and db connectivity? I know I would be interested.

Re:Is this a good thing?

[Neil Watson]

However, teaching them the tools first is not going to make them a good programmer.

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?

[bedessen]

A web application is software and should be treated as such.

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?

[tshoppa]

Could you reccomend some books to those folks that are interested in not becomming a bad programmer

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 and Web Pages that Suck, too.

Re:Is this a good thing?

[nege]

Thanks for the info! As someone who does not program for a living, I am very interested in NOT being the subject of complaints from real programmers when one day they have to read my code. I would primarily be responsible for webservers (few) and then all the web design and database stuff for a very small company. I know about sysadmin stuff for the linux servers, but am completely new to programming (outside of shell scripts) as far as applications and design is concerned. This book intrigues me because Perl is exactly what I am looking at to do the cgi stuff (forms processing db connectivity, and some of the other topics mentioned in the post above)

Re:Is this a good thing?

[Anonymous Coward]

>thanks to the .COM boom?

What's .COM? Dot Component Object Model?

Are you implying that a programmer who employs reuable COM components is somehow less of a programmer (even though he or she may have written those COM components themselves)?

Just what are you saying?

Are you any kind of programmer?

Re:Is this a good thing?

[Anonymous Coward]

You don't give web professionals enough credit. Given, there are lots of bad webpages, and bad web designers, but there are lots of bad programmers, as well. The ratio is about the same in both professions/hobbies.

I prefer to think that there are a lot of reasonable, well-educated web designers out there who care about these issues, but for various reasons don't have the time or inclination to get into the nitty gritty details of Perl. I'd like to think I'm one of them..... (though I chose PHP for my web programming). I'm the kind of person who prefers pragmatism over abstraction, but never one to the detriment of the other. A resource like this, had I found it earlier, might have made Perl seem less daunting to me when I first tried to pick it up.

I suspect that the ability to write manageable code is not terribly far from the ability to create usable, relevant, easy-to-navigate, and well-designed webpages. In such a regard, I think solid web designers are more than capable of the task of web programming with such a resource as this.

Re:Is this a good thing?

[absterge]

Yes, it is a good thing. That's me, through and through - I've been begging, borrowing, and breaking code for a long time, in attempts to do the most simple things. I've got a shell account, but I've not used it for much more than hand-wrung HTML; I just want to get up and running in something, like perl or CGI or anything, that will help me accomplish simple things efficiently (I recently spent quite a few hours just trying to kludge together some ~useful page-hit stats, and ended up with very little to show for it).

I read the review, and as soon as I'm done typing this, I'm going to order the book.

Re:Is this a good thing?

[Chagrin]

Would you really rather have them writing Java servlets?

Re:Is this a good thing?

[jbolden]

One of the things that was wonderful from about 96-99 was all sorts of people who had terrific content but didn't know jack about design or programming putting up web pages. Its not so hard to deal with a weak presentation. Its not so hard to download a text heavy HTML page and extract useful information using programming tools. Its very difficult to figure out the answers to many of the complex questions these guys provided on their sites. Everyone is an expert in something, not everyone is a good programmer or a good designer. Getting these people to feel confident enough to go back to putting up sites is IMHO a very good thing.

Re:Is this a good thing?

[reallocate]

Only if all developers stop using HTML.

Re:Is this a good thing?

[Anonymous Coward]

I don't really understand what your talking about?
How is anyone gonna learn something properly if they don't first know the right tools to use to do something. Knowing the tools is like a base knowledge that starts you off in the right direction instead of the wrong one.

You would have done better to recommend a book or something that takes them from just knowing the tools to learning the theory, or practical hands on 101 programming.

I think sometimes people just don't like others to know how they work their magic. So they get mad when someone gives a beginner a powerful set of tools that can be used for good or evil.

Put it this way, the more people understand what good programming is and what good tools are, the more that can all around going Oooh aaah at your super l33t programming skillz.

Re:Is this a good thing?

[Anonymous Coward]

%s/the more that can all around/the more that can all stand around

Baby talk is fine.... until it gets out of hand.

[huper]

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

Will this help with design and usability?

[shoppa]

Will unleashing all these tools on folks who've never dealt with anything more structured than point-and-drool tools like Frontpage really result in better web sites?

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.

Re:Will this help with design and usability?

[Anonymous Coward]

Will unleashing all these tools on folks who've never dealt with anything more structured than point-and-drool tools like Frontpage really result in better web sites?

First of all, "point-and-drool?" I hate Frontpage as much as the next /. elitist, but is this really necessary? I'm not even sure what you mean by it. You imply that Frontpage is unstructered. In what sense?

Will [this] . . . really result in better web sites? . . . Most importantly, will there be any net gain in design and usability?

A net gain in design? Design of what? The web site? The maintainence tools? Usability? Of the tools? Of the site for visitors? What are you getting at?

I don't think this is at all the point of the book. Perhaps "point-and-drool" web designers (as you call them) should read Designing Web Usability

Re:Will this help with design and usability?

[tshoppa]

Power Tools for Power Fools is what I'm worried about. If they're producing bad web pages by hand, they'll probably produce many more bad web pages by scripts.

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?

[dinodriver]

Having more true designers (not frontpage html hacks) that can program would be a big benefit to software development. There are way too many sites and apps out there that function the way they do simply because it was the easiest or cleanest way to program. Sometimes this makes the app easy to use by other geeks, because they can guess how it works, but often it is absolutely horrible to use from the non-geek user's perspective. Even in cases where designers and info architects (anyone still use this job title? ha!) specify something that would be very easy to use often times the programmers will say it's just not possible: often it is possible but the programmers just don't want to do it. If the designers know more about programming, the programmers won't be able to bail out anymore. The end result will be better applications for non-geek users.

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.

cool

[jred]

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 :)

Compare to Hayes auto repair books

[A nonymous Coward]

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?

Re:Compare to Hayes auto repair books

[Art_XIV]

Sweet parody!

Re:Compare to Hayes auto repair books

[Tablizer]

(* 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..... *)

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.

This is a good thing

[ikewillis]

Content development is a great bridge to draw people into the programming world. Web content provides just as much a potential platform for application development as anything else.

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

[prakashj79]

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

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...

[2nd Post!]

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?

Re:Website tools...

[armchairlinguist]

Maybe you need that $700 to pay bills.

Re:Website tools...

[perljon]

$20 an hour... that's cheap. Most people I know how charge for coding perl charge at least $100, if not higher.

Re:Website tools...

[gbroiles]

I'll start by saying I mostly agree with you .. but I think you oversimplify the comparison. Specifically, you ignore the cash flow side of this - does your hypothetical $20/hr developer want to get put on unpaid leave-of-absence for a week because his boss had to pay for a new software package? If not, then the "buy the software" approach costs $700 more than the "write it from scratch" approach, even if the second is less efficient overall.

Re:Website tools...

[2nd Post!]

Well, there's the thought that spending a week learning 'stuff' is a non value add activity.

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...

[Anonymous Coward]

Would you SHUT UP!
I see all these complaints about poorly designed websites and programs... blah, blah blah.
If you're employer doesn't give a shit about you or your quality of work It Just Doesn't Matter.
Take a cue from hardware. DEC Alpha technology is dying, Macintosh is not the dominant desktop platform. "Better" does not pay the bills. GET A CLUE.

Re:Website tools...

[gbroiles]

Hey, maybe you've got lots of cash sitting around cluttering up your brokerage account, such that the difference between $700 and $1400 doesn't look very interesting to you. Feel free to Paypal some over to me.

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...

[Nicolas MONNET]

How much time do you think it would take you to learn to use WebObjects?

1 week?
2 weeks?
2 months?

Re:Website tools...

[consumer]

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?

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...

[2nd Post!]

Your points are all valid, of course.

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...

[denshi]

Ummm.. because WebObjects sucks?

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:

1. The programmers have to learn or brush up on J2EE & Java.
2. They need to learn how to interact with WebObjects, the APIs, the quirks, the bugs, the misfeatures.
3. 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.
4. The administrators need to learn how to keep it up and running, how to tune it, how to get specific logging, etc.
5. 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.
6. 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...

[Anonymous Coward]

*I'll probably be called a flamed for pointing out your flaws but whatever..

Ummm.. because WebObjects sucks?
*Ummm... I've guess you've never have used it huh? :P

Ha, ha, only serious. No, really, work with me here.
*hehe.. yeah lets try...

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?
*How hard is it to copy and paste files? Legacy code is something else :P

Let's see what now has to happen:
*No, lets see what someone who's never used WebObjects thinks needs to happen.

1) The programmers have to learn or brush up on J2EE & Java.
*If they are server side programmers they should know the basics of J2EE by now. Hell I know high school kids that know it. Java is the top language in colleges right now. J2EE just adds more classes :P

2) They need to learn how to interact with WebObjects, the APIs, the quirks, the bugs, the misfeatures.
*Its a J2EE container ergo: you already know the APIs. They are standard through out the entire J2EE Platform, and all other J2EE servers.

3) 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.
*You still don't get the idea of a platform. If the J2EE container doesn't run exactly how its supposed to it CAN'T be called J2EE container, can't be certified, and can't be sold to the public. If you want to hack one there is always Apache's Tomcat + JBOSS, but you should know Java before you claim to be hacking anything. By the way since J2EE is so new they've solved some Enterprise problems in a nice design from the ground up.

4) The administrators need to learn how to keep it up and running, how to tune it, how to get specific logging, etc.
*God forbid they would have to do their jobs huh? Most of those things are one again part of the platform and not just specific to this container. Apple has a good record for easy to use products...

5) 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.
*Why bother reading all the stuff you're not going to use? All the articles on J2EE web servers I've read are simple to read and understand. What kind of retard reads the book when the index points to what you want?

6) 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.
*Funny since you never used it... link?

None of these things are free; you will invest substantial time in learning an app if you go that route.
*Good point. Things cost money, I'll try to remember that. Learning the basics of J2EE is worth the time and money. I'll list my reasons at the end.

Now let's say you have a collection of programmers who
1) prefer things other than Java,
*I guess we know who really runs the company then huh? In java you can ALWAYS call other things

2) aren't afraid of SQL,
*J2EE loves SQL, Apple just added a way to use XML and other technologies to DBs

3) know the web,
*J2EE embodies more than just the web... but it doesn't force you to know the parts that don't.

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.
*sad, sounds like someone isn't going to be moving on to bigger and more interesting stuff within the company. Not that I believe there is something wrong with that. I know a guy that (luckily) loves Cobol, because that's what his company is going to have him do for the rest of his career.

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.
*Thats why you don't want to learn WebObjects, but the portion of J2EE that suits your needs. Then your work is guaranted to work with WebObjects.

*everything below are my comments

I've got a "Managing Information on the Web" certificate from my University. Its a shame those courses weren't teaching it in Servlets/JSP. They are better designed/cleaner/portable/documented solutions (both for small and large projects) than what I originally learned.

Best reason for any company to use java is to standardize to a single language. I'm sure you might think its Nazis-tic or cry "whats wrong with choice?" Having a standard language allows the company to be more dynamic with its workforce, and hardware assets. It can allocate the Java programmers from one platform into other java projects, not possible in other languages. Some languages born and will die in that platform.

I'm not talking about taking a J2ME programmer and assigning him to a J2EE distributed project and expect him to perform as well as everyone else. I'm talking about having a company that has had to lay off employees and because of it calls upon the help of the remaining programmers help in different aspects (probably JavaBeans) of the project.

All that under a language that has great documentation coding-patterns that will allow someone else to pick up and update a project when necessary.

Java is cross platform (you should know this by now!)
I'm constantly using my favorite java apps where ever I am. I'm usually running jBuilder on Linux at home, on Windows at work, and I'd like to buy at Titanium I book one day(apple did an awesome job on their Mac JVM). I wouldn't have to purchase JBuilder again... because the copy that I own runs on a Mac as well. It will also runs on Solaris, but I'm not planning on buying one of those any time soon ;)

J2EE is used in the IT industry almost like a standard for enterprise applications. If you like choices here are 1.3 certified implementations of J2EE:
BEA - WebLogic Server 7.0
Borland - Enterprise Server, AppServer Edition
Computer Associates - Unicenter Management
Fujitsu - INTERSTAGE Application Server
IBM - WebSphere Technology for Developers
Macromedia - JRun 4
Pramati - Server 3.0 & Studio 3.0
SAS - AppDev Studio 2.0.2 Preview Release
SilverStream - eXtend App Server 4.0 Beta
SunTM ONE - Application Server
SunTM ONE - Studio 4
Sybase - EAServer 4.1
Trifork - Application Server 3.1
these are the paid to qualify for certification testing. There are few open source versions out there that are very good.

Remember it's a platform, so they all implement J2EE exactly, making your java code and libraries app server in depended. So if my company was running Apache Tomcat as Apple handed us some Macs and WebObjects we just have to drag and drop the source/libraries to get the page up and running.

I like code, but I don't want to work with servers my entire life. I'm not a Cobol programmer either. I enjoy doing different things with different kinds of platforms. J2ME is going to be taking of soon and I'll be there :D

You'll notice java on most Enterprise IT sites. I hope you understand why they would bother.

Re:Website tools...

[chromatic]

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?

Re:Website tools...

[denshi]

So I can have J2EE in any color I want, as long as it's black?

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.

Re:Website tools...

[Anonymous Coward]

So I can have J2EE in any color I want, as long as it's black?
*Thats a stupid way of looking at it. Its more like you can get any color you want aslong as it's been tested to work on all surfaces.

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.
*You oviously didn't even understand my message if you think java is all I know. My point stands valid and in your reply you didn't even try to hide it. You were bashing a product you didn't have the slightest clue about.
*Thanks for waisting everyones time with miss information. By the way meaty discussions involve facts not BS.

I bought this book a month ago...

[Anonymous Coward]

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!

another "perl for new programmers" book

[consumer]

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.

Re:another "perl for new programmers" book

[Anonymous Coward]

I bought that from a slashdot review and think it's excellent. I've used it to build several small tools and will continue to do so. This one sounds good too but I'm not sure I have the time to read another one at this point.

dead language

[axxackall]

Who cares about Perl? It's gonna dyi anyway soon along with Python. The result of their merge, new language Parrot will be very unstable for awhile, uncompatible to both Perl and Python. So any investment of time, efforts and books to Perl (and Python) will be lost.

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.

Re:dead language

[RollyGuy]

Perl is dead just about as much as C was when Java came on the scene.

Perl will ONLY be dead when people stop using it.

Re:dead language

[PythonOrRuby]

Parrot is not a language, but rather a virtual machine that will act as a runtime environment for Perl6, Python, Ruby, Tcl, Scheme, etc.

Although I suppose you could be talking about Parrot assembly language.

Re:Perl?

[perljon]

I beleive that after 100 lines of perl code, no matter how cleanly written, all the source will become unmanagable.

That's why you're pretty much useless, and noone listens to you when you talk

As Jamie Zawinski said:

[Wakko Warner]

"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.

Re:As Jamie Zawinski said:

[warpSpeed]

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.

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:

[Darby]

How long will it take you to learn WebObjects and be able to realize the $700 software investment in saved time.

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:dead language - April fools joke

[Anonymous Coward]

Parrot huh? I hope you're joking because this was an April fools joke from a year ago.

Re:My 2 cents

[Anonymous Coward]

That wasn't a troll. It was a joke. Overzealous moderators again I see..

re: Abstraction

[Tablizer]

(* 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)

Re:Dumb Question

[Anonymous Coward]

No, but I *would* pour myself down a naked and petrified Natalie Portman's pants.

Re:dead language - April fools joke

[Anonymous Coward]

What joke? This page is official, isn't it?

Re:Perl?

[Anonymous Coward]

Seeing as you can't even write a simple sentence
I'd expect Perl to be a major challenge for you.

Syntax and grammar do matter.

Everything is Dying

[Tablizer]

(* 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.

Re:Everything is Dying

[Anonymous Coward]

> 2. LISP - Never popular but never dead.

Lisp never popular? You weren't a software engineer in the 80s were you?
No, I am not talking about DOS Turbo Pascal monkeying, I am talking about
doing software development that matters. Lisp carried the cutting-edge-technical-development
of the 80s on its shoulders. Everything, from graphics research to robotics, was done in Lisp.

> While other languages tend to exaggerate and get carried away with the fads of their day
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.

Your sense of a programming langugage being "carried" away, only shows the dotcom what-will-sell
"developer" you truely are. You are busy outguessing the future and trying to figure out which *tool* will be best for the future, and not which *idea*.
You are still busy evaluating your tools, because you have never been able to customize and/or build
your own.

> 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.

Oh my my, you have just shot yourself in the foot and trashed your argument.

Lisp was the first language to include conditionals ("if else then") and it allowed structured
programming BEFORE the grand mommy of sturctured programming (algol). Lisp predates Object Oriented
Programming, and it was the first language to fully support all of OOP's requirements (it actually
got some certification from some OOP body, don't remember which) Lisp supports all sorts of psuedo-methedologies out there
and all sorts of FUTURE development methods and practices, because Lisp is highly flexible.

You can either learn compiler construction by heart, grok all sorts of parsing algorithms,
semantic analysis algorithms, code generation and optimization, learn about your host machine
and OS inside out, and write a compiler for EVERY feature you need or customize (read, "maintain)
an existing OSS compiler that has your facilities, OR you can learn Lisp.

Lisp hackers are compiler authors on steroids. They have the power of a compiler construction
team (for free) and do it in a fraction of its time. If the PC was programmed in LISP, Microsoft
would never have been able to shaft the competitors of its applications division, by having backdoor access to the system compiler.
The competition themselves would have been able to peek at the compiler and improve on it, until it
meets their needs, and It could have been a fair fight.

> It was born in the 1950's as a math-like experiment
> and was not originally meant for application building.

Please point out ONE computing tool or concept, that was NOT born as a math experiment or is not strongly ground by mathematics?

Look around you, no matter how much you try to run away from it, programming is still a mathematical excercise. Don't be a coward, face your problems.

Re:Everything is Dying

[Tablizer]

(* Lisp never popular? You weren't a software engineer in the 80s were you? Everything, from graphics research to robotics, was done in Lisp. *)

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:Baby talk is fine.... until it gets out of hand

[alienmole]

Have you ever been asked to clean-up really bad perl? Many times "clean-up" is a total re-write.

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:dead language - April fools joke

[Anonymous Coward]

Old April Fools Hoax

hmm... what!?

[Ender Ryan]

I fail to understand your logic. Buying some off-the-shelf program for maintaining your website, and learning to program so you can maintain, modify, create, etc. your website on your own aren't even close to the same thing. I have never seen something off the shelf that will provide everything this book covers.

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!?

[2nd Post!]

Do you know what WebObjects is?

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.

man perl?

[theolein]

What's wrong with man perl?

Perl security

[Anonymous Coward]

www.cgisecurity.com/lib

Ack! You'll Slashdot the book!

[bwalling]

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.

Re:Baby talk is fine.... until it gets out of hand

[PythonOrRuby]

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;

Too bad ...

[Anonymous Coward]

it wasn't "Python for Web Site Management".

Re:Baby talk is fine.... until it gets out of hand

[alienmole]

I'm fully aware that Perl "allows for" that kind of code. The words I used were "helps you write". Perhaps I should have said "encourages you to write". I responded to the poster about the "baby talk" because I've seen this phenomenon repeatedly: people who've developed bad code because the language doesn't discourage them from doing so.

One more book to buy

[ellem]

When you finish this one pick up:

MySQL and Perl for the Web
Paul DuBois
New Riders

It is an exellent book.

Re:One more book to buy

[fliplap]

Note: your quote from the Simpson's episode "Sweet and Sour Marge" is slightly incorrect. The correct quote is:

"...While we're at it: Why don't I just change my last name back to Hitler?" -- Garth Motherloving

Compare to MP3.com

[sulli]

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?

Re:Baby talk is fine.... until it gets out of hand

[PythonOrRuby]

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.

Re: Abstraction

[CaptainEcchi]

(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!

Re:Baby talk is fine.... until it gets out of hand

[alienmole]

Certainly, you can write bad code in any language. But I've seen more bad code in Perl than any other single language. I attribute this to a few things, and one of them is the baby-talk issue raised by the original poster.

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 is missing

[Not The Real Me]

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.

Re:Chapter 22 is missing

[Anonymous Coward]

Ah ha ha ho ho ho tee hee hee. How original. What a wit. A regular raconteur.

Re:Perl vs. PHP - No - PYTHON

[Anonymous Coward]

Python would be a far better language for a complete newbie.

Perl DIY vs WebObjects

[2nd Post!]

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?

Re:Perl DIY vs WebObjects

[jbc]

My own take on this, for what it's worth, is that at least in the early days of the Web, DIY with Perl was a far superior solution for almost everyone, since the commercial alternatives were few and lame. Over time that balance is clearly going to be shifting in favor of the commercial tools, since the commercial vendors will have had time to identify the features that their customers really need and to deliver those features effectively.

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

Perl and Complexity

[namespan]

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.

Re:Perl and Complexity

[jbolden]

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 ...) because they have grown up with the technologies tend to be the most popular languages, they tend to be the best supported and they tend to be the most difficult to gain fluency in.

Re:Baby talk is fine.... until it gets out of hand

[PythonOrRuby]

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
}
}

Re:Baby talk is fine.... until it gets out of hand

[alienmole]

The quick hack you mentioned isn't the sort of thing I was thinking of, and in fact is possible without requiring special syntax in any language that supports closures, e.g. the Scheme for it would be (map (lambda (s) (display s)) foo). A lambda-lifting compiler can optimize that nicely. Nothing wrong with code like that, although it's perhaps a bit messier and less general in Perl :)

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

[PythonOrRuby]

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.

Re:Baby talk is fine.... until it gets out of hand

[alienmole]

You'd be amazed the amount of programming theory you can soak up reading through the perl6 mailing lists. :-)

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.

Sheesh.

[Anonymous Coward]

Apparently you haven't found the spell-check option in emacs... once you do, try running your signature through it.

Are you -insane-?

[strombrg]

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.

Re:Baby talk is fine.... until it gets out of hand

[PythonOrRuby]

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.

this book is good......

[RestonVA]

for me to poop on

Comment removed

[account_deleted]

Comment removed based on user account deletion