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
| [reply] [Watch: Dir/Any] |
(jeffa) Re: Perl's Bad Ideas
by jeffa (Bishop) on Apr 05, 2002 at 17:59 UTC
|
| [reply] [Watch: Dir/Any] |
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.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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." | [reply] [Watch: Dir/Any] [d/l] |
|
...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" }
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
|
|
|
| [reply] [Watch: Dir/Any] |
|
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! ;-)
| [reply] [Watch: Dir/Any] |
|
$/, $\, $|, $", 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.
| [reply] [Watch: Dir/Any] |
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 | [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] [d/l] |
Re: Perl's Bad Ideas
by clintp (Curate) on Apr 06, 2002 at 01:41 UTC
|
Wow. $#arr is mild. How about:
- v-strings. Horrible idea, badly implemented, and the cause of many unforseen consqeuences. TIMTOWDI gone stupid.
- 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.
- global $|, $/, $\, etc.. instead of per-filehandle.
- 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.
- $ used on single elements of hashes and arrays.
- <> 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. :)
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
|
- 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...
| [reply] [Watch: Dir/Any] |
|
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"
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] [d/l] |
|
|
Re: Perl's Bad Ideas
by demerphq (Chancellor) on Apr 05, 2002 at 18:34 UTC
|
| [reply] [Watch: Dir/Any] |
|
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.
| [reply] [Watch: Dir/Any] |
|
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?
| [reply] [Watch: Dir/Any] |
|
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. | [reply] [Watch: Dir/Any] [d/l] |
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 | [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] [d/l] |
|
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
| [reply] [Watch: Dir/Any] |
|
|
|
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 :,(
| [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] [d/l] [select] |
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 | [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
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"
| [reply] [Watch: Dir/Any] [d/l] [select] |