At the risk of beating a dead horse (South Park anyone?), I'd like to make two points about coding for large projects.
1) Normally, lots of people are involved. The success of the project doesn't rest entirely on the coders, but management as well. Software Engineer can't be done in a vacuum. Management must want the results that come from managing the engineering process. You may well ask does this happen in the "real world?" As a matter of fact it does, but rarely. Check out this example: http://www.fastcompany.com/online/06/writestuff.html Like Grant, I don't buy the "l33t coder" argument. Sure, some coders are faster and more productive than others -- I allow that. Unfortunately, engineering is a team effort. When coding is equated to a widget machine (e.g.. "the more widgets produced in less time = more profit"), engineering practices are irrelevant. There is more to producing software than v1.0. Engineer is all about following the rules and getting there together as a team. The dividends for managing the SW engineering process come later in the product life cycle and aren't as visible during the initial build phase (as a counter-example, look at Netscape -- code so tangled that after v4.0, it had to be rebuilt from the ground up). Coders that need their egos stroked can surfer alt.binaries.*. The more coding is treated like an industrial art, the better I'll like it. 2) Small projects don't require the same amount of attention, especially if the team consists only of one person. It this case, the sky's the limit, Tex. If you don't want to eschew for() loops for map and grep, go for it. If you want to use Acme::Bleach for production code, Amen brother! Of course, I also assume you'll be doing the maintenance too. :-) -- ---------------- Joe Johnston - http://taskboy.com "A closed mouth gathers no feet."
