Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Perl's Bad Ideas

by japhy (Canon)
on Apr 05, 2002 at 17:43 UTC ( [id://157002]=perlmeditation: print w/replies, xml ) Need Help??

Perl isn't perfect. We know that. But I feel like pointing out a gripes of mine with the language as it stands.

The $#var syntax. This is a bizarre variable related to @var, although no subscripting is involved. In my Perl, $#var would not exist. If it did, it would be length($var), @#var would be (@var-1), and %#var would be scalar(keys %var). I can't see $#var existing in Perl 6, since arrays will always keep their @.

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker, who'd like a (from-home) job
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

Replies are listed 'Best First'.
Re: Perl's Bad Ideas
by Dominus (Parson) on Apr 06, 2002 at 00:53 UTC
    My candiates for Perl's Worst Ideas Ever:

    3. $/, $\, $", and $,.

    Every single function in every single module in the world has to begin with local ($/, $\, $", $,) = ("\n", "", " ", ""); if it wants to be able to print stuff out and actually emit the data it thought it was emitting. Plenty of modules don't do this, and as a result they do something deeply bizarre if you use them in a program that's run with perl -l.

    2. open FH, $file instead of $fh = open $file.

    Using bareword strings as filehandles was a huge error because it means that filehandles are global variables; it also means that you can't pass them to functions or store them in data structures in a normal way.

    Note that changing this would also fix the "comma after filehandle" problem that YuckFoo complains about in another message in this thread, so this problem is a superset of that one.)

    1. Implicit conversion of references to strings. Terrible, terrible idea. The 'benefit': It's easy to print out references---which is hardly ever useful anyway. Another 'benefit': You can compare references with eq---but it would have been more efficient to use == instead. The cost: Horrible, horrible bugs where some piece of code goes and silently stores all your data in the array named @{"ARRAY(0x436d1d)"} and then you never find that data again. Or you can use strict 'refs', which means that instead of a silent bug, the program drops dead at run time 1000 lines away from the place that actually committed the error. If references didn't turn into strings in the first place, you wouldn't need strict 'refs' at all; you could throw it away at no cost. (A side benefit might be that people wouldn't be so superstitious about using symbolic references when they were appropriate.)

    Perl could have provided a special stringify operator for those rare cases when you wanted to use a reference as a hash key or something. It wouldn't have been hard to provide an extension module to do this.

    Compared with these three, I don't think $#array even registers on the scale.

    --
    Mark Dominus
    Perl Paraphernalia

(jeffa) Re: Perl's Bad Ideas
by jeffa (Bishop) on Apr 05, 2002 at 17:59 UTC
    maverick was the one who introduced me to that syntax back at my first job with him. That particular syntax gets even hairier when trying to get the the last index number from an anonymous data structure. In fact, it borks the otherwise robust vim sytax highlighting:
    
    #!/usr/bin/perl -lw
    
    use strict;
    
    my $thingy = {
        array => [qw(foo bar baz)],
    };
    
    # am i a comment or code?
    print $#{$thingy->{array}};
    
    

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    B--B--B--B--B--B--B--B--
    H---H---H---H---H---H---
    (the triplet paradiddle with high-hat)
    
Perl 6 will make amends (was:Perl's Bad Ideas)
by TheDamian (Vicar) on Apr 07, 2002 at 00:20 UTC
    Thanks for this highly useful thread.

    I'd just like to point out that Perl 6 addresses almost every one of these dislikes (and even a few of clintp's favorite things):

    The $#var syntax
    Gone in Perl 6. It becomes @var.end or @var.last (probably the former, though I used the latter in E4).
    Ranks right up there with $[
    Gone in Perl 6. Replaced by an overloaded FETCH method on individual (or classes of) array-like objects.
    no commas are allowed after the filehandle
    As Dominus explained, using the comma isn't really a viable option. But whitespace as the syntactic marker for indirect objects probably wasn't the best choice either, in hindsight. Hence the use of the colon for that role in Perl 6.
    $/, $\, $|, $", and $,
    Gone in Perl 6. Replaced by methods on individual filehandles.
    open FH, $file
    Gone in Perl 6. Dominus gets his wish; it becomes $fh = open $file.
    Implicit conversion of references to strings.
    (Probably) gone in Perl 6. You'll need to explicitly stringify (using unary _).
    v-strings
    I don't know if Larry has considered their disposition yet.
    pseudohashes
    Gone in Perl 6. And going in Perl 5, for that matter.
    $ used on single elements of hashes and arrays
    Gone in Perl 6. Perl 6 variables never change sigils.
    <> globbing
    Gone in Perl 6. Use glob.
    $;
    (Probably) gone in Perl 6. Though the functionality might remain (as a per-hash or per-class method).
    Symbolic references
    Staying in Perl 6.
    Perl's laissez faire approach to OO.
    Staying in Perl 6. But being augmented by a second, B&D, OO mechanism.

    BTW, those who are complaining are, for the most part, neither grinding axes nor bondage freaks. They are generally people with large commercial OO production systems to build, who would prefer not to have to jump through so many hoops to get compile-time checking, declarative attributes, pre- and post-conditions, strong encapsulation, etc. That is, they genuinely need all those valuable, scalable OO tools that Perl 5's laissez faire approach to OO trades off.

    Punctuation.
    Staying in Perl 6. But being simplified (e.g. sigils) and rationalized (e.g. fewer global punctuation vars).
    Built-in networking and IPC functions
    Staying in Perl 6. But becoming automagically loaded when used rather than bloating the core. (Hey, you want to be able to run perl on your Palm Pilot, don't you? ;-)
    eval $string
    Staying in Perl 6.
    Globs
    Gone in Perl 6. Every symbol has its own entry in some symbol table.
    package variables.
    Staying in Perl 6. And augmented by a third storage type: truly global variables.
    local
    Staying in Perl 6. Though the name isn't, since it just confuses people.
    Punctuation variable names.
    Staying in Perl 6. Though there will be fewer of them, and they'll be lexicals, not globals.
    The entire approach to sockets in perl
    I don't know Larry's thinking on this as regards Perl 6, except that the socket functions will also be autoloaded on demand, rather than mooching around the core. The interface certainly could do with some additional Perlification though...and some documenting.
    chop
    Very probably gone in Perl 6.
    chomp
    Possibly gone (as an independent function) in Perl 6. But Yuckfoo's wish is certainly granted: filehandles will be able to autochomp.
    scalar @var
    Evolving in Perl 6. Only returns the count in numerical contexts (but use of explicit @var.length encouraged instead). In non-specific scalar contexts, returns a reference to the array.
      Seeing everything is a closure, is the statement part of a conditional in the same block as the body itself?
      # For example while (my $el = pop @els){ # Body of loop } # Is it equivelant to this? { my $el = pop @els; { # Body of loop } } # Or this? { my $el = pop @els; # Body of loop }


      -Lee

      "To be civilized is to deny one's nature."
        ...is the statement part of a conditional in the same block as the body itself?

        No, the conditional is outside the block, both physically and logically (err...physiologically? ;-).

        Your example is equivalent to:

        my $el; while ($el = pop @els) { # Body of loop }

        BTW, in Perl 6, if and while (and the rest of the control structures) can be thought of as built-in functions. As if they were:

        sub while (BOOL $condition, &closure) {...} sub if (BOOL $condition, &closure) {...}

        That's why the conditional is not part of the block: it's an entirely separate argument to the control structure.

        And, yes, you'll be able to get the signature (a.k.a. prototype) of a control structure, and overload it, and redefine it (lexically).

        And you'll probably be able to write bad things like:

        if condition(), &call_me;

        and worse things like:

        &debug := { if BEGIN{$debug}, &^action }; # and later... debug { print "here" }
      v-strings
      I don't know if Larry has considered their disposition yet.
      *whisper*Banish them... they were a terrible hack... develop a general purpose mechanism instead of this abomination...*whisper*
      Perl's laissez faire approach to OO.
      Staying in Perl 6. But being augmented by a second, B&D, OO mechanism.

      BTW, those who are complaining are, for the most part, neither grinding axes nor bondage freaks. They are generally people with large commercial OO production systems to build, who would prefer not to have to jump through so many hoops to get compile-time checking, declarative attributes, pre- and post-conditions, strong encapsulation, etc. That is, they genuinely need all those valuable, scalable OO tools that Perl 5's laissez faire approach to OO trades off.

      I've built several large (some very large) commercial OO production systems and never found Perl's OO lacking in any significant way. (For that matter I've built effective OO systems in C as well!) Most of the nits you listed can be solved with good design and mild discipline by the programmers. No whips, chains, or leather required.

      Personally, if I can use Perl's OO as I currently do I'll remain happy as a pig in mud.

        I've built several large (some very large) commercial OO production systems and never found Perl's OO lacking in any significant way.

        Well, sure. But not everyone is as smart, or as disciplined as you. And even if they were, many of them work in large programming teams with other people who certainly aren't as smart, or as disciplined as you.

        Such people really appreciate tools (and whips and chains) that make life simpler.

        Personally, if I can use Perl's OO as I currently do I'll remain happy as a pig in mud.

        Then you'll be wallowing contentedly for many years to come.

        On the other hand, I suspect that you'll also come to appreciate how much easier and quicker Perl 6 makes it to build classes. And that eventually you may even enjoy the whip of design-by-contract or the chain of proper encapsulation.

        C'mon! You know you want to! ;-)

      $/, $\, $|, $", and $,

      Gone in Perl 6. Replaced by methods on individual filehandles.

      All (sniff) good things must come to a (sniff) end eh?

      Ill miss those ones I tell yah. Its sad to see such friendly variables consigned to the waste basket of history... Sniff.

      Globs

      Gone in Perl 6. Every symbol has its own entry in some symbol table.

      Thank you thank you! Ive been working on a new dumper module recently and those dang globs caused my code size to go up by about 30%.

      Yves / DeMerphq
      ---
      Writing a good benchmark isnt as easy as it might look.

Re: Perl's Bad Ideas
by RMGir (Prior) on Apr 05, 2002 at 17:58 UTC
    Yup. Ranks right up there with $[ (the array base index variable)...

    In fact, if you didn't have $[, you probably wouldn't need $#var...

    $ perl -e'@a=qw(a b c); print "$#a\n"; $[=3; print "$#a\n"' 2 5
    Yuck.
    --
    Mike
      Well, I thought that $[ was deprecated, or as perldoc perlvar puts it: "Its use is highly discouraged.".

      So I guess that one will be gone soon at least... :)


      You have moved into a dark place.
      It is pitch black. You are likely to be eaten by a grue.
Re: Perl's Bad Ideas
by clintp (Curate) on Apr 06, 2002 at 01:41 UTC
    Wow. $#arr is mild. How about:
    1. v-strings. Horrible idea, badly implemented, and the cause of many unforseen consqeuences. TIMTOWDI gone stupid.
    2. pseudohashes. Another bad idea implemented poorly. The actual usefulness of these is minimal, and places where they can be used *correctly* are usually contrived examples. More TIMTOWDI gone stupid.
    3. global $|, $/, $\, etc.. instead of per-filehandle.
    4. I agree with Dominus about strigified references. Although I admit to printing them just to see what's inside sometimes... that could be fixed by tinkering with print instead of strigifying things. Laziness gone horribly awry.
    5. $ used on single elements of hashes and arrays.
    6. <> globbing
    And probably more that I can't think of at the moment, it's been a long week. For a *real* thread-burner, ask me about those features of perl that I *adore* that everyone else hates. :)
      Says clintp:
      For a *real* thread-burner, ask me about those features of perl that I *adore* that everyone else hates. :)
      OK, Clinton. What feature of Perl do you adore that everyone else hates?

      For me, $; is probably near the head of the list. Or maybe symbolic references.

      --
      Mark Dominus
      Perl Paraphernalia

        • Perl's laissez faire approach to OO. Most people bitch and moan about it for one reason or another, but I like being able to be as OO as I want to be... or not. It's just so damned easy to do exactly what I want, I figure those that complain are either grinding axes or bondage freaks.
        • Punctuation. I love punctuation. It doesn't look like programming without the line noise. Do this, don't do that, can't you read the signs?
        • Built-in networking and IPC functions. This is what turned me on to Perl in the first place (and scarred me for life from TCL). We don' need no steeeenkin modules.
        • eval string
        • Globs. They're fun to say. GLOB GLOB GLOB GLOB GLOB. And they're fun to use.
        • package variables. It seems everyone's got a hard on for lexicals. my() this, my() that. Sounds like a bunch of three year olds. Gimme a namespace and chuck use strict and I'm happy. /me hugs local() too
        • Punctuation variable names. Wait. That goes with my punct fetish.
        More later...
      3. I personally don't hate these. Once you learn to scope your variables (and these can be a great motivator to learn). OTOH I can understand the desire for per-FH, but it seems like globally settable *defaults* might be nice.

      5. *sigh* yeah the sigil thing is hard on beginners, now however I am not happy about having to switch back... In some ways it does make sense as well, $ is scalar and you're getting a single element (scalar) out. Slices use @ denoting multiple elements returned.

      6. Why? Implementation, or too much for one operator?

      --
      perl -pe "s/\b;([st])/'\1/mg"

        Says belg4mit:
        6. [ <> globbing was a bad idea ] Why? Implementation, or too much for one operator?
        Too much semantics on one piece of notation. If Larry hadn't unnecessarily overloaded <> to do globbing, then you would be able to write
        @array_of_fhs = ...; my $line = <$array_of_fhs[37]>;
        Which you can't presently do, and which frequently trips people up. Without the glob overloading, this would have meant just what it appears to.

        --
        Mark Dominus
        Perl Paraphernalia

Re: Perl's Bad Ideas
by demerphq (Chancellor) on Apr 05, 2002 at 18:34 UTC
    Just a thought but about the only time I use that is when looping over the indexes of an array. Since perl6 (iirc) will have a way to do forech @list while still keeping the position in the array I imagine that the need for this will become even rarer still.

    Yves / DeMerphq
    ---
    Writing a good benchmark isnt as easy as it might look.

      Check the latest Exegesis. Looks like $#array is going away, to be replaced with @array.last
      ...perl6 (irrc) will have a way to do forech @list while still keeping the position in the array...
      It seems that the plan is to enhance foreach so it can go through a list two elements at a time, then use the @list.kv method to get a list of alternating indexes and values.
        Is it just me, or does it not seem like @array.last should return the last element of the array, rather than the index of the last element?
Re: Perl's Bad Ideas
by trs80 (Priest) on Apr 06, 2002 at 00:07 UTC
    I believe one of its intended purposes was to allow for predefining the length of an array. So the '#' is symbolic of, 'number' of elements you want it to have:
    use Data::Dumper; my @test; $#test = 20; print Dumper(\@test); print $#test , "\n";
    When used in a void syntax (verbiage?) it simply returns the current number of elements.

    That doesn't mean I like it anymore or less then you do.
Re: Perl's Bad Ideas
by YuckFoo (Abbot) on Apr 05, 2002 at 18:39 UTC
    It never made sense to me why no commas are allowed after the filehandle in a printf with parentheses. I think even if someone could explain why printf(OUT "foo\n"); is the reasonable or logical choice, I would still not be satisfied.

    YuckFoo

      Says YuckFoo:
      It never made sense to me why no commas are allowed after the filehandle in a printf with parentheses. I think even if someone could explain why printf(OUT "foo\n"); is the reasonable or logical choice, I would still not be satisfied.

      It's not just the reasonable, logical choice, it's pretty much the only choice. If there were a comma after the filehandle, then what would this do?

      print $x, $y;
      Are you printing the contents of $y to filehandle $x? Or are you printing the contents of $x and $y to stdout?

      This is the same old problem that you always have when there's an optional argument at the beginning of an argument list instead of at the end: How do you tell if the optional argument is there or not? Sometimes external factors allow you to tell; when there are no such external factors, you have to invent a syntactic distinction.

      --
      Mark Dominus
      Perl Paraphernalia

        See, it almost makes sense, but I'm not satisfied.

        If there were a comma after the filehandle, then what would this do? print $x, $y; Are you printing the contents of $y to filehandle $x? Or are you printing the contents of $x and $y to stdout?
        If $x is a filehandle, of course I am printing contents of $y to filehandle $x.

        Your other alternative is a non-alternative. If $x is a filehandle, print $x, $y; doesn't print contents of $x and $y to STDOUT, it generates error 'No comma allowed after filehandle...'.

        So if it's not really a choice, why not 'do the right thing'.

        If Perl is smart enough to know it's a filehandle, why isn't it smart enough to use it as such?

        YuckFoo

Re: Perl's Bad Ideas
by runrig (Abbot) on Apr 06, 2002 at 04:57 UTC
    $#array didn't bother me so much when I realized that perl borrowed much from unix, where $# is the number of arguments, and ${#var} is the length of an array (in ksh, anyway).
    ------------
    ooo  O\O  ooo tilly was here :,(
    
Re: Perl's Bad Ideas
by jepri (Parson) on Apr 06, 2002 at 04:23 UTC
    The entire approach to sockets in perl. The documentation reads 'refer to the C library documentation' which is appalling anyway. And things like SELECT still require the use of bit vectors. As near as I can tell, people produce good networking code in perl despite, not because of, perl's socket support.

    And the docs for IO::Select and IO::Socket aren't much better.

    ____________________
    Jeremy
    I didn't believe in evil until I dated it.

Re: Perl's Bad Ideas
by Dog and Pony (Priest) on Apr 06, 2002 at 22:27 UTC
    I can but agree on this. When I started learning perl, this was one of the things that definetely confused me. Not only is it a strange syntax to remember, but the only obvious mnemonic I could come up with - # means a number, thus "number of elements" - is also wrong. Unless you count from zero, like perl does. ;-)

    To be honest, I was never to satisfied with scalar @var either, even if it is logical when you get the idea of contexts, and that arrays return the number of elements in scalar context. That was not a given...

    I really would like the simple function(s) length(@array) and possibly index_of_last(@array). Possibly with OO-syntax like @array.length(), and most certainly with a better name instead of index_of_last. :) But maybe I am a bit unortodox here, about perl... well, could I have those alternatives as well as something short?

    And not to mention that lots of text editor's syntax coloring croak badly on $#var making the rest of the line a comment...


    You have moved into a dark place.
    It is pitch black. You are likely to be eaten by a grue.
Re: Perl's Bad Ideas
by YuckFoo (Abbot) on Apr 06, 2002 at 21:09 UTC
    I'm surprised how few gripes this call for gripes generated, I guess we love our Perl, but I have one more. I don't wanna chomp no more. chomp $this; chomp $that; chomp; chomp; chomp; I'm tired of chomp. I wish for an autochomper.

    YuckChomp

      Oh come now, you mean you don't do
      { local $/ = 'eatMe'; chomp($str); }
      What then?
      $str =~ s/eatMe$//;
      Or
      $str = substr($str, 0, rindex($str, 'eatMe'));
      Or
      $pat = 'eatMe'; substr($str, rindex($str, $pat), length($pat), '');
      Or ...

      Chop on the other hand is definitely chomp's evil twin brother. Admittedly I could probably use chomp more, though s/// occurs to me more readily. (It's so easy to whip out the 800 lb. gorilla).

      --
      perl -pe "s/\b;([st])/'\1/mg"

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://157002]
Approved by mdillon
Front-paged by NAstyed
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (5)
As of 2024-03-19 03:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found