Nothing wrong with reimplementing wheels for pedagogical practice so long as you're aware that's what you're doing.

As far as module ideas, some of the questions here can provide interesting things to poke at (e.g. Challenge: Generate a glob patterns from a word list recently). Or if you're of a mathematical bent maybe something like Project Euler problems. Working through some more general CS problems in SICP or code katas might be another thing to try.

Great, I'll try to do it.

Can you please answer one more question. I thought about what you wrote above: "Output to STDOUT". Do you mean to use "print STDOUT smth" instead of "print smth"?

If you omit the filehandle argument in print, it will default to the last selected filehandle.

Unless you change it, you can expect the current filehandle to be STDOUT. In most cases, print @list and print STDOUT @list mean exactly the same thing; the STDOUT is typically omitted.

You probably won't need to do it very often; however, if you do change the filehandle (with select) you should keep track of the old filehandle, as you'll often need to restore it.

Here's a short script, with output file contents, to demonstrate:

$ perl -e '
    print "Expecting STDOUT\n";
    print STDOUT "Specifying STDOUT\n";
    print STDERR "Specifying STDERR\n";
    print "Current filehandle: ", select(), "\n";
    my $orig_fh = select STDERR;
    print "New filehandle: ", select(), "\n";
    print "Expecting STDERR (after select STDERR)\n";
    select $orig_fh;
    print "Original filehandle: ", select(), "\n";
    print "Expecting STDOUT (after select \$orig_fh)\n";
' 1> x.out 2> x.err

$ cat x.out
Expecting STDOUT
Specifying STDOUT
Current filehandle: main::STDOUT
Original filehandle: main::STDOUT
Expecting STDOUT (after select $orig_fh)

$ cat x.err
Specifying STDERR
New filehandle: main::STDERR
Expecting STDERR (after select STDERR)
[download]

— Ken

No that's to do with how I usually run perltidy as a filter from emacs and want it to simply print out the tidy'd contents rather than rewrite based on the the input file directly. From the docs:

    -st, --standard-output
        Perltidy must be able to operate on an arbitrarily large number of
        files in a single run, with each output being directed to a
        different output file. Obviously this would conflict with outputting
        to the single standard output device, so a special flag, -st, is
        required to request outputting to the standard output. For example,

          perltidy somefile.pl -st >somefile.new.pl

        This option may only be used if there is just a single input file.
        The default is -nst or --nostandard-output.

    -se, --standard-error-output
        If perltidy detects an error when processing file somefile.pl, its
        default behavior is to write error messages to file somefile.pl.ERR.
        Use -se to cause all error messages to be sent to the standard error
        output stream instead. This directive may be negated with -nse.
        Thus, you may place -se in a .perltidyrc and override it when
        desired with -nse on the command line.

The cake is a lie.
The cake is a lie.
The cake is a lie.