Re^4: Modern Perl and the Future of Perl

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

[shmem]

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.

These risky constructs deserve a prominent place in e.g. perltrap (which up to this day is full of obsolete perl4-perl5 traps. I'll try to write a patch.) That's all that is necessary. That documentation should show up in the perl docs, not as a Perl::Critic policy complaint after the fact.

If somebody uses risky constructs in production code, that programmer is a risk to your business. And risky constructs aren't just the ones you mention, but every half-known construct.

Do you still occasionally use pseudo-static lexical variables when you shouldn't? Don't code drunk, then. Do you need Perl::Critic to detect them in your code? I bet all you get is false positives.

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.

It's because it is the wrong tool which doesn't solve the problems it promises to solve!

I have much the same reaction whenever I hear of people that have a "personal firewall" on their box. I'm always glad if I can direct them to the Personal Firewall FAQ. If you need Perl::Critic, your problem is somewhere else. See my other post.

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