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