Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?) From: Erik Naggum <erik@naggum.no> Date: 1999/07/28 Newsgroups: comp.lang.lisp Message-ID: <3142145710427254@naggum.no> * William Deakin <willd@pindar.com> | OK, but would you ever use perl? not if I could avoid it. (I have actually programmed a fair bit in Perl, like I have C++ code published with my name on it. other things I have tried and have no intention to do again if I can at all avoid it include smoking, getting drunk enough to puke and waste the whole next day with hang-over, breaking a leg in a violent car crash, getting mugged in New York City, or travel with Aeroflot. such experiences lead me to assume that Perl users bang their head against the flaws over and over just to see if they are still there, like a dog that goes "wow! a ball! WOOF! wow! a ball! WOOF! wow! a ball! WOOF!" (etc) all day.) | Perl is a tool and like all tool is useful in what it does. sure, but I still don't want to have any nuclear warheads stored in my basement, no matter how good they are at what they do (despite being evidence of a lot of really cool physics and engineering). to abuse the koan style (paraphrased, not original): a novice had a problem and could not find a solution. "I know", said the novice, "I'll just use Perl!" the novice now had two problems. watch someone using Perl, just about anyone. chances are they are trying to make some _other_ tool behave correctly, and Perl offers the duct tape and the chewing gum to make it hold together for a little while. this is sometimes necessary, but the big problem with this approach is that Perl people are _satisfied_ with duct-tape-and-chewing-gum solutions. instead of going back to fix whatever the real problem was afterwards, they use more and more duct tape and chewing gum. bottom line is: Perl was designed to solve the wrong problem and does it very well, which makes for MORE and frequently much harder problems, but that is just fine with Perl people, because it goes to prove how useful Perl is: it can solve _all_ the problems it creates. if the problem is too hard, Perl people tend to dismiss them with "we just have to live with that". this way, a simple problem in the format of a report from a database can lead to serious problems that the whole organization just has to live with. (I want to squeeze in something about Y2K here, too.) I have done project firefighting for many years, and like firemen have this amazing ability to locate where a fire started in the charcoal carcass of a building by asking a few tough questions, I use the line "show me the Perl scripts" when a manager calls on me to find a problem. some laugh. most don't. I have done more to unemploy Perl than any other programmer I know about. Perl mostly has a managerial solution: give their programmers time to find and fight the real problem, don't _ever_ let them get away with a short-term fix in the long run. my biggest problem is that I can spot problems in Perl scripts much more accurately that I can ever figure out what they are trying to do. | This is an argument for some form of pragmatism. But what appears to be | language fundamentalism is very interesting, as is the fact that I have | probable missed the point.... well, I'm not a language bigot, but I sometimes play one on the Net, and Perl and Scheme people are particularly entertaining the way the struggle SO hard to convince themselves that their language of choice doesn't suck. (please note that all of this is my experience and opinion, not something there is any purpose in refuting, and I'm not going to swayed by other people's experience or opinion, but if you think that's inconsistent, I can apologize for the anecdotal arguments right away, as if that helps.) #:Erik -- suppose we blasted all politicians into space. would the SETI project find even one of them?