Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Maybe it's because people who use PHP probably don't realize that it sucks, and others are thankfully spared the experience, so they don't feel a need to complain publicly.

    • We shouldn't discount or try to explain away what people think. My guess is that PHP doesn't suck for a lot of people, which is why a lot of people (relatively) do not say that it sucks.

      If we find out why, rather than treating the datum as an outlier, we can apply what we find to Perl.

      For instance, several different people have told me that the PHP core documentation is organized better and available in other languages.

      A lot of other people have also told me that the PHP documentation is more pragmatic,
      • Perhaps Perl needs better CGI specific documentation. Perl, being a general purpose language, has a broad range of problems it can be used for. PHP, baring the mutant server-side version, is a CGI-only language. It is a lot easier to write documentation for PHP that tells users how to process CGI args, maintain session state, read client environment variables than to do the same for Perl, for which there are a great many ways to do it (and more are invented everyday). There are reams of paper dedicated to P

        • What happens when you type perldoc perlcgi? Nothing. My point exactly.

          Maybe someone should write a manpage-length introduction to programming CGI with Perl and Apache that could be included in the core distribution. It could show the "right" way to do things (taint, strict, and without having to comprehensively cover all of the alternatives. It could show how to accomplish common tasks. It wouldn't have to follow the usual maxim of, "That's a CGI issue, not a Perl issue, so it doesn't belong

          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
          • "it could show the "right" way to do things (taint, strict, and "

            Maybe, but there are a lot of arguments even at that level. Do you use CGI to write your HTML? I, and a lot of others, consider that a bad practice, mixing code with HTML. Others, including a number of very talented programmers, feel differently.

            So how do you document even a hello world cgi script? Do you teach them with CGI's commands, heredocs, outside files, or perhaps one of the many templating systems?

            Sure, it's just a simple demo, but you're trying to encourage good behavior, and while we can agree on some bad behaviors (see your list), there are others that arise immediately that are still debated.

            TIMTOWTDI, and while that's a great thing, the different philosophies behind them make even a simple script a heavy debate.

            Of course, a document showing the major DIFFERENT ways to address, say, a "hello world", a form->email script, and a database search, would be awesome, it'd be quite a task to take on, and require some very skilled writing to keep clean.

            Hmm. Perhaps perlcgi could just offer "DO NOT" list, plus mention the benefits/drawbacks to the different instruction sets, followed by a list of more detailed docs foreach one ala perldoc perl?

            • The nms project at SourceForge is doing a good job of creating some quality examples of common CGI applications. Perhaps the perldocs should reference that collection of software.