I love that Perl (5 and 6 even more) is so in tuned with programmers, that when I have an error, I know the actual reason of the error. I can make a mistake and Perl would say "You probably meant to do THIS instead.." instead of saying "Assignment failure".
Subversion says "svn: Can't find a temporary directory: Internal error" when it actually means to say "Uh.. I seem to ran out of space on the subversion server...".
I can't compare Perl to Subversion as languages because Subversion isn't a language, but I can definitely compare them as programs and projects that rely on communities and user insights. Perl really shines in that aspect.
I agree. diagnostics and perldiag are both very nice in that way.
-- dagolden
The situation with Perl's warnings and errors is not always so rosey. For example, with this program:
#!/usr/bin/perl
use strict;
use warnings;
$name = "Sophie";
print "Hello $name!\n";
We get:
Global symbol "$name" requires explicit package name at test.pl line 6.
Global symbol "$name" requires explicit package name at test.pl line 8.
Execution of test.pl aborted due to compilation errors.
After years of using use strict I got used to the fact that it means that I haven't declared the variable using a "my" or an "our" or whatever. However, many newcomers fall on it when they are trying to add "strict" to their programs, and then ask us about it on Freenode's #perl.
Granted, it may be too late to change this message due to backwards compatibility. "use diagnostics" seems to help, though.
Regarding Subversion, it is documented in "Dispelling Subversion FUD" that "A lot of error messages could be clearer. We're working on it.". And I'm not sure the error messages emitted by most other programs (including most Perl programs) will be much clearer if they suddenly run out of disk-space on the device.
Re:Perl isn't always perfect
xsawyerx on 2009-08-04T12:04:35
I disagree, but I'll leave the discussion to some other time.
