in reply to ISO technical document outlining system requirements for Perl

Perl has been ported to at least 60 (100+?) different operating systems, including (as mentioned above) PalmOS. In every case, the same basic functionality exists. (Obviously, if forking isn't supported on the OS, then you can't have fork work in Perl, and the like.)

As for requiring a dedicated server - it all depends on what you're doing. Perl itself is very fast, compared with VB. However, because you can do some really complex things in Perl very easily, it can be very ... dominating. Most commerical uses for Perl do require their own servers. Not because it's Perl, but because the application built in Perl has requirements. (Report servers, e-commerce apps, etc)

I would recommend doing at least one of the following steps:

  1. Download and install ActivePerl on your desktop. Play with it and get a feel for the requirements of what you're doing. In many cases on Windows, using WScript, JScript, and/or VBScript may be more appropriate.
  2. Talk to your manager. If you're asking the question, you probably have been asked to do something by your manager.
  3. Bring in a Perl consultant to discuss the issue. Sysadmins are trained to be very conservative. Remember, it might be your application that's causing the server to slowdown, but it's his job. (There are old sysadmins and bold sysadmins, but there are no old and bold sysadmins.)

Oh, it's not a Perl compiler - it's a Perl interpreter. Perl compilers are different beasts.

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

  • Comment on Re: ISO technical document outlining system requirements for Perl

Replies are listed 'Best First'.
Re: ISO technical document outlining system requirements for Perl
by Abigail-II (Bishop) on Mar 03, 2004 at 21:27 UTC
    Oh, it's not a Perl compiler - it's a Perl interpreter. Perl compilers are different beasts.
    The beast I have in /usr/bin/perl compiles Perl, and has no idea how to interpret Perl. One could say /usr/bin/perl is interpreting the results of the compilation of Perl, but that's not what's usually understood by interpreting.

    /usr/bin/bash is an interpreter. /usr/bin/perl isn't.

    Abigail

[reply]
      /usr/bin/perl compiles Perl to opcode, then interprets those opcodes. From a black-box view, it's interpreting Perl, regardless of how many internal steps it takes to get there.

      This is opposed to the black-box view of gcc, which solely compiles C into the opcodes (or ASM) for the OS it's targeted to compile to.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]
        From a black-box view, it's interpreting Perl, regardless of how many internal steps it takes to get there.
        That's silly. That would mean that 
            #!/bin/bash
    gcc -o blabla program.c
    ./blabla
    rm blabla

        [download]
        is a C interpreter.

        I've never heard of a definition of an interpreter as "a compiler that directly executes the code it generates".

        Abigail

[reply]
[d/l]
      I thought /usr/bin/perl did both. First it compiled the program in to opcodes or something, then it interpreted them?
[reply]
[d/l]
      A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom