Elaine -HFB- Ashton wrote: > > Greg London [[EMAIL PROTECTED]] quoth: > *> > *>blaming the current language is convient. > *>"Perl encourages bad coding practices." > > Well, having managed systems for programmers for 15 years now I can say > that I have noticed a trend from programmers well based in C to kids with > little or no college, no C and some of the worst programming habits anyone > could imagine.
Notice the word "trend" says nothing about "cause". I'm talking about "responsibility" which means ONLY who is at cause. "noticing a trend" does not assert cause, but it allows the reader/listener to make that jump. And it completely avoids fixing responsibility. You're left blaming the language again. which is exactly what I said should be the first thing to look for. Is the manager shifting blame? Are the programmers looking for a scapegoat? If you're the manager, then you're ultimately responsible for the code your project produces. blaming perl is not being accountable for your job description. Are you holding your programmers to equally laxidaisical standards? I've worked on fly-by-wire software for the Boeing 777. It was written in Ada, the most god-awful strict language I've ever worked in. But since the software is what actually keeps the airplane in the air, its good that its strict. But Rockwell also took three times as many man-hours to VERIFY the code as it did to DESIGN/WRITE the code. It was a 8 year project just for one black box. Ada didn't make good code, the managers and the responsibilty that the programmers had made good code. web pages, surprise surprise, aren't coded with the mental mantra of "bad code means people die". if you want good code, you as a manager are responsible for making sure the budget and schedule allow for it. Or, if you do cut corners, you own it as your decision. if someone writes crappy code and you budgeted time/money for well written apps, then you, as manager, should chew out the programmer and have them do it correctly. perl is not at fault. now, there is such a thing as a safety-net when working on the high-wire act. fly-by-wire stuff should be in Ada. Not because ada makes good software but because some bad software wont even compile. but if someone falls off the highwire, it's not the wire's fault, it's the highwire actor's fault. If they don't know how to walk the high-wire, 1) they shouldn't be up there in the first place 2) its the manager's fault for putting them there and having the project fail. people bitch and moan about companies like Microsoft selling buggy software without any kind of warranty. Yet warranties boil down to "who's responsible". And I find it hilarious that no one wants to be responsible for their own friggin code. Microsoft et al give all sorts of excuses as to why they can't put a warranty on their software. But it's all a bunch of crap to confuse who should be responsible for their software. They should be responsible for their code. You should be responsible for your code. Get a job where an "off by one" bug in your software means 500 people die, and you might grasp what I mean. I did it for about 3 years. You can have bugs in Ada as well as Perl. Stop blaming the tools. Greg
