Subject: Re: lisp is *SLOW* From: Erik Naggum <clerik@naggum.no> Date: 1997/08/12 Newsgroups: comp.lang.lisp,comp.lang.c++,comp.programming Message-ID: <3080336092590847@naggum.no> * Sajid Ahmed | I tried to tell the CS teacher about machine language instructions, but | he shoved it off and tried to say that some processors were designed to | do only recursion; biggest bunch of bologna I've ever heard. | | Anyway, I've come to conclusion that Lisp is bad, Lisp is evil, and as | the subject says lisp is *SLOW*. * Alexey Goldin | My lesson: do not teach pig to sing: it is useless and annoys the pig. I think there are a couple other possible lessons. (1) there are people out there who think they know what computing is all about, and who will object vehemently to any conflicting suggestions, especially when they come from someone better educated than themselves. dismissing such people at a young age will cause them to go mad with rage, targeting any and all reasonbly well-educated people they can find, preferably somebody working in a field that isn't too popular. the only other case I have found of this kind of lunatic rage against better education is Larry Wall. he is also kicking Lisp and academics even more than this "Peaceman" bozo does, equipped with slightly better intellectual ammunition (I gotta give him that). (2) efficiency concerns _are_ actually legitimate at some level, and those who think low-level code efficiency is the alpha and omega of software performance can probably be put to good use in optimizing inner loops and reordering data to increase cache hit rates and the like, after the designers have gone home and the software actually works (otherwise, they will just screw it up). I imagine this kind of people would be useful in writing optimizers for compilers, too, after the real brains have found new ways and directions in which to optimize. in both cases, we have classes of people who can do something good and useful, but which it would not be beneficial to tell much of the big picture. you can teach a mechanic to fix your car, and you need a damn good mechanic these days, but it would be a mistake to discuss new metal alloys that can withstand higher pressures in the combustion chambers or new kinds of fuel with him, especially if they could replace the engines that this mechanic knows and on which he has based his career and all his education from when he was just a boy and loved cars. for all intents and purpose, I grew up on a DEC-10. I had met other architectures before it, but this lovely machine was where I became a programmer. others have argued that other CPUs are their model of beauty and intelligent elegance, and they typically argue differently than I do, not infrequently based on their perception of the system software and the way everything was organized, as far as they could understand it at their age. the Intel generation, further misguided by Bill Gates' total lack of appreciation of the DEC-10 on which he pilfered CPU time to defraud his first customer and ever since has peddled shoddy excuses for software, has had to deal with a totally different kind of "incubating environment". I believe that a good environment brings out the best in people, and that a really bad one brings out the worst. after all, we're still animals that try very hard to adapt and survive. yet, I, too, am a deeply concerned "software mechanic" at times, and I could be exceedingly myopic in my concerns, but in time, I discovered that the car wasn't invented, much less built, in a run-down garage, tuning and tweaking doesn't make a better engine, washing and polishing doesn't make a better car, etc. I wanted to figure out how people who designed these things thought and how they worked. I wanted to make some _significant_ improvement one day, not just tweak a single engine to yield a little better, but make _all_ engines yield better, not just polish a single hood better, but design a metal allow and coat it with something that would make all hoods look shinier no matter the weather conditions and air pollutants. now, there's a important distinction between being satisfied with your ability to tweak an engine or polish a car, and being deeply frustrated with the limits of tweaking or the need to polish cars so frequently while you're looking for that better design that would make such trivial problems go away. my guess is that there's a frightening lot of frustrated, but good, mechanics out there. Peaceman the bozo is not among them, obviously, but I'm afraid that he talks their lingo. "Lisp is evil", the frustrated mechanic says, and any other mechanic will look at him, they will _feel_ his frustration (which is real enough), and they will murmur "it's all because of unleaded fuel" or whatever it is that car aficionados lament -- I wouldn't know. I don't actually own a car, because today's automobile design _sucks_, and the taxes they levy on owning and using one are just criminally insane (at least in this country). I'm waiting patiently here while I'm sure they're hard at work designing those nifty "transporters" from Star Trek. _then_ I'll start going places. fortunately, we already have programming languages that work like "transporters", taking care of all the crufty details, so I don't have to wait. but think of it: how would the automotive and oil industries react to "transporters"? wouldn't they call them evil and worse? not to mention that you could probably get a least five kilometers in your highly optimized car before the transporter could beam you anywhere, and let's not forget that any teenager can learn to drive, but it would probably still require a pretty solid education before you could operate a transporter safely. of _course_ transporters are bad, evil, and slow. sheesh! it all boils down to this: if Lisp were allowed to win, just how would society cope with all the criminals who were just writing bad code? #\Erik -- 404 Give me a URL I cannot refuse.