just my opinion: blaming the current language is convient. "Perl encourages bad coding practices."
It displaces blame to some non-human entity. "The project is late because of perl" A non-sentient language definition is suddenly the excuse why a group of humans cannot meet their schedule, deadline, or budget. language is not an active agent in the goings on in a programming team. It is a set of rules, logic, etc, that the programmers can use. That a team used these rules in a very bad way is not the language's fault. "The language made me do it." this is anthropomorphism. my point? Everywhere I've worked, I've heard someone complain about the current language being used on the project. "If only it had been written in ____, then life would be so much easier." and I've worked on strict languages like Ada and VHDL, hard languages like assembler, simple languages like C and Verilog, and languages like Perl. at some point, someone always blames the language. And what I got was that everytime I hear that kind of statement, someone is trying to shift blame to an inanimate object. If you've got crappy code, and the boss asks you to upgrade it, it's your job to figure out how long it will take. then your boss figures out whether it's worth it to them. blaming the language doesn't achieve anything. on the other hand, it might gloss over the fact that a lot of people at your company made some really bad decisions in the past, slapped together some really bad code, and then handed it off to you to deal with. what you have to say at that point is something like: "look, this is a piece of crap code. we can either bandaid it and get product out the door fast, or we can spend some time and rewrite it in a clean approach. The first way is more expensive in the long run, the second way is more expensive now, but will pay off over time." Then you and your boss look at the cost/benefit and figure out the best choice for the company. AND THEN YOU HAVE TO TAKE RESPONSIBILITY FOR YOUR DECISION. which then means that next year, when you have to revist your bandaid'ed code, you cant blame the language. you have to be willing to own that you created the mess your working with now. which also means that the crappy looking code your looking at now might actually have been written with the company's best interests at heart. sometimes you've got to ship code or go bankrupt. so, before you go to far down the tunnel of blaming language, you should spend some time getting programmers and managers to be RESPONSIBLE for their choices and not let them get away with the blame game. Greg
