This is essential for Perl programming, along with perl -MO=Lint -c <file>. The downside is that it is slow and takes away the fast turnaround times you're used from scripting languages, checking every file after editing (as you should) takes longer than compiling a Go program ...
I've been using "perl -tTW" along with "use strict; use warnings; use sigtrap;" before I found out about Perl::Critic, which works nicely with flymake (http://www.gnu.org/software/emacs/manual/html_node/emacs/Fly...). None of it has seemed to slow me down too much.
The thing about these tools (along with other checkers, warnings, errors, etc), for me at least, is they tend to be corrective. I learn not to keep making the same mistakes, if for no other reason that to avoid the "pain". This is just icing on top of the fact that these tools can be automated, especially to prevent code from being checked in or merged when it violates these checking systems.
I go back and forth on this. Aptitude seems more reliable in general than cpan, at least in the sense that cpan installations fail more frequently than apt.
Also I assume that cpan packages reflected through apt will be updated with apt-get update, while cpan has no similar update-all mechanism (AFAIK).
One advantage of using cpan is that if you're developing on a Mac and deploying on a Debian distro you can use the same commands on both systems to pull in the packages you need.
when dealing with cpan, i think you should separate between the repository itself, which is surely more up to date than debian or ubuntu repos (because this is where debian or ubuntu pull from anyway)
and the command line interface, you have cpan, cpanp (cpan plus) and cpanm (cpan minus)
First, typing that in the shell gives me an error:
zsh: no matches found: /(.*)/
So, I tried typing:
cpan upgrade '/(.*)/'
Which at least kept my shell from trying to expand the last argument, but cpan complained:
Warning: Cannot install upgrade, don't know what it is.
Try the command
i /upgrade/
to find objects with matching identifiers.
Sorry, install with a regular expression is only supported when unambiguous.
Rejecting argument '/(.*)/'
Sorry meant the CPAN shell. Should have reproduced the prompt better. Also it does appear that the regex isn't required any longer. That's certainly nice.
That's why I just use cpan2deb. There's a few modules that won't package properly with it, I should file some bugs.
I also use cpanm when I have a need to be separate from vendor, but generally in the worst-case admins prefer to only maintain one set of perl/cpan rather than two.
i hope engaging in this clearly off topic, wont offend others
linux and foss rely on volunteer effort, therefore efficiency matters a lot, inefficient system will loose volunteers and momentum, i think its surprising the system lasted for so long , but then i believe the number of surviving distros is in decline and even less so the number of package management system
anyway, maybe my usage of the word centralized and decentralized term is wrong
cpan can be viewed as centralized, it is a single storage space for all modules
i just believe that is too much waste, in having to repackage each application to different systems, there must be a better way, where the effort will be more efficient and require less resources
maybe the opposite of what i said is true, maybe we need to centralize over one package system to reduce the effort, or in other, maybe we need we centralized over a single system and repo, to be able to decentralize the effort
I thought most people would have as main reason to not mix their own stuff with the system Perl?!
And you want multiple Perls installed, anyway. Backward compatibility is a target in the Perl world, but stay safe... ("This is the versions at the job servers. This is what I do my hobbies with. Also, I need to keep a 5.8.8 Perl, to make certain so X works with that golden oldie.")
JSHint[1] seems to be the most popular JS linter, although I believe Perl::Critic to be the more powerful of the two tools. I've always appreciated how Perl::Critic allows you to write your own rules, and I wish JSHint was so customizable because I have coding standards I'd like to automate that don't exist in JSHint's options.
> I believe Perl::Critic to be the more powerful of the two tools.
It is quite limited by Perl's quirky syntax, unfortunately ("only Perl can parse Perl"). Last time I checked, it would miss e.g. all warnings for anonymous subs:
# triggers "Subroutine "foo" does not end with "return" at line 5, column 1. See page 197 of PBP. (Severity: 4)"
sub foo {
my $s=shift;
}
# triggers no warnings
my $x = sub {
my $s=shift;
}
This is a bug/limitation in PPI (which otherwise does a great job with the mess that is Perl syntax) ... I'd assume the various JS analysers can do a more thorough job.
Q: What's the difference between writing Perl and taking a severe beating? A: Nothing. The wonder of Perl is that it helps you get the latter without needing any external assistance.
You downvoters are so uptight! Are attempts are humor against HN guidelines? Surely (or maybe not!) you can appreciate a good joke? Unless it hit too close to home, pun intended? (Disclaimer: I do not advocate taking a severe beating, Perl-inflicted or otherwise.)
I didn't vote on any of your comments here. Humor doesn't go all that well here, my take on that is that it is of course subjective, and a whole lot of it is quite a bit less original than maybe the commenter thinks (which turns it into a sort of noise).
https://github.com/illusori/emacs-flymake-perlcritic