Re^3: Modern Perl and the Future of Perl

[BrowserUk]

If Perl::Critic were not customizable, I wouldn't use it. I wouldn't recommend it.

Well yes, it's customisable but only before the fact. Not during.

One of those 10 commandants is "thou shalt not kill". A pretty good rule for the most part, but we can all think of times and places, people and circumstances in which even this rule must be ignorable. Take your pick from military, to policeman; to a parent defending her children; self-defense; capital punishment. Some each of us can agree with. Some we may not.

That's why we have courts and judges and juries to decide on a case by case basis. Because no matter how complex and complete the legistlatures attempt to cover all the bases, there are always exceptions and exceptional circumstances.

Even just opinion influences what was illegal yesterday is legal to day and may be illegal again tomorrow.

"Yeah but that's just an futile, extreme analogy that doesn't hold up for the case of coding standards techniques and constructs."

But...the problem with Perl::Critic is that it attempts to take the human out of the decision making process.

Yes, it can be configured. But that still requires a pre-judgement that must be applied to all cases henceforth. As in--this is the configuration that we will use for this company/dept/team coding standards and all code shall be run against and anomolies resolved.

But on what basis do you decide the configuration?

• Imposed from on high (minority rule)

  You (if your the boss) decide what you thinkis right and everyone follows.

  Analogy:apartheid

• Majority concensus

  What about the opinions of those that don't agree?

  Analogy: American Indians/black 200 or 100 years ago.

  Or those that join the group later?

  Analogy: Americanised Japanese 1941

• Other?

The saving argument is that Perl::Critic used correctly, will draw human attention to just those areas of the decision making process requires concensus. That when the programmer choses to ignore a "standardised" configured ruling and a warning is produced, s/he should have to justify their decision to do so to "management".

1984

The reduction of the art of programming to the step by step application of a set of rules and procedures. Big brother is watching you.

Paranoia you cry. But I now live in a society that has the greatest concentration of CCTV cameras per head of population in the entire world.

For the most part they do not figure in my life at all, but 23 years ago and even 10 years ago, the idea that this could happen was laughable and unthinkable.

Imagine 11 months ago when I said "Imagine a world where human beings where unable to apply their reason and discrimination to rules and guide lines." that that could ever become true.

Taking the human out of the decision making process; and even sitting on the programmers shoulder and making his decisions or making him justify every decision; and taking away his voice and influence over the work he does.

I've worked on a production line in a car factory where you sit for 2 minutes and 13 seconds and then stand and do your 7 alloted tasks for 3 minutes and 2 seconds for 6 hours and 42 minutes each day. You don't want to go there, and this is the start.

[chromatic]

If you can't agree on a coding style within your team, the use of Perl::Critic is not your biggest problem. If you can't modify the coding style within your team as necessary, the use of P::C is again not your biggest problem.

You can run into the same problem with programmable text editors, the strict pragma, variable naming conventions, unit tests, pre-commit hooks, and any other useful tool for software development.

[BrowserUk]

1. Do you impose one text editor upon all your employees?
2. Do run a daemon continuously, randomly or periodically on all your employee systems to detect other editors and either scream or tattle when it does?
1. Must variable names be selected from a predefined list of those allowed?
2. Do you have a programmable way of checking all variable names to ensure that list is complied with?

I hope you can see how these examples can be extended to all your other "useful tool" examples.

The problem with "useful tools" is that they come and go. In fads.

• In the '70s and '80s it was 3GLs.

  For every one of the myriad successful languages that was used by one or more groups of programmers somewhere, and the list is huge, there are 10 more largely unsuccessful ones that was imposed upon some group of programmers, somewhere, for a while.

• In the '80s and early '90s it was 4GLs.

  Aims: admirable. Execution (of the 4 or 5 I used for a time and several more I know a little of): abyssmal.

  (IMO) Perl 5 (base syntax and semantics) is the closest anyone has gotten to what they were searching for. Perhaps 3.5GL. (To borrow a trick from the mobile industry.)

  (IMO) Perl 6 (base syntax and semantics as best I know them) has the potential to become the first true 4GL.

  Devoid of all the justifictions; artificial constraints; NIH syndromes; historical dogmas; all encompassing and overarching grand designs; political and mathematical correctness; and any other faddy, of-the-moment featuritis & futuritis; paradigms and methodologies.

  Forget all the GUIs, and CASE & UML modelling tools, that were all at one time or another considered by some or many as an essential part of what constituted a "4GL".

  Forget also (for now, but do not dismiss completely), quantitative definitions like "Jones defines the various generations of programming languages in terms of developer productivity, measured in function points per staff-month. A 4GL is defined as a language that supports 12 - 20 FP/SM.".

  Anyone read The Mythical Man Month?

  Instead concentrate soley upon one early sentence from the link above:

  In the evolution of computing, the 4GL followed the 3GL in an upward trend toward higher abstraction and statement power.

  And think about how many of the Perl::Critic rules are there soley to inhibit the use of Perl's higher abstraction and statement power?

The relatively short history of computing is littered with the bodies of many thousands of productivity aids and other "useful tools". Some have left their mark. Many have vanished completely.

How sure are you that your current set of opinions on what constitutes "Best Practices" will stand the tests of time?

• Sure enough to try them for yourself?
• Sure enough to recommend them to others?
• Sure enough to impose them on your team?
• Sure enough to impose them upon your company?
• Sure enough to impose them upon the world?

Now re-read that list substituting "Sure enough to risk their imposition upon ...".

Does either list give you any pause for thought?

[shmem]

The use of Perl::Critic is fundamentally wrong.

Developing good, then best practices is a good thing; agreeing upon naming conventions and code style also is, nobody denies that, and BrowserUk certainly doesn't.

Good coding practices aren't if imposed and applied after the fact.

Good coding practices are a programmer's attitude towards the job at hand, and this attitude will not develop under any imposition of rules whatsoever, but by understanding them and internalizing them. Best practices are such only in practice, when you are coding.

Once this attitude is fully shaped there's no point in using Perl::Critic, since you know what you do, and why, at every step.

Perl::Critic alienates what has to be a programmer's internal state into a technical instrument, which is wrong. As it is applied after the fact, it is a tool for imposition, which is a hindrance to really developing good practices.

[chromatic]

Once this attitude is fully shaped there's no point in using Perl::Critic, since you know what you do, and why, at every step.

Some P::C policies detect code that is undeniably wrong. For years, I recommended the use of UNIVERSAL::can and UNIVERSAL::isa as functions until they bit me in real life. For years, there was no warning on pseudo-static lexical variables (Perl 5.10 added this).

It's not clear that those constructs are always bugs, but they all deserve investigation. P::C can detect those in a large codebase, along with other constructs which we now know to be risky.

Now I don't know what's happened to you and BrowserUK that your hands jerk off the keyboard in shock whenever someone suggests that your team should consider agreeing on the use of a tool that can help you identify things in code that you need to think about, but that's fine. Don't use them. If they give you nightmares or make a bunch of nametags for you that say "Hello My Name Is Winston Smith," then you don't have to use them.

Me, I think they can lead to better code. You'll never see me use the default vanilla set of policies, but you do see me taking advantage of other good tools such as profilers, unit tests, tags, version control, and POD checking tests because I don't trust myself to get everything right the first time. I'm perfectly happy disabling a P::C policy if it doesn't help me write better code, and if the burden of maintaining policy files is greater than the benefit I get from using P::C, I'll throw it out.

I don't see how that means I'm telling coders to turn off their brains and march back into their drab gray cubicles. Frankly, anyone who uses any of these good tools as an excuse not to think and not to do good work has no place on my team.

[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.