Subject: Re: Is there a debugger or similar for Common Lisp? From: Erik Naggum <clerik@naggum.no> Date: 1997/11/24 Newsgroups: comp.lang.lisp Message-ID: <3089361005957477@naggum.no> * Tony Tanzillo -> Kent M Pitman | Your comments seem to underscore the reasons why LISP has, or | is perceived by most, to have failed. Lisp would be perceived to have failed even after it had saved the world. why? because it isn't a mass-market language for mass-market people and all that some people will ever judge is whether something is a mass-market product or not. you appear to be among them. I consider the mass market a less than interesting market because it tells me what to want and lags from 10 to 30 years behind research. | Software companies that don't use "vision", but instead just maintain a | prioritized list of things their users ask for, and implement them | starting at the top (most popular), continuing down the list until | resources are exhausted, will quickly go out of business. | | The software companies and products that become major successes are not | largely customer-driven. They are products designed by crazy lunatics | with vision and more importantly, the _guts_ to take bold risks. uhm, if it's a bold risk, how do you ensure that you're staying in live for a long time? people who take bold risks _fail_ more often than not. (ask any banker.) there's no recipe for converting a bold risk into a success, and a lot of things have to happen at the same time for risks not to take you down. sometimes, it's better not to take bold risks, but smaller ones, and stay alive for decades to become extremely good at whatever you're doing. unlikely as it may seem in today's software market, competence is still valued by some. | The LISP language is getting its ass kicked by things like Visual Basic. well, this defines the limits of your perception, and says nothing else. | I am aware of no LISP IDE that offers anothing that comes even close to | this kind of user-friendliness. If you know of one, I will get out my | checkbook right now. user-friendliness is a question of which users you want to be friendly to. | It has been proven that people will use whatever is easiest to use. *laugh* really? Kent wrote about one-place vs two-place predicates, and I believe it to apply in this case, too: people will choose the more appealing ("easiesr" if you like) of two available steps (considering also the steps ahead that they can see or foresee), but they will _not_ choose the easiest path, as determined by an outsider or after the fact. _this_, in fact, has been researched extensively. e.g, people wouldn't use whatever is easiest to use if it would take them a serious battle to start to use it. _this_ is why Lisp is not used more than it is: it takes people with vision and guts to start using it. in effect, those who choose Lisp take a bold risk that they will make a living, do a better job, etc, if they know Lisp, and know full well that they will have a hard time stomaching the idiocy of lesser tools. perhaps it takes "crazy lunatics with vision and guts" to use Lisp? one might consider it an interesting question whether you think that only the bold risks that pay off are good, or, put another way: "what about the bold risks that fail, for whichever value of `fail'", or, yet another way: "how do we determine which bold risks are good and which are not, _before_ they have succeeded or failed?" | Judging by the unfriendly nature of most LISP systems, I get the | impression that their designers don't want anyone to use LISP. yeah, and judging by the unfriendly nature of most mountains, I get the impression that their designers don't want anybody to climb them, either. as any mountaineer can tell you: too easy paths are no longer worth climbing after you gain some experience. I think you are very seriously misjudging good programmers, Tony, like most of the people who clamor about ease-of-use for programming tools. good programmers don't want to _do_ easy things, so it doesn't really matter whether easy things are easy to do or not. it's the hard things that they want to be easy. easy and user-friendly interfaces to hard things look vastly different from easy and user-friendly interfaces to easy things. in fact, making an interface to something that requires a great deal of insight to use properly so easy that people without such insight can use it may be doing them a great disservice, instead. pulling levers or pushing buttons is really not a substitute for knowing what you're doing, and when you do, you find that the manual tasks involved are not all that important, unless they are completely overwhelming, as they are wont to be if all the easy things have to be "in your face" all the time. #\Erik -- if you think this year is "97", _you_ are not "year 2000 compliant". see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.