Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Until more of the world switches to taking a functional perspective, I suspect that procedural code is going to be more understandable (and maintainable) by the general population of developers.

    Paradigm shifts often take time.

    • Here! Here!

      The problem with functional code is that most fresh meat, er, new hires/newbies won't grok what's going on in the code. By using procedural idioms over the functional ones, your code is more likely to be understood by others (and maybe even you) in the future. Using language neutral idioms in public Perl code goes a very long way to squashing Perl's "unmaintainable, spaghetti code" reputation.

      Does that mean eschewing map and grep all together? I don't think so. It is better to limit the use of

      • Re:Maintainability (Score:3, Insightful)

        by ziggy (25) on 2002.04.18 17:34 (#7267) Journal
        By using procedural idioms over the functional ones, your code is more likely to be understood by others (and maybe even you) in the future.
        Any style can be abused to produce good or bad Perl code. Erring on the side of "procedural Perl" for the benefit of newbies doesn't mean it will naturally be easier to understand. I've seen grotty Perl code that's using a classic FORTRAN style, so I'd say that it's more important to write clearly than to write in a specific style. I've also seen code that's been massively improved by adopting a functional style in a small scale, without going whole-hog -- in such a way that the fresh meat isn't phased for more than about 5 minutes. :-)
        Using language neutral idioms in public Perl code goes a very long way to squashing Perl's "unmaintainable, spaghetti code" reputation.
        Squashing a misperception about Perl isn't your job. Solving a problem in a way that other Perl programmers understand your solution is your job (unless you're writing an Acme::* module, a japh, or a golf swing :-).