in reply to Re^7: Modern Perl and the Future of Perl
in thread Modern Perl and the Future of Perl

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.

  • Comment on Re^8: Modern Perl and the Future of Perl

Replies are listed 'Best First'.
Re^9: Modern Perl and the Future of Perl
by shmem (Chancellor) on Dec 21, 2007 at 20:13 UTC
    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 ;)

    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

      Alright, I can understand that, and I agree.

      I consider P::C much more like warnings and strict, and -Wall and all of those lovely GCC warnings we keep increasing in Parrot.

      Yes, in theory, I'm a good enough programmer that I shouldn't write dubious code. Sometimes I do, though. In particular, I think of -Wc++-compat, which warns about perfectly legal C code that a C++ compiler can't compile. That's not a problem for me or most of our platforms, but a few platforms have C compilers so awful and old and broken that the only hope of compiling anything resembling modern C is with a C++ compiler. If there are C++-style errors in our code, they won't work.

      I'm all in favor of using warnings and tools like this to help develop well, and I agree that there's no substitute for wisdom and experience and careful thought... but I just can't see how the tools are bad in and of themselves, when they have good and practical uses.

      Yes, there are people who will abuse them. They'll abuse anything though, and in the absence of good tools that thoughtful people could use to do good things, incompetent and malicious people will invent new ways of malice and incompetence. We can't avoid that, so we might as well concentrate on making good things that people can use productively instead.

A reply falls below the community's threshold of quality. You may see it by logging in.