It was thus said that the Great David Cantrell once stated:
> On Sun, Dec 17, 2006 at 09:36:52PM -0800, Aaron J. Grier wrote:
> 
> > this is exactly what I hate about perl.  "there's more than one way to
> > do it" invariably means that some dumbfucks out there will attempt to do
> > it every single way possible in the language.  perl apparently prides
> > itself on this.
> 
> A general purpose language which can't be used in different ways to
> solve different problems is not fit for purpose.  Are you proposing that
> programming languages should be rigid and unsuitable for a wide range of
> tasks?

  Um ... <raises hand> ... I'd like somethimg a bit more consistent.

  A typical programic idiom I use (when programming in C) is:

        if (argc == 1)
                do_some_process(stdin);
        else
        {
                for (i = 1 ; i < argc ; i++)
                {
                        input = fopen(argv[i],"r");
                        do_some_process(input);
                        fclose(input);
                }
        }

  So imagine my surprise when:

        if (scalar(@ARGV) == 1)
        {       # the one bit of consistancy I can do without actually
                &do_some_process(STDIN);
        }
        else
        {
                for ($i = 1 ; $i < scalar(@ARGV) ; $i++)
                {
                        open INPUT,$ARGV[i];
                        &do_some_process(INPUT);
                        close INPUT;
                }
        }

  Doesn't work at all.  Problem one (remember, I come from a C background
here), $ARGV[0] *doesn't* contain the program name ($ARGV isn't right since
it's only defined when using <ARGV> apparently---lovely), so okay, I adjust
some numbers and it *still* fails because you can't pass file handles to
subroutines.

  Only, it seems like you *can* but only if you use the *obvious* notation

        open INPUT,$ARGV[i];
        &do_some_processing(*INPUT);
        close INPUT;

  Never mind the fact that every @#...@#$ variable in Perl is preceeded by a
'$', '@' or a '%' *except* for filehandles, diretory handles and block
labels.

  Yes, C has its quirks too, but at least there I can actually pass any type
of variable to a subroutine without having a special notation for a certain
class of variables.

  -spc (And least you think otherwise, there's plenty to hate in C, but I'm
        afraid I've lived with it long enough to subconsciously work around
        its quirks ... )

Reply via email to