Subject: Re: Is there a debugger or similar for Common Lisp?
From: Erik Naggum <>
Date: 1997/11/24
Newsgroups: comp.lang.lisp
Message-ID: <>

* 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.

if you think this year is "97", _you_ are not "year 2000 compliant".

see for GNU Emacs 20-related material.