Thank you for pointing out those problems with that tutorial to me. It had me hooked with the magic words of "web development" and by the way it looked.

Then don't be fooled by shiny little thingies. Be cautious. Of course it's fine to learn something bad to be corrected and turn it into the good version of it. But it's even better to learn it right from scratch.

I didn't look at it as closely as you did.

Chances are you wouldn't have known anyway, since you're admittedly a newbie. That's why I was warning you.

It is hard to find a Perl site that is geared specifically for web development.

It is very easy to find "Perl sites" that are geared specifically for web development. Far too easy. It is very hard to find good ones.

I read that article on AJAX, and I will probably not use it as I have no XML on my site.

I was not suggesting you to use AJAX. Nor is it the case that you have to "have XML on your site", there are quite a lot of JS libraries for this which will handle the "dirty" job under the curtain for you, and perl modules which provide "bindings" into those.

I will also only use javascripts written by others as the last time I tried writing one on my own, I blew it big time since javascript is so bloody difficult.

While I only touched upon JS and never wrapped my head around it, overall I would regard it as a much simpler programming language than Perl. (Of course it can be hard to know object hierarchies and such...)

Could you possibly point me to a page here or elsewhere that will show me the different ways a Perl script can be indexed?

Huh?!? Perl scripts are not indexed. Perhaps the pages they generate. I think you just want to learn about robots.txt and the robots meta-tag. Then, just ask Google.

I wondered what Perl means. Win is short for Windows, is Perl short for something?

The story is narrated elsewhere, but in some sense it is short for pearl.

You are right about Perl being a pain in the rear to use at times, but it is much easier than javascript.

I was not claiming nor implying that Perl is a PITA either at times or on a regular basis. Incidentally as I wrote before I consider it to be more complex than JS. But what's more important (in their typical usages - to which you're referring to now) is that they serve two different purposes, at two different ends of a medium.

File extensions requirements may be a relatively new to those reading that tutorial. With html, one could use .htm or .html, so a singular file extension requirement may trip up newcomers. The file names without spaces thing baffles me as much as it seems to be baffling you.

Huh?!?

As for the use statements at the beginning of Perl scripts. They are not required to make a script work as far as I can tell.

We recommend people to adopt those particular use statements in quite about any script beyond the level of a bare oneliner: CGI (and more generally, web-oriented) scripts do not make an exception. If you want to ask perl all the help it can give you not to make trivial errors then it will; if you don't... well you're on your own.

The use of use strict is like choosing between using html or xhtml and between transitional *html and strict *html. If one doesn't want strict, one shouldn't have to put it in their script.

Poor but somehow appropriate analogy. With the important difference that Perl's strictures reduce your freedom by enforcing good programming techniques that will likely prevent you from making typical programming errors: which is a great help to trade for those lost degrees of freedom. If one doesn't want strict, then she's on her own again. But she should also know that when posting code for help, people will point out that enabling strict and warnings would have allowed her to find the problem in the first place.

Turning on warnings for web scripts is mostly a waste of space if the warning messages don't get through to the programmer.

I'm quite confident that they're in the logs. But most importantly, one should first try the scripts on a shell, then upload them when reasonably sure that they're error and warnings free. (Of course in real world one can rarely be.)

For me it is a fluke if I get a warning with the following in my code.

use CGI::Carp qw(fatalsToBrowser);
[download]

That won't show warnings in your browser. Only fatal errors. Thus I presume that making all warnings fatal errors with:

use warnings FATAL => 'all';
[download]

would work. But even with this I stress that one should test the script on a shell first. And in any case use CGI::Carp qw(fatalsToBrowser); is nothing but a tool useful during development, but I'd rather take it out for "production".

For simple scripts, scalars will (generally) hold only numbers or strings. So, for the simple programmer, that's all that (IMO) they need to know to start. Don't bog the newbie down with too much all at once.

You wrote the magic world yourself: generally! it would have been enough if they also wrote it, perhaps in parens as you did: IMNSHO it wouldn't have been to "bog the newbie down with too much."

Newbies probably wouldn't know what interpolation or concatenation is. Even I have a hard time figuring those out. I have a small clue about what those words mean but still have to look them over and over again.

Huh?!? You must be joking? Whatever, my point is being exactly that just because newbies probably don't know what interpolation is, they should be told. The tutorial, instead, uses it without even explicitly explaining what it is!

I was thinking that it might be a good idea to start a node specifically on what Perl sites to avoid. I am sure that there are other sites out there that are just as bad or worse than the one we have been discussing. That one and others could be highlighted here, and when a person is searching Google, that node made come up towards the top. In regards to Perl searches, Perl Monks is always near the top. You should take your write-up about that site from this node and start another one just about these bad sites.

Let's drop that AJAX and javascript topic. It is moot as of this moment anyway.

As for the rest, I am sorry if there were places I lost you. I was probably tired when I wrote it, as I am tired now. I would probably lose you some more.

Thank you for all of the information you gave me.

Lady Aleena

"An it harm none, do as ye will."

I was thinking that it might be a good idea to start a node specifically on what Perl sites to avoid.

I think it's hardly doable since a "Perl site" in your acceptation is quite about any random site that may deal with Perl. There are just too many of them. Of course one may think of at least create an "Hall of Shame" with a hit of the very worst, possibly along with some comments. However I can't see a terrible usefulness in this either, since the sites we're talking about are those that may pop up following a random Google search and the kind of people who may easily be fooled by them are highly improbable to check the HOS first. But if anyone has his or her entry to contribute, I think it will be ok. At your request, I'll move the "main body" of the post in which I commented some of the site's text to a new meditation.

I am sure that there are other sites out there that are just as bad or worse than the one we have been discussing.

There are certainly much worse ones.