Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re^4: Perl for big projects

by spiritway (Vicar)
on Jul 14, 2006 at 05:37 UTC ( #561148=note: print w/ replies, xml ) Need Help??

in reply to Re^3: Perl for big projects
in thread Perl for big projects

All of what you say is true. Perl does offer may freedoms that can quickly lead to disaster if you abuse them or don't know what you're doing - and since we're human, we *are* going to make mistakes and create disasters. IMNSHO, that's what makes programming so much fun - I never know when I'll do something spectacularly bad.

I think there is a tension between two competing forces, safety and power. Some languages are so safe, you can't get things done with them (that's an exaggeration, but they can be frustrating to use). They keep you in a sort of Barney-land, where there are no sharp objects and everything is purple. Other languages are like juggling chain saws. They're downright dangerous.

Perl seems to be a good compromise. It gives me enough power to get things done, without (always) erasing my hard drive. As you pointed out, Perl's attitude towards pointers has helped prevent me from executing my data, often something to be avoided.

What I like about Perl is that I have a choice as to how much discipline I'll use. I can follow good practices if need be, but I can also ignore them and play with fire. This works for me - a lone amateur - but it probably would not work for a team, without there being someone to enforce some rules. In cases where adhering to standards is critical to the project, Perl might not be as useful as some more restrictive language.

Much as I hate to say this, Perl isn't the best language for every project. In a large project with many programmers, you are likely to have a wide variation in skills, making it imperative that some order is enforced from "on high". If it's already built into the language (and can't easily be circumvented), then perhaps Perl wouldn't be as good a choice.

Still, I find the idea of Perl being "too rich" to be something like complaining that your job pays too much money. Oh, well...

Comment on Re^4: Perl for big projects
Re^5: Perl for big projects
by chromatic (Archbishop) on Jul 14, 2006 at 05:57 UTC
    In cases where adhering to standards is critical to the project, Perl might not be as useful as some more restrictive language.

    Which programming language in use or existence today mandates the use of meaningful identifier names? How about test coverage? What about well-factored functional units? Non-duplication? Effective and usable documentation?

    If you can't perform code reviews and have your team adhere to minimal coding standards, use that language.

      Hi, chromatic. I'm not certain what point you were trying to make here. Suggesting that some features are missing from all languages, doesn't negate the value of the ones they do contain. There is a place for, say, strict type checking, and Perl doesn't require that. Other languages do. They are probably a better choice in some instances.

      Perhaps your point was that no language features can substitute for adequate code review and testing. This is true. Even so, code review and testing do not prevent disastrous bugs from getting through to production. Review alone doesn't catch all the bugs. Relying on language features doesn't catch or prevent all the bugs, either. If I had to choose *only* one safeguard, I'd opt for code review and testing, having many eyeballs look over the code. But refusing to use other available tools is (IMNSHO) taking unnecessary risks. Just because there are laws and police to protect my property, doesn't mean I leave my doors unlocked.

      Understand that I'm not being critical of Perl. I love that language, and it's almost the only thing I use. Still, it isn't perfect, and it isn't necessarily the best language to use in every situation.

        My point is that I've personally encountered very few maintenance problems while using Perl caused by anything remotely resembling a type error that a static type system could catch. (Perhaps a handful or two in eight years.)

        (Hey, I've even written simple Haskell code that passes the type inferencer but has a trivial mathematic proof violation.)

        I've almost never failed to encounter bad identifier names, poor factorization, massive duplication, and poor factorization in code with maintenance problems.

        My theory is, fix the big errors first. People write bad code badly. Don't pretend that static analysis or compiler tools can fix anything but trivial errors. It (currently) can't.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://561148]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2014-11-29 08:41 GMT
Find Nodes?
    Voting Booth?

    My preferred Perl binaries come from:

    Results (204 votes), past polls