Re^6: Modern Perl and the Future of Perl

[Mutant]

I guess it really depends how you want to use the tool. There are a lot of powerful tools in the world (not just in programming). You (or some organisation) can choose whether the tool is your slave or master.

Some people *want* the tool to be their master. Whether you or I think that's a good idea, it's obviously a very popular approach - it basically sums up Java (or at least the popularity of Java, although things may have changed somewhat). People have large legacy code bases of Perl and programmers who are used to the Java Way trying to maintain it. TIMTOWTDI applies even here. Why not let them do it?

But Perl::Critic is still just a tool. You can still be the master if you want. Set the rules up as you wish, and allow your programmers to break those rules at will (with sound justification of course). If they get annoyed with particular rules, turn them off completely! Or don't use it at all. You're the master.

[shmem]

There's a big difference between learning something, and being trained at something.

You don't have good practice as long as you need a tool that beats you into submission. You don't have good practice as long as all you have is just habit.

You can train a horse to stamp it's hoofs resembling numbers according to arithmetic questions you speak. Does that make the horse a mathematician?

You have good practice when you can adapt your coding style to your audience - your team, your customers, your module users, your task, the budget. To be a good orator you need to know grammar, rhetoric, fallacies, intonation and the comprehension level of your audience, and attention and applause are your reward.

To put it bluntly:
Perl::Critic is a utterly useless tool on the path to mastery. It is good for training skilled dogs.

Note that I am not speaking of Damian's "Perl Best Practices" Book here.

The only use I can conceive for Perl::Critic is occasional, in the way I use perltidy. You don't write messy code with garbled indentation and messy line breaks and run that code through perltidy after the fact, do you?

If you need Perl::Critic to enforce a coding style, you have a problem that lies elsewhere.

[mr_mischief]

I think the whole "beats you into submission" is more extreme than what most proponents of Perl::Critic mean.

My understanding of how best to use something like Perl::Critic is this:

• I can take code I'd been meaning to refactor, and figure out automatically which parts vary most from my usual current style. Those parts that differ most in style practice probably also differ most in usage of language features, since both tend to change (hopefully for the better) over time.
• I can, as a new member of a team, run my code through Perl::Critic with the team's settings a few times as a gentle reminder of where my habits differ from the rest of the team. The longer I'm with the team, the less I need such guidance because my habits will become more similar to those I'm programming with over time.
• I can, as an intermittent contributor to someone else's Open Source project, save them some time reformatting my code to their standards if I simply follow their standards rule set before submission. Since it might be very different from my own normal style, an automated check might help me change a few things before sending a patch.
I don't think any of those goals are necessarily narrowing my ability to innovate or to express my creativity in my code. I just think they can help people stick to conventions they were intending to stick to anyway, as a gentle reminder.

All that said, I almost never use the tool because I do very little work closely connected to other developers lately and I pretty much settled on my style of code some time ago. I do pull it out if I'm digging up nuggets of my sad older code or if I'm doing a hit-and-run patch like the scenario I mentioned. Most of my code older than my current coding style isn't worth reusing rather than rewriting anyway, I'm afraid.

[BrowserUk]

You have, perhaps, found the one good use for Perl::Critic. That of an individual programmer, say me or you or chromatic or John in post sales, can apply it (P::C) to a piece of our own old code, or a any piece of old code that we are about to do some work on, and enable everything. And then step through each of the gazillion bellyaches it produces turning them off as we dismiss them. Or leaving them enabled if we not yet ready to dismiss them. Until we eventually arrive a whatever subset is left that we cannot immediately dismiss as either a pointless warning or an acceptable risk.

At that point we have a list of things that we might have picked out anyway, but also some we might have missed. We've also forced ourselves (that emphasis is important), however breifly, and probably only regarding the first occurance of each, to actively rather than passively consider before dismissing the rest.

That process, could be beneficial in any number of ways. Not least because it would force us to read the whole code, at least superficially, rather than just dive into the bit where we think we need to go. And that is always good.

But that it not how anyone seems to be advocating its use. None. Nary a one.

The way its use is being advocated is for some person or core of people to sit around a table and consider each of its gazillion settings in turn and decide, once and for all and in the abstract, which of those all future (in-house, in-dept etc.) code will have to comply with. And that is wrong.

It's wrong in so many ways and at so many levels that it is pretty impossible to cover them all or even a good subset in a single, off the cuff post. But here's one; perhaps the most fundemental. And in someone elses words rather than mine:

In contrast, postmodernism puts the focus back onto the carpenter. You'll note that carpenters are allowed to choose whether or not to use hammers. They can use saws and tape measures if they choose, too. They have some amount of free will in the matter. They're allowed to be creative.

Every single feature in Perl, even the "bad" ones, was put there for a reason and has a purpose. It didn't fall out of the sky at random, or grow up from the depths of Hell for the devilment of it. Each was considered and ruminated and cogitated over and put into to deal with a particular situation, or set of particular situations. And whilst some of those features have fairly specific and limited uses, most have a variety of uses and once you start combining them, myriad uses.

My fundemental argument against P::C is that it is simply, really, actually impossible to whittle away any of Perl's features without throwing something useful, and in some limited situations possibly critical, away also. And it's naive and arrogant and disasterous to believe that you can, in one meeting or series of, in the abstract, account for and truely consider the implications of defining a complete set to which all future code must comply.

Why those who are advocating the use of P::C are doing so, is because they believe that their style has now evolved to the point of perfection. And it must therefore be a Good Thing if their style is enforced upon all code they have to deal with. Because it will benefit everybody. How many of those advocates have truely considered whether each of the individual considerations they are making are because it's truely good for their codebases--or just good for them?

How many of those decisions are because (as one other poster in a another discussion put it) $action if $condition; isn't being deprected in favour of if( $condition ) { $action; } simply because "they as former C++ programmers didn't grok it the first time they saw the former"? Or because "they prefer conditions to come before actions", or whatever other personal justifiction they have settled upon?

If you look carefully at the mountain of P::C extension modules, you can detect certain patterns in their directions.

• There are the "OO dogmatists".
• The "FP (and map) are hard to understand" traditionalists.
• The "magic variables and implicit parameters are evil"-ists.
• The "there was nothing wrong with COBOL, I just want access to CPAN"-ists.
• Any number of other groups who, to my best estimation, simply do not get Perl.

They want the productivity. They want the immediacy. They want CPAN.

Above all they want the lack of a ISO standards commitee predefined coding standard--so that they can define their own standard.

But here's the kicker. If their bosses, team leaders, or management had applied a similar blanket automation enforcement of their (the bosses) preferences, opinions and style, upon them (the P::C advocates), when they (the latter) were just starting out. They probably wouldn't now be coding in Perl!

And finally, I bet if we could get the top ten (informed, thinking) P::C advocates to publish each of their P::C profiles, then you would get no two from ten that were identical, and less than 50% convergance across the whole set.

Now which of them, those king pins in their domains with their overruling authority, would relish writing code under their nearest co-advocates standard profile? Much less that of their most distant co-advocate's?

And much, much (much) less mine! Or at least one that I might come up with :)

Update: a late additional quote that I forgot then remembered.

How does Perl put the focus onto the creativity of the programmer? Very simple. Perl is humble. It doesn't try to tell the programmer how to program. It lets the programmer decide what rules today, and what sucks. It doesn't have any theoretical axes to grind. And where it has theoretical axes, it doesn't grind them. Perl doesn't have any agenda at all, other than to be maximally useful to the maximal number of people.

[jplindstrom]

If you need Perl::Critic to enforce a coding style, you have a problem that lies elsewhere.

No. Because people make mistakes. Not all of the time, but some of the time. I'll give you an example.

Perl::Critic runs every time I open a file and highlights, directly in the source code, whenever there is something to complain about according to the policies I haven't disabled (which I spent quite some time doing in the beginning).

But nowadays I never think about this because 99% of the time there is nothing to report and Perl::Critic is silent.

But sometimes there is something to report and one of the lines of code is blue, begging for attention.

Several times over the last couple of months I've opened files in our code base at work and seen the warning that there is "code before strictures enabled", i.e. no "use strict".

Now, most of these have been five-liner .t files used to set up a test framework. So no biggie, no harm done, nothing was really broken.

But one of the files was a proper module where someone had missed to "use strict;". There was lots of code without strict. And sure enough, when I added it, the source didn't compile because of an undeclared variable.

So Perl::Critic actually helped me find a bug which was introduced by someone making a mistake.

Now, having this little aid will prevent me from making that particular mistake.

I have loads of little guidelines, conventions, and heuristics for how to do things in order to not screw up all the time. Very few of them happen to be Perl::Critic policies, and just a few of them would be useful to implement as policies, but for the ones that makes sense... why not?

Having said all this, I share your concern that Perl::Critic policies will be used as "rules" rather than "guidelines" (but as usual, you have to know why the rule is there, or that there is a rule to break in the first place before you have earned the right to break it).

I also see the risk that in some environments / organizations / projects Perl::Critic policies risk being something imposed on programmers from above, rather than embraced from within the team itself.

/J

[chromatic]

enforce

I'd love to have a discussion about how to help novice Perl programmers write good code, and how to help them train their senses and tastes to keep them out of trouble, but if you're more interested in arguing with words I never said and points I never made, you're more than welcome to have your discussion without me.

[shmem]

I'm not intending to put words in your mouth you never uttered, so let me rephrase that bit:

If somebody needs Perl::Critic to enforce a coding style, they have a problem that lies elsewhere.

BrowserUk and I - we are concerned about Perl::Critic because using it as a code quality insurance is wrong. Using it as a tool to teach perl programming is wrong, too. So what is it good for? It promises to solve a problem but does something else.*)

Same as with cars - we have more and more electronic aids for driving in our cars, ABS and ESP and stabilizers and what not, but those don't prevent people from making accidents, like driving full speed into a fog bank and join a pile of wreckage of 50 other cars, dead bodies and scattered limbs.

Those electronic devices are right now being a risk in themselves. Not only do tey make driving possible for people which don't have the skills, but they tend to fail, as with the poor guy whose speed-o-meter got stuck at 170 km/h, and he was forced to drive at that speed until the car ran out of gas. The system prevented him from interrupting the ignition also (clever!**). Those electronic devices now need firewalls on the internal data bus.

Drivers need better teaching and training if traffic accidents are to be reduced.

*) The same thing is seen with "Homeland Security". Surveillance to keep us save from terr'ists? Naah...

**) It's best practice not to interrupt ignition whilst driving ;)