From: Kent M Pitman
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <sfwg1oprc2n.fsf@world.std.com>
UAB writes:
> I wonder if there is a debugger or any way to trace a program written in lisp.
Sure.
;; Here's the canonical function to be traced:
(DEFUN FACT (X)
(IF (ZEROP X) 1
(* X (FACT (1- X)))))
;; Here's how you enable tracing:
(TRACE FACT)
;; Here's some typical output:
(FACT 3)
0 FACT > (3)
1 FACT > (2)
2 FACT > (1)
3 FACT > (0)
3 FACT < (1)
2 FACT < (1)
1 FACT < (2)
0 FACT < (6)
6
;; Here's how you undo tracing:
(UNTRACE FACT)
Also, try something like (STEP (FACT 3)). The interface will differ
from system to system but will typically offer commands that will let
you step past a form, step into subforms of a form, etc.
You can also call (BREAK "some message") from within your program to
force entry into the debugger at any given point of interest.
Good luck.
--Kent
Tony Tanzillo wheezed these wise words:
> That's what I call a debugger.
There are many kinds of debugging tools.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Kent M Pitman
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <sfwwwi0xd5j.fsf@world.std.com>
"Tony Tanzillo" <·············@worldnet.att.net> writes:
> Kent M Pitman <······@world.std.com> wrote in article
> <···············@world.std.com>...
> > UAB writes:
> >
> > > is there is a debugger or any way to trace a program
^^^^^^^^^^^^^^^^^^^^^^^^^^
> > ;; Here's the canonical function to be traced:
^^^^^^^^^^^^
> > ;; Here's how you enable tracing:
^^^^^^^^^^^^^^
> > (TRACE FACT)
> >
>
> That's what you call a 'debugger'?
No, in case you missed the subtle cues, I call that "tracing".
Lisp ALSO offers a STEP macro which I showed how to invoke but
did not show an interaction with. It allows interactive and
program-initiated single-stepping; the manner of invocation is
standard, but the manner of interaction is not.
Lisp ALSO offers a *debugger* which I showed how to enter but
did not an interaction with.
I *did* however mention their availability in the part of my message
you elected not to include:
- Also, try something like (STEP (FACT 3)). The interface will differ
- from system to system but will typically offer commands that will let
- you step past a form, step into subforms of a form, etc.
-
- You can also call (BREAK "some message") from within your program to
- force entry into the debugger at any given point of interest.
> There's an interesting IDE available for the AutoLISP
> programming language (editor/compiler/debugger), that [...]
>
> That's what I call a debugger.
Many Common Lisp systems offer similar features. I did not discuss the
individual features of Lisp debuggers because they are not standard
across implementations. Some are extremely sophisticated, some are
less so. In general, the Common Lisp language leaves "interactive
environment details" to the implementation to specify.
I'm glad AutoLisp has a good debugger; I assure you that most Common
Lisp systems have fine debuggers, too.
From: P. Srinivas
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <659l62$4hm$1@tribune.usask.ca>
Kent M Pitman (······@world.std.com) wrote:
< stuff deleted >
: I'm glad AutoLisp has a good debugger; I assure you that most Common
: Lisp systems have fine debuggers, too.
Not really. atleast not in Allegro CL for Unix. The debugging environment
of ACL is pretty primitive to say the least. A while back I posted a
question to this group asking if there is any public domain source-level
stepper debuuger available. Among the answers I got: Such a beast exists
only for GNU Common LISP. Emacs LISP too has a good debugger (Edebug).
It is possible that it exists for others, but no one pointed to me or
followed it on the newsgroup. Is there anything I am missing?
It is surprising that no one before thought it as a useful thing
otherwise some one would have written it.
Someone suggested that it should be possible to modify edebug to
do it with infereior lisp. It might be that there is no portable way
to do it across all LISPs. WHy can't vendors of commercial CL hack such
thing up? If a guy can put together such thing for GMU Common LISP,
it can be easily done for these companies.
srini
--------------------
Srinivas Palthepu Email: ·····@cs.usask.ca
ARIES laboratory, Phones: (306) 966-8654 (lab)
Department of Computer Science, (306) 966-4759 (office)
University of Saskatchewan, (306) 373-6724 (home)
57 Campus Dr, Saskatoon, SK, S7N 5A9 Fax: (306) 966-4884
From: Kent M Pitman
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <sfw7m9z33oh.fsf@world.std.com>
Oops. I said I wasn't going to reply further in this thread.
Well, ignore my previous remarks if you like. Sorry about that.
From: Kent M Pitman
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <sfw90uf33q2.fsf@world.std.com>
·····@skorpio3.usask.ca (P. Srinivas) writes:
> Why can't vendors of commercial CL hack such thing up? If a guy can
> put together such thing for GMU Common LISP, it can be easily done
> for these companies.
The economics of commerce are more complex than that.
One reason GNU CL can offer this and other vendoers can't is that it
can offer anything that some public-spirited person happens to want to
contribute. On the other hand, while it can potentially "happen to
offer" anything, it can promise nothing. For example, last I checked
(and I'll be happy to be corrected if this has been fixed), GNU CL is
lacking many basic program primitives that would make it ANSI compliant.
The Common Lisp language is designed around the idea that each vendor
will invest according to what they measure as important. Vendors
may differ in those metrics, but I don't think any vendor with a budget
and a need to have sales continue to fund that budget is busy saying
"people are asking for x but i'm not going to give it to them--i don't
think they need it". I think instead they are saying "people are
asking for x and y, but i think they need y more, and if there's time
and money left over later, i'll do x also."
People often confuse "interest in" a certain thing with "willingness
to pay". I have, in my experience with life, come to the conclusion
that a great number of conflicts among people are caused by the
misleading attempt to express two-place predicates as one-place
predicates. Examples verbs that I find meaningless in one-place form
are "interested in", "committed to", etc.
Suppose a politician says "I am committed to the environment." What
has he told you? Nothing. (I claim "committed to" doesn't work that
way.) He usually follows with "I am committed to jobs." Any new
information? Nope. Want something fun to do? Get him to say a
phrase like "I am more committed to jobs than to the environment." or
"I am more committed to the environment than to jobs." THAT would be
information. He isn't going to tell you that because it would get him
in trouble--there are true inferences you could get from either
position which would be unpleasant. There are no meaningfully
derivable certain inferences from the one-place forms, so they are
safe.
Back to Lisp. Vendors get a lot of "interested in" feedback. They
get a lot less "would be willing to sacrifice x to get y" feedback.
And, sadly, there's some drama to new product releases (read: company
confidential information about product directions) that keeps this
information from efficiently flowing. So sometimes we can't ask the
right questions, and sometimes we don't get good answers.
But the lack of a feature in an implementation is generally not
equivalent to disinterest in that feature. It is more precisely and
properly expressed as "greater interest in whatever else we did instead".
Most Lisp debuggers are rich in operations that let you poke at the
stack, see local variables, etc. Some are a flat TTY interface.
Harlequin's LispWorks, for example, offers a choice of that flat
interface or a menu-oriented interface. Harlequin's LispWorks will
take you from the debugger to the source expression within a
definition.
Steppers? Harlequin don't have something that will move a cursor over
the textual source, but we have something that will show you the
expressions in your Lisp Listener using PRINT. That often serves the
purpose; it may not be as flashy as you want. Could we do more?
Probably. Will we? Probably not right now. I bet if you saw our
list of things to do, you'd not sacrifice any of the features that are
ahead of it on the list ... Would that mean YOU suddenly became
"disinterested"? No. It's just a matter of trade-offs.
One possible test you could run to see if I'm just making this
up--implement a commercial CL of your own and focus on flashy steppers
at a higher priority than we have. If your approach takes the market
by storm, ... well, I was going to offer to apologize for being
confused in my priorities, but why should I be apologizing for having
given you an idea that makes millions? ;-)
Your comments seem to underscore the reasons why LISP has, or
is perceived by most, to have failed.
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.
The LISP language is getting its ass kicked by things like
Visual Basic. A cruddy pile of garbage Visual Basic may be,
but what does that matter?
A non-programmer (which is what most VB users are) can make use
of intelligent editing features that put the information they
need at their fingertips. They can move their cusor over a
variable in the editor while they are debugging, and see the
value assigned to it.
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.
The AutoLISP IDE I was referring to is probably the most
user-friendly LISP IDE in existence. It highlights code
in the editor as you step through it. It displays variables
in a watch window, and lets you "animate" the execution of
a LISP program (automatic stepping at a given time interval).
A novice can actually watch a program execute, by seeing
visually observing program logic flow.
The point to this is that feautures like these are what
help people learn to use a language, which in-turn is
what helps make the language more popular. It has been
proven that people will use whatever is easiest to use.
They're not computer scientists with an opinon on every
language on the planet, they're people who need to solve
problems, not create more of them.
Judging by the unfriendly nature of most LISP systems, I
get the impression that their designers don't want anyone
to use LISP.
Kent M Pitman <······@world.std.com> wrote in article
<···············@world.std.com>...
> ·····@skorpio3.usask.ca (P. Srinivas) writes:
>
> > Why can't vendors of commercial CL hack such thing up? If a guy can
> > put together such thing for GMU Common LISP, it can be easily done
> > for these companies.
>
> The economics of commerce are more complex than that.
>
> One reason GNU CL can offer this and other vendoers can't is that it
> can offer anything that some public-spirited person happens to want to
> contribute. On the other hand, while it can potentially "happen to
> offer" anything, it can promise nothing. For example, last I checked
> (and I'll be happy to be corrected if this has been fixed), GNU CL is
> lacking many basic program primitives that would make it ANSI compliant.
>
> The Common Lisp language is designed around the idea that each vendor
> will invest according to what they measure as important. Vendors
> may differ in those metrics, but I don't think any vendor with a budget
> and a need to have sales continue to fund that budget is busy saying
> "people are asking for x but i'm not going to give it to them--i don't
> think they need it". I think instead they are saying "people are
> asking for x and y, but i think they need y more, and if there's time
> and money left over later, i'll do x also."
>
> People often confuse "interest in" a certain thing with "willingness
> to pay". I have, in my experience with life, come to the conclusion
> that a great number of conflicts among people are caused by the
> misleading attempt to express two-place predicates as one-place
> predicates. Examples verbs that I find meaningless in one-place form
> are "interested in", "committed to", etc.
>
> Suppose a politician says "I am committed to the environment." What
> has he told you? Nothing. (I claim "committed to" doesn't work that
> way.) He usually follows with "I am committed to jobs." Any new
> information? Nope. Want something fun to do? Get him to say a
> phrase like "I am more committed to jobs than to the environment." or
> "I am more committed to the environment than to jobs." THAT would be
> information. He isn't going to tell you that because it would get him
> in trouble--there are true inferences you could get from either
> position which would be unpleasant. There are no meaningfully
> derivable certain inferences from the one-place forms, so they are
> safe.
>
> Back to Lisp. Vendors get a lot of "interested in" feedback. They
> get a lot less "would be willing to sacrifice x to get y" feedback.
> And, sadly, there's some drama to new product releases (read: company
> confidential information about product directions) that keeps this
> information from efficiently flowing. So sometimes we can't ask the
> right questions, and sometimes we don't get good answers.
>
> But the lack of a feature in an implementation is generally not
> equivalent to disinterest in that feature. It is more precisely and
> properly expressed as "greater interest in whatever else we did instead".
>
> Most Lisp debuggers are rich in operations that let you poke at the
> stack, see local variables, etc. Some are a flat TTY interface.
> Harlequin's LispWorks, for example, offers a choice of that flat
> interface or a menu-oriented interface. Harlequin's LispWorks will
> take you from the debugger to the source expression within a
> definition.
>
> Steppers? Harlequin don't have something that will move a cursor over
> the textual source, but we have something that will show you the
> expressions in your Lisp Listener using PRINT. That often serves the
> purpose; it may not be as flashy as you want. Could we do more?
> Probably. Will we? Probably not right now. I bet if you saw our
> list of things to do, you'd not sacrifice any of the features that are
> ahead of it on the list ... Would that mean YOU suddenly became
> "disinterested"? No. It's just a matter of trade-offs.
>
> One possible test you could run to see if I'm just making this
> up--implement a commercial CL of your own and focus on flashy steppers
> at a higher priority than we have. If your approach takes the market
> by storm, ... well, I was going to offer to apologize for being
> confused in my priorities, but why should I be apologizing for having
> given you an idea that makes millions? ;-)
>
From: Erik Naggum
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
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.
From: P. Srinivas
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <65cole$h4l$1@tribune.usask.ca>
Erik Naggum (······@naggum.no) wrote:
: * 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.
I too do not care if it is mass market or not.
My main consern is how best I can program. I reaslised that it is
to program in LISP. Now my question is how best to code in LISP and
what type of tools. Besides, it helps if having good tools make it
mass market which will make more people putting more moeny into
LISP. What is your objection to it? I think it is a good thing.
LISP might have been few decades ahead at its time, but we probably
should live in present world. Curretnly LISP implementation of IDEs
are at least 10 years behind. I saw pretty good editor/debugger for
the first release of Turbo pascal and later adopted to turbo and borland C
way back in mid 80s. I am yet to see such a level of user-friendlyness
in most modern current state-of-the art CL implementations.
Where have we gone wrong? There is one saying in my langauge TELUGU)
which essentially translates "My forefathers used to eat butter, you
can smell it on mouth even now."
: | 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.
Ok. forget for the time being about the risk,
now think about another word. Vision or/and innovation. This is
proactive type of risk taking where you do not have a market for it
readyly but there is a good chance that it will serve some needs.
If it serves some need, people will pay for it, unless it has
unreasonable cost. A company cannot just respond to immediate needs
alone. It has to have plans for the future and that often involves
new directions and some element of risk. Besides, good IDE for a time
tested language is not what I consider a risk.
: | 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.
Why do you think so? the point he is making (as I undesrstand) is
that current IDEs for visual basic wins hands down when compared to
CL IDEs. I agree with that and am open for a proof contarry to it.
: | 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.
And there are tools for climbing mountains too. And thank god
that they did not think that mountain climbing equipment need not be
user-friendly. If one wants to take more challenging task she will
go and climb higher difficult mountain with tools than climbing a small
mountain without any tools even though both are equally harder.
Besides, this is a bad analogy. People climb mountains
for its own pleasure. But people write LISP programs for doing
some task. We enjoy programming too, but do not write
just for enjoying. We enjoy only when it achieves a purpouse.
If your aim is to reach a particular hight,
I would (and most other) use a ladder anytime than climbing it
unless it is a trivial height which I cna simply jump up.
: 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.
I do not see any disagrement here. I also do not just want easy things
to be easy. What I want is a better way of doing the same thing.
: 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.
I partly agree with you here. Many people who do not understand any basic
concepts of programming sit in front of Visual Basic for a few
hours and come out saying that they have suddenly become a programmer all
of a sudden. What a nirvana!!
But that does not say anything about what a really serious programmar needs
in terms of tools/IDEs. I have been programming in LISP atleast 8 years.
I think I am a reasonably good programmar. But I still feel a need for a
better IDEs for LISP. Most of CL systems are "powerfull". But they simply
have raw power. When I am stepping through a large function with a lot of
macros, I can not really comprehend where exactly I am and what is
happening to key variables. That is especially true if there are a lot
of system generated uninterned temp variables as a result of
macro expansion. If there is a better interface that hides these and just
show me the point in source code where I am and allow me inspect each variable
with a mouse click, it will be of great help. Sure I can now see the variables
by typing a command in a listener widow. But that takes more time.
And I can also print the current form being executed, if the form is big and
argument lists are long/deeply nested, then I need to truncate printing
with printer control variable otherwise it fills up my Emacs window
quite quickly and forces me to scroll.
Having a better interface will do a great service to LISP programmars.
At least I will be very happy. I do not know others.
Incidentally, I looked at the URL posted by Tony Tanzillo (lisppad):
http//ourworld.compuserve.com/homepages/tonyt/lisppad.htm
That is the sort of thing I want. In fact it need not be that *flashy*.
Simple interface in Emacs would be sufficient. I just want the same
type of thing a C programmar can get in EMACS. And it should be easier
to do such things in LISP since you have access to full run time
LISP system where comparative C debugger does not fully understand
C langauge. Some people are putting full C interpreter in the
debugger GDB. It is all messy there.
srini
--------------------
Srinivas Palthepu Email: ·····@cs.usask.ca
ARIES laboratory, Phones: (306) 966-8654 (lab)
Department of Computer Science, (306) 966-4759 (office)
University of Saskatchewan, (306) 373-6724 (home)
57 Campus Dr, Saskatoon, SK, S7N 5A9 Fax: (306) 966-4884
In article <············@tribune.usask.ca>, ·····@skorpio3.usask.ca (P.
Srinivas) wrote:
> LISP might have been few decades ahead at its time, but we probably
> should live in present world. Curretnly LISP implementation of IDEs
> are at least 10 years behind.
This is an unclear statement. Given that the Lisp machine
was 20 years ahead in 1985, we still have some days
until people catch up. Seriously, I'm quite satisfied with
the Genera debugger. Currently I'm evaluating a log
file, which resulted in some 400000 simple objects.
Everything that makes you redo stuff unnecessary is
unwanted. When my code drops into an error, I'm just
looking up the source, fixing it and reinvoke the stack
frame for the function. The program is just continueing to
run. Given that you can have an environment like Dynamic Windows based
Genera where literally everything can be clicked on, it is
hard to see how other IDEs can be 10 years ahead (unfortunately
Lisp vendors were not clever enough to market a portable CLIM based
IDE - this would have been the killer application for Common Lisp).
> I saw pretty good editor/debugger for
> the first release of Turbo pascal and later adopted to turbo and borland C
> way back in mid 80s. I am yet to see such a level of user-friendlyness
> in most modern current state-of-the art CL implementations.
Have you ever used the old Symbolics systems?
> Why do you think so? the point he is making (as I undesrstand) is
> that current IDEs for visual basic wins hands down when compared to
> CL IDEs.
For some tasks yes, often not.
--
http://www.lavielle.com/~joswig/
Erik Naggum <······@naggum.no> wrote in article
<················@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.
In terms of the capabilities and friendliness of LISP IDE's I'd say
that it is LISP that is lagging behind the mass-market products.
> | 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.
Not really. Your comment is clearly one that is rooted
on your own loyalty to whatever you like or are good at,
but your point of view is seriously jaded in this regard.
Popularity is my yardstick. One you can't argue with. Like I
said, if you like LISP because it is kept hopelessly obscure,
then more power to you. However, people like myself must eat,
and we must compete in a market that dictates to us, what we
must use, regardless of your opinon of them.
> | 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.
I see that you also stereotype users as well. How 1960's
If I must do the same, then I would have to say "the ones with
money in their pockets".
> | 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.
Things like Visual Basic are generally not used by what you deem to
be "experienced programmers". I think you must retool your thinking,
and avoid the stereotyping that you seem to have fallen victim to.
Perhaps you consider programming to be something only "experienced"
or "good" programmers do. In this regards, you are hopelessly out
of touch with reality.
You really need to get out more. Domain experts are not experienced
or expert programmers, they are experts at their domain, and for these
people, programming is not a career, it's just one of the tasks they
must engage in to solve their various domain-specific problems.
You seem to be under some sort of delusion that programming is
strictly an occupation, in the same sense that "computer operator"
was once an occupation unto itself, rather than just a task that
is performed in many occupations as is the case today.
Guess what?
If the joke is "Real programmers don't use Visual Basic", then
prey tell, why is Microsoft the only one who is laughing?
> I think you are very seriously misjudging good programmers, Tony,
No, You're misjudging good people who don't fit your stereotype.
> 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.
Well, just this further underscores what I say above. Where on earth
did you get the idea that I was referring to products that are only
for "good programmers"?
Perhaps you take far too much for granted. What you might consider
to be "easy", may not be easy to most of the people in the target
audience of a devleopment product.
Anyone who is in business to sell programming tools only to "good
programmers" will not be in business very long.
> 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.
See above. Some people are not programming because they want to
become better or "good" programmers, they're doing it because
they must. And they must do it within a set of constraints that
they or you might not deem the best.
You would probably do well in a world where everyone was a computer
scientist. But unfortunately, this is not that world.
Regards,
In article <··········@mtinsc02.worldnet.att.net>, "Tony Tanzillo"
<·············@worldnet.att.net> wrote:
> In terms of the capabilities and friendliness of LISP IDE's I'd say
> that it is LISP that is lagging behind the mass-market products.
Have you used Lispworks?
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> Have you used Lispworks?
Have you compared it to a typical Windows-based IDE? Perhaps not. It's
easy to dismiss them, just because they're for languages like Basic or
C++. OTOH, there's Pythonwin, which assimilates a hell of a lot more
of the Windows way of doing things than most Lisps.
However, not all Lisps lack a Windows style IDE. Take a look at a
Windows port of SCM, available from: <URL:http://jk.offworld.org/>.
This even includes a Windows style form designer! Recommended.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
No, but I would be happy to take a closer look at it
if you can point me to some info.
Thanks.
Rainer Joswig <······@lavielle.com> wrote in article
<·································@news.lavielle.com>...
> In article <··········@mtinsc02.worldnet.att.net>, "Tony Tanzillo"
> <·············@worldnet.att.net> wrote:
>
> > In terms of the capabilities and friendliness of LISP IDE's I'd say
> > that it is LISP that is lagging behind the mass-market products.
>
> Have you used Lispworks?
>
> --
> http://www.lavielle.com/~joswig/
>
From: Faried Nawaz
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <nf90ubg8ha.fsf@pain.Hungry.COM>
"Tony Tanzillo" <·············@worldnet.att.net> writes:
No, but I would be happy to take a closer look at it
if you can point me to some info.
http://www.harlequin.com/
faried.
--
WAR IS PEACE FREEDOM IS SLAVERY BACKSPACE IS DELETE
"Tony Tanzillo" <·············@worldnet.att.net> writes:
>
> In terms of the capabilities and friendliness of LISP IDE's I'd say
> that it is LISP that is lagging behind the mass-market products.
>
Have come close to Franz ACLPC, Harlequin LispWorks PC, or, even
better, MCL by Digitool?
VC++ came "close" to MCL only recently.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
"Tony Tanzillo" <·············@worldnet.att.net> writes:
>If the joke is "Real programmers don't use Visual Basic", then
>prey tell, why is Microsoft the only one who is laughing?
>> I think you are very seriously misjudging good programmers, Tony,
>No, You're misjudging good people who don't fit your stereotype.
Research into what real spreadsheet programs (written by 'good people'
who aren't 'real programmers') has come up with some *terrifying*
statistics: 1/3rd of them having serious errors (e.g. banks getting
their sums wrong).
I've personally met office workers in legal offices who don't know
why entering money sums as $1-23 (note the minus sign) instead of $1.23
(note the decimal point) is a bad idea. I actually protested about this
once, to be met with blank incomprehension. These are the people writing
and using spreadsheets.
If anyone knows of similar published studies of real-world
Visual Basic programs, I would be very interested to read them.
I would expect the results to be better, but still not good.
>Well, just this further underscores what I say above. Where on earth
>did you get the idea that I was referring to products that are only
>for "good programmers"?
Because the topic was debuggers.
Bad programmers go on safari in flashy debuggers and are not seen again
for weeks. Good programmers prefer advisable debuggers that *don't*
show them things; the less human involvement is required, the faster the
debugging goes.
>See above. Some people are not programming because they want to
>become better or "good" programmers, they're doing it because
>they must. And they must do it within a set of constraints that
>they or you might not deem the best.
What real programming _isn't_ constrained?
Flashy debuggers are a great way to soak up milliards of cycles of
computer time and weeks of programmer time. Give me assertions and
advice packages any time.
I am *not* saying that programming shouldn't be made easier for people
who have to do it, whether professionally or otherwise.
What I *am* saying is that for most tasks, flashy gui debuggers are
a very effective way of making the task *harder*.
--
John �neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL.
Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok
Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote in article
<············@goanna.cs.rmit.edu.au>...
> "Tony Tanzillo" <·············@worldnet.att.net> writes:
> >If the joke is "Real programmers don't use Visual Basic", then
> >prey tell, why is Microsoft the only one who is laughing?
>
> >> I think you are very seriously misjudging good programmers, Tony,
>
> >No, You're misjudging good people who don't fit your stereotype.
>
> Research into what real spreadsheet programs (written by 'good people'
> who aren't 'real programmers') has come up with some *terrifying*
> statistics: 1/3rd of them having serious errors (e.g. banks getting
> their sums wrong).
Perhaps, but what is more important is that these people want
to implement their own solutions, even if that means there'll
be more errors. There is more to it than just handing the user
the proverbial noose. Users often demand total control over their
situations, and pehaps the price they must pay for control, is
a flawed implementation. But the real point is that many domain-
specific solutions are devised and implemented by domain experts.
Of the 1.8 million registered AutoCAD users, over 1 million are
using AutoLISP to automate their workflows. These people are not
trained professional programmers. They are engineers, architects,
land surveyors, industrial designers, and on forth. In many cases,
their use of LISP is limited to simple programs that contain less
than 20 lines of code. If you saw some of the code they write, you
would scream (I often do), but the quality of their code is of
secondary importance. In most cases, they somehow manage to get
the code to work. The reason most of them use AutoLISP is because
it lets them to customize their tools to work they way they want
or need them to work. That is the bottom line insofar as they are
concerned.
> I've personally met office workers in legal offices who don't know
> why entering money sums as $1-23 (note the minus sign) instead of $1.23
> (note the decimal point) is a bad idea. I actually protested about this
> once, to be met with blank incomprehension. These are the people writing
> and using spreadsheets.
> If anyone knows of similar published studies of real-world
> Visual Basic programs, I would be very interested to read them.
> I would expect the results to be better, but still not good.
Visual Basic is used mostly by people with little or no training
or programming experience. So one would expect that most of what
they create with it to be inferior, but in many cases their needs
are relatively simple, so they somehow manage to get by.
The imporant thing about Visual Basic and it's IDE, is that it
makes the language more approachable.
> >Well, just this further underscores what I say above. Where on earth
> >did you get the idea that I was referring to products that are only
> >for "good programmers"?
>
> Because the topic was debuggers.
> Bad programmers go on safari in flashy debuggers and are not seen again
> for weeks. Good programmers prefer advisable debuggers that *don't*
> show them things; the less human involvement is required, the faster the
> debugging goes.
Well, we're back to good programmer/bad programmer thing again.
Like I said. A tool vendor that makes tools for "good programmers"
will never survive.
Aside from that, I have to generally disagree with your comments.
Give me a GUI debugger that breaks on an exception and puts me at
the location where it happened, and allows me to step execution
from there, and see what values are currenly assigned to variables
involved, all without having to press a single keystroke, and I
will run circles around someone with an advisable debugger.
> I am *not* saying that programming shouldn't be made easier for people
> who have to do it, whether professionally or otherwise.
> What I *am* saying is that for most tasks, flashy gui debuggers are
> a very effective way of making the task *harder*.
Not at all. Speak for yourself in this regard. The fact is that
they may be harder for you, but GUI debuggers are not designed
with people like yourself in mind to begin with.
Just out of curiosity, what C/C++ tools do you use, if any?
> --
> John �neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL.
> Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok
>
From: David Thornley
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <65hk86$pkv$1@darla.visi.com>
In article <··········@mtinsc04.worldnet.att.net>,
Tony Tanzillo <·············@worldnet.att.net> wrote:
>Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote in article
><············@goanna.cs.rmit.edu.au>...
>> "Tony Tanzillo" <·············@worldnet.att.net> writes:
>> >If the joke is "Real programmers don't use Visual Basic", then
>> >prey tell, why is Microsoft the only one who is laughing?
>>
>> >> I think you are very seriously misjudging good programmers, Tony,
>>
>> >No, You're misjudging good people who don't fit your stereotype.
>>
>> Research into what real spreadsheet programs (written by 'good people'
>> who aren't 'real programmers') has come up with some *terrifying*
>> statistics: 1/3rd of them having serious errors (e.g. banks getting
>> their sums wrong).
>
>Perhaps, but what is more important is that these people want
>to implement their own solutions, even if that means there'll
>be more errors. There is more to it than just handing the user
>the proverbial noose. Users often demand total control over their
>situations, and pehaps the price they must pay for control, is
>a flawed implementation. But the real point is that many domain-
>specific solutions are devised and implemented by domain experts.
>
There's something wrong here. Most of the business people I've known
have wanted correct answers (or fudged the way they wanted it), and
would rather have their questions answered swiftly and correctly
than get the rush of writing their own spreadsheets. They do want
control, and do pay the price for it. Why is that?
I can think of several possible reasons:
- They don't know any better
- They can't afford to bring in a professional
- They can't communicate with a professional
- The professional is not available when they need her
- Management would rather they used thousands of dollars of their
time rather than hire a professional for hundreds of dollars and
have the spreadsheet working correctly
Obviously, these reasons are not going to go away.
Equally obviously, there is no way to make sufficiently powerful
programming languages safe, and by "sufficiently powerful" I'm
talking about VB and the old Excel macros and other such "user-
friendly" things, as opposed to raw Common Lisp.
On the one foot (out of hands), this is costing companies real
money, when they submit bids that are too high or too low, craft
unworkable budgets, and the like. I really doubt that the one-
third of bad spreadsheets is concentrated in stuff that isn't
financially important.
As a global society, we really do need a better way to do things.
>
>The imporant thing about Visual Basic and it's IDE, is that it
>makes the language more approachable.
>
Yup, we need an approachable language for non-programmers. I have
no experience with VB, so I don't know what's involved here.
Lisp and Scheme would be interesting choices, as they work well in open
designs. A standard spreadsheet is written in C or C++ (or Pascal or ...)
and has a scripting language grafted on. Even if the source code
was shipped with the spreadsheet, it would useless to somebody who
only knew the scripting language. It would be useless to somebody who
wanted to change the spreadsheet behavior unless all the source was
shipped and our enterprising domain expert had the right development tool.
Suppose I were to write a spreadsheet in Lisp and ship it, with the source
for everything but the basic engine. Suppose in addition I included the
Lisp development system. In this case, the user could examine the source
code included and hack it to arrive at the desired results. They'd
be starting from something well-written, with plenty of source code
to look at for tips in getting what they need done. This would at
least be different.
I'm unfamiliar with AutoCad also, so I don't know how it works there.
>
>Well, we're back to good programmer/bad programmer thing again.
>Like I said. A tool vendor that makes tools for "good programmers"
>will never survive.
>
Just because that's a niche market doesn't mean the vendor won't
survive. There is a demand for good programmers for certain projects,
and many people realize that spending ten thousand dollars for
software for each expensive programmer is not necessarily wasteful.
The Macintosh developer's market is not large, but lots of people
sell high-quality tools that are intended for good programmers.
>Aside from that, I have to generally disagree with your comments.
>Give me a GUI debugger that breaks on an exception and puts me at
>the location where it happened, and allows me to step execution
>from there, and see what values are currenly assigned to variables
>involved, all without having to press a single keystroke, and I
>will run circles around someone with an advisable debugger.
>
Really? I've used Metrowerks Codewarrior and Macintosh Common Lisp
pretty much side-by-side, and I don't see that one debugger is
significantly better than the other. (Both do the fairly
elementary stuff which is all I ask from a debugger.)
>> I am *not* saying that programming shouldn't be made easier for people
>> who have to do it, whether professionally or otherwise.
>> What I *am* saying is that for most tasks, flashy gui debuggers are
>> a very effective way of making the task *harder*.
>
Having used several different debuggers, I don't see that a flashy GUI
debugger is any worse than any other one for the basic stuff, and it
may be easier to learn. (On the other hand, if you're going to learn
the half-dozen or dozen commands most used, any debugger will be easy
to learn.) The upside of, say, the Metrowerks debugger is that it's
there, and it's easy to use. The downside is that it doesn't do as
much as Jasik's debugger (for the Macintosh) or gdb (for Unix).
This is why non-serious Mac programmers tend to stick with the
Metrowerks IDE, and the serious ones tend to use the Metrowerks stuff
along with Jasik's debugger, Resourcerer, BBEdit or maybe Alpha for
editing, and so forth. It seems to work pretty well.
>Not at all. Speak for yourself in this regard. The fact is that
>they may be harder for you, but GUI debuggers are not designed
>with people like yourself in mind to begin with.
>
Yup. The Metrowerks debugger is simple and usually sufficient.
If you need more, you can get more. Metrowerks has put some effort
into making their IDE somewhat open, so that you can plug other, more
sophisticated tools in if you like. On a Lisp system, it should be
even easier.
The other, really big, advantage of an IDE is that it works great on
systems with small displays and limited or no multitasking. Writing
C in an IDE versus writing it on an X display with separate windows
for vi, gcc, and gdb is a matter of tradeoffs: the IDE will be easier
to use, and the X combination will be more powerful. If I can't have
multiple applications at once, I want the IDE.
--
David H. Thornley | These opinions are mine. I
·····@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly.
Richard A. O'Keefe wrote in message <············@goanna.cs.rmit.edu.au>...
>"Tony Tanzillo" <·············@worldnet.att.net> writes:
>Research into what real spreadsheet programs (written by 'good people'
>who aren't 'real programmers') has come up with some *terrifying*
>statistics: 1/3rd of them having serious errors (e.g. banks getting
>their sums wrong).
>
>If anyone knows of similar published studies of real-world
>Visual Basic programs, I would be very interested to read them.
>I would expect the results to be better, but still not good.
>
I don't know of any formal studies, but I've seen enough anecdotal evidence
that naive programmers generate just as bad code in VB as in spreadsheets to
be convinced. The problem is that naive users, when using visual
environments, tend to mix construction of the GUI with the construction of
the underlying domain models and mix those models with the database or I/O
aspects of the product, leading to a hodgepodge of mixed code with tons of
modality and intertwining that makes maintenance a nightmare (BTW, there's a
guy in my office who has had 5+ years in VB, who loves Microsoft stuff, and
HE says the same thing). You get the same effects (but to a lesser extent
because of the oo discipline) in some of the more modern Smalltalks and
Lisps with visual environments. The only cure is to use the GUI
construction tools carefully and to be aware of the different layers of your
system (view vs. model vs. persistant store) and separating these facets
best as possible. Alas, few VB programmers ever reach this stage of
enlightenment, "Learn Visual Basic in 21 Days" and the Microsoft online help
system being the last programming documents they've read. I'm sure we'll
have another round of this type of code from the Java developers out there.
I guess it eventually leads to job security for those who can actually
produce maintainable code.
>>Well, just this further underscores what I say above. Where on earth
>>did you get the idea that I was referring to products that are only
>>for "good programmers"?
>
>Because the topic was debuggers.
>Bad programmers go on safari in flashy debuggers and are not seen again
>for weeks. Good programmers prefer advisable debuggers that *don't*
>show them things; the less human involvement is required, the faster the
>debugging goes.
>
In fact, "good" programmers rarely use their debuggers for little other than
verification of correct program flow. If you start finding logic errors,
it's a sign that there has been a severe screw up in your understanding and
design and most "good" programers at that point drop back five yards and
take a new look at the problem. If a user is so inexperienced that he needs
a fancy debugger, he's probably inexperienced enough to use it in an
extraordinarily inneffective manner.
>I am *not* saying that programming shouldn't be made easier for people
>who have to do it, whether professionally or otherwise.
>What I *am* saying is that for most tasks, flashy gui debuggers are
>a very effective way of making the task *harder*.
Those who live by the debugger die by the debugger...
--
Frank A. Adrian
First DataBank
············@firstdatabank.com (W)
······@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote:
> What I *am* saying is that for most tasks, flashy gui debuggers are
> a very effective way of making the task *harder*.
I only can second that. Those "cool" debuggers (actually I would call
them "buggers" instead ;-) ) are the first thing that I deinstall. Even
hand-written debugging support for C-programming is better than those
GUI-monsters.
bye, Georg
From: Erik Naggum
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <3089644951937358@naggum.no>
* Georg Bauer
| Those "cool" debuggers (actually I would call them "buggers" instead ;-) )
how about "rebuggers"?
#\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.
Tony Tanzillo wheezed these wise words:
> Not really. Your comment is clearly one that is rooted
> on your own loyalty to whatever you like or are good at,
> but your point of view is seriously jaded in this regard.
I like the "choice space" idea. I often suspect that there are points
in choice space which are not only further from others (imagine a
metric for edit distance in choice space), but from where some other
points might not even be visible.
Perhaps you and Erik are sitting in points in a choice space from
which one or even both of you are unable to share the point of view of
the other person. Overzealous loyalty may certainly blind people to a
point of view that differs from their own. Consider the hordes of C++
programmers happy to slag off any language not called C++.
Years of attacks on Lisp from C++ zealots may have created a "siege
mentality" amoubg some Lisp people. I wouldn't blame them if this was
indeed the case, as I've felt some of this myself at times. Now the
heat is on Java, using exactly the same arguments! Isn't it amazing
that people can know so little about a language that the same attacks
can be made on a totally different language?
Fortunately, not all C++ programmers are so clueless. It's easy to
forget this, when you can see so many bad examples. It's also very
convenient to only think of these bad examples if you want to believe
that nobody but Lisp programmers can have anything of value to say.
This is a standard tactic in any kind of war with words. Only use the
worst case for your opponents, and only use the best case for
yourself.
> Popularity is my yardstick. One you can't argue with. Like I
> said, if you like LISP because it is kept hopelessly obscure,
> then more power to you. However, people like myself must eat,
> and we must compete in a market that dictates to us, what we
> must use, regardless of your opinon of them.
Well, some people _will_ argue with the popularity yardstick. Most
people will ignore them, tho. I've lost count of how many times I've
seen a C++ programmer use the numbers argument, only to be countered
with one word: Cobol.
However, I agree with you about competing in a market. Naturally, we
don't all compete in the _same_ market. Not even all Lisp programmers
do that. While, in theory, Lisp can be used in all areas of commercial
software development, in practice we have to code for a market. That's
what makes it commercial. In that sense, we're constrained by who will
pay us. That, in turn, is dependant on where we look for work etc.
You get paid to write code in AutoLisp. That shapes your perspective.
Using AutoLisp helps define your options, and most certainly defines
your market. Markets make demands. All pretty obvious to you and I,
but perhaps not so obvious to everyone.
IMHO Lisp is flexible enough to meet the demands of a wide variety of
programmers. It doesn't have to be a "One size fits all", with a
single Lisp for all Lisp programmers. My guess is that this isn't
possible, simply because the markets for which Lisp is used are just
to varied. Let me know if this changes, and AutoDesk add a full CL to
their CAD app, but I won't hold my breath for it. The market doesn't
appear to demand it (you'll know this better than I ever will).
It's also possible that the market for CL systems doesn't demand a GUI
debugger of the kind found in tools like VB. OTOH, that's possibly a
circular argument, as programmers seeking a GUI debugger might be less
inclined to use a development system without one.
See what I mean about choice space and viewpoints? Seek nought and you
shall find nought. It works for everyone.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> to varied. Let me know if this changes, and AutoDesk add a full CL to
> their CAD app, but I won't hold my breath for it. The market doesn't
> appear to demand it (you'll know this better than I ever will).
Why being so negative? How about this recent job offer from Autodesk...
---------------------------------------------------------------------
Date: Tue, 28 Oct 1997 15:13:39 -0800
From: ROB LEVINE <··········@autodesk.com>
Autodesk, the leader in design and animation software for the PC,
develops, sells and supports products for CAD, Internet, Virtual
Reality, and Multimedia applications running on PC's and Work-
stations.
The company is headquartered in Marin County (Bay Area).
RELOCATION ASSISTANCE IS AVAILABLE WHERE NEEDED.
_____________________________________________________________________
SEE OUR HOMEPAGE FOR OTHER JOBS:
http://www.autodesk.com/compinfo/career/career.htm
_____________________________________________________________________
ENG#7676
Title: Programmer/Software Engineer V
Location: San Rafael, CA
Purpose:
This senior software development position will be responsible for the clean
integration of a new generation of Lisp language technology into the AutoCAD
product. This technology, including a compiler and integrated development
environment is currently implemented as an ObjectARX application running as
an extension of AutoCAD R14. The person filling this position will be part
of the team working out the architectural issues involved in creating a
tighter coupling between the product essentially replacing the existing
AutoLISP implementation with this newer technology.
Essential Duties and Responsibilities:
� Work as key member of team integrating new Lisp technology into the AutoCAD
product.
� Evaluate and recommend various technical possibilities for expanding AutoLISP
coverage in future AutoCAD releases including closer correspondence with
Common Lisp.
� Design and implement core architectural changes needed to bridge various
programming environments including AutoLISP and VBA implementations.
� Provide inputs for documentation of new or existing programs.
� Research and understand the marketing requirements for a product, including
target environment, performance criteria and competitive issues.
Secondary Duties and Responsibilities:
� Research new technology or development tools to remain abreast of current
technology.
Education & Training:
� Degree in Mathematics, Software Engineering or Computer Science, or
equivalent experience.
Specialized Knowledge & Skills:
� Advanced software development and architectural skills with excellent
knowledge of OOP Programming Techniques, OOD/OOA, and Windows.
� Strong understanding of ActiveX Automation technology.
� Strong background in Lisp programming language and dialects
� Excellent C++ programming skills and experience.
� Knowledge of the Windows 95, and NT software development tools.
� Thorough technical knowledge in software development methodologies,
design and implementation.
� Excellent analytical and design skills at product and project level.
� In-depth experience in research and analysis, project planning and
implementation.
� Aware of business issues as they impact overall project plans.
� Recognized reference and central point for technical issues across groups
and products.
� Strong communications (both written and oral) and interpersonal skills.
Other Relevant Skills and Experience:
� Visual C++, Visual Basic for applications; Computer Aided Design, Software
Development experience with a commercial CAD vendor; OLE Client, Server,
Automation.
Work Experience:
� 6+ years of technical experience in software development environment.
� Experience in the design, implementation and testing of application
programming interfaces, particularly in the area of ActiveX Automation.
� Proven experience developing commercial applications.
Position Available: Immediately!
--------------------------------------------------------------------
Autodesk is an Equal Opportunity Employer!
All interested applicants should Email cover letter and resume
(word processed document or ascii text, please)
to: ···········@autodesk.com
Also, you can reach us via FAX @ 415-507-6361, or mail correspondence to:
Autodesk,Inc.
Worldwide Employment
111 McInnis Parkway, San Rafael, CA 94903.
Please indicate the name & number of the position on all submissions.
Rob Levine / 800-653-9452
--
http://www.lavielle.com/~joswig/
Tony Tanzillo wheezed these wise words:
> Your comments seem to underscore the reasons why LISP has, or
> is perceived by most, to have failed.
The operative word here is probably "perceived". Whatever the truth
may be, perception is ultimately what sells software. How or where
that perception comes from will depend on a great many factors, not
least word of mouth. Without a massive advertising compaign, word of
mouth may be very powerful.
Which words and whose mouth? Ahh. The most positive comments I've
found in the last 5 years have been right here. But who reads this
newsgroup, apart from Lisp hackers and people already curious about
Lisp? Preaching to the converted is easy, as is teaching to those
eager to learn.
Is it shocking that some of us here don't think that Lisp is perfect
in _all_ respects? Possibly. OTOH, the phrase "..but you can't please
all people the people all the time" springs to mind.
> 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.
That's an alternative to the proactive approach, which creates new
things before most of us realise that we need them. The real
visionaries can do this decades before that need arises.
I'd certainly describe Lisp as a tool for building such tools, and
probably even one of those tools itself. Strangely, few people are
interested in such things, instead prefering tools like VB, C++, etc.
So perhaps Lisp is still ahead of its time? In most respects, yes. In
terms of graphical debuggers, perhaps not. Again, this is a matter of
perception. The wrong perception may deter many people from learning
the language and discovering the truth.
Many will perceive Lisp's way of doing things as serious retro. Typing
commands into a listener, for example. The "point and click", "drag
'n' drop" style is rather dominant. While the Lisp language can easily
beat most other languages, Lisp environments are very different.
I don't care too much, as I stopped using "symbolic debuggers" years
ago, when I began writing recursive code. Whether I use assembly
language, C, or Lisp, my choice of debugging is a app specific trace,
implemented by sprinkling the code with trace code for selected
variables and control flow points.
This is mainly coz I tend to run the same code over and over, using
the trace to highlight errors without thinking "Something's wrong" and
running a debugger to see why. Call it "proactive debugging".
> 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.
I appreciate people who dare to make bold moves. Too many companies
seem to be driven by accountants. Sometimes it's important to do
things _because you can_. We can't always prove that a thing has
"value" before we create it. Remember the light bulb?
> The LISP language is getting its ass kicked by things like
> Visual Basic. A cruddy pile of garbage Visual Basic may be,
> but what does that matter?
Perception may matter more. There are many ways to measure the value
of a tool. Note that Bill Gates likes Basic. MS may sell a Basic
simply _because they can_, but I'm sure a little support from the top
can also help. How many big name companies give as much status to
Lisp? Note that I'm not asking about who uses Lisp, nor who sells it.
I'm asking about status. Whether we like MS or not, we should at least
admit that they have a rather powerful influence over the status of
the languages that _they_ use and sell.
In spite of briefly selling MuLisp, MS appear to have done little to
support this product or Lisp in general. Thus, the software industry's
perception of Lisp is untouched by MS - unless there are people saying
things like, "Lisp must be good because MS once sold it", or "Lisp
must be shite because MS sold it and then dropped it." As I've not
noticed them, I suspect that Lisp may be perceived as being untouched
by MS. Most people may even be completely ignorant of this connection
between MS and Lisp, while the MS/C++ and MS/Basic links are all to
apparent. In spite of these perceived links, C++ and Basic survive.
> A non-programmer (which is what most VB users are) can make use
> of intelligent editing features that put the information they
> need at their fingertips. They can move their cusor over a
> variable in the editor while they are debugging, and see the
> value assigned to it.
This is perceived by many as a good thing. The lack of such features
is perceived as being a bad thing. Whether right or wrong, this is
often the case. FWIW.
> 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.
Hmm. Visual Common Lisp? I too would wish to buy such a system.
Meanwhile, I compromise with LWW and a search for the next best thing
to Lisp. However, I'm not greatly concerned about the lack of an IDE
based debugger. I even debug Windows programs using a trace.
> The AutoLISP IDE I was referring to is probably the most
> user-friendly LISP IDE in existence. It highlights code
> in the editor as you step through it. It displays variables
> in a watch window, and lets you "animate" the execution of
> a LISP program (automatic stepping at a given time interval).
I've never seen this sone in AutoLisp, but I'll take your word for it.
This would indeed please many people.
> A novice can actually watch a program execute, by seeing
> visually observing program logic flow.
Ah, the novice. An often forgotten creature, and usually the target
for much derision when remembered. Alas.
> The point to this is that feautures like these are what
> help people learn to use a language, which in-turn is
> what helps make the language more popular. It has been
> proven that people will use whatever is easiest to use.
The sales of some software certainly depend on such factors.
> They're not computer scientists with an opinon on every
> language on the planet, they're people who need to solve
> problems, not create more of them.
Ah, the "little people". An often forgotten species, and usually the
target for much derision when remembered. Alas.
> Judging by the unfriendly nature of most LISP systems, I
> get the impression that their designers don't want anyone
> to use LISP.
"Increasingly, people seem to misinterpret complexity as
sophistication, which is baffling -- the incomprehensible
should cause suspicion rather than admiration. Possibly this
trend results from a mistaken belief that using a somewhat
mysterious device confers an aura of power on the user."
-- Niklaus Wirth
Hmm.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
* Tony Tanzillo wrote:
> 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.
It's hard to imagine anything more badly wrong than this statement.
Let's look at Window systems. Quite a lot of the crazy lunatics with
vision were at Xerox PARC, and produced stuff years ahead of its time.
Then some more customer-driven people with less vision at Apple did
some fairly derivative stuff. Finally some people at Microsoft with
practically no vision at all, but a great desire to become rich by
giving people what they wanted, did Windows. Who became rich here?
Who became a major success? Who is the richest person in the world?
Let's look at IDEs. Some people at MIT had a pretty cool vision about
interactive programming environments in the 70s, and some slightly
more customer-driven people at Symbolics and LMI made commercial
sysems based on those in the 80s. People at Xerox were doing even
more radical stuff with Interlisp-D. Then a whole bunch of
commercially-minded customer-driven type people started doing
derivative stuff, and got rich.
So forget it. People with vision go bankrupt; people who are
remorselessly customer-driven get rich.
Of course they also get driven by customers into these little
prettified development environments which are of very little if any
use to people who write large-scale systems.
--tim
Tim Bradshaw wheezed these wise words:
> So forget it. People with vision go bankrupt; people who are
> remorselessly customer-driven get rich.
Agreed. See the URL:http://www.bootstrap.org> website. The man who
created the mouse craze has only recently been given credit for it.
I dunno if he's bankrupt, as he has his own website, but I doubt that
he's rolling in as much money as some commercial mice vendors.
The big problem with being remorselessly customer-driven is that large
numbers of people will thank you, while most visionaries will remain
unknown to the vast majority the daily users of their inventions. Few
of them will care. OTOH, why should they? _We_ may appreciate the
ideas of visionaries, and the visionaries themselves, but to most
people a mouse is just a tool.
Let's not expect everyday users to see things as we do. If AutoLisp
users expect a GUI debugger, and they get one, then that's wonderful.
There's nothing wrong with that. They're happy users. If they were
power users, they might not be so happy, but most users are not.
Do we have to judge everything by the standards of power users and
programmers? "One size fits all" doesn't work. We can give users the
tools that match their needs, do it without insisting that they all be
programmers, and civilisation won't crumble.
I wonder how different the world would be if only programmers could
use computers. Would it be a better world? YMMV. Enough people choose
otherwise. The important question is how do we live with that choice?
OTOH, just go ahead and flame someone for asking for a GUI debugger.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
> > 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.
>
> It's hard to imagine anything more badly wrong than this statement.
> Let's look at Window systems. Quite a lot of the crazy lunatics with
> vision were at Xerox PARC, and produced stuff years ahead of its time.
> Then some more customer-driven people with less vision at Apple did
> some fairly derivative stuff. Finally some people at Microsoft with
> practically no vision at all, but a great desire to become rich by
> giving people what they wanted, did Windows. Who became rich here?
> Who became a major success? Who is the richest person in the world?
Vision alone will not work. As I mentioned, you must have the guts
to take bold risks. The people at Xerox Parc (and Zerox itself)
did not have the guts necessary to bring their fruit to market.
> Let's look at IDEs. Some people at MIT had a pretty cool vision about
> interactive programming environments in the 70s, and some slightly
> more customer-driven people at Symbolics and LMI made commercial
> sysems based on those in the 80s. People at Xerox were doing even
> more radical stuff with Interlisp-D. Then a whole bunch of
> commercially-minded customer-driven type people started doing
> derivative stuff, and got rich.
Again. Symbolics failed because it did not have the guts or the
marketing savvy. You can't simply invent great stuff and then
sit back and admire it.
> Of course they also get driven by customers into these little
> prettified development environments which are of very little if any
> use to people who write large-scale systems.
Here we go again..... "people who write large-scale systems"???
So, a pattern begins to emerge here. Most if not all responses
to my comments make reference to a group of elite (to which all
respondents seem to include themselves in), which they have
called "good programmers", "experienced programmers", and now
"people who write large-scale systems".
Hmmmmm.....
I hate to break this to you, but most people don't need to write
large-scale systems. Only a damn fool would go into business
catering to such limited number of elite individuals. I suppose
that is why the cost of LISP systems are so astronomical.
I'm beginning to get the impression that members of the LISP
community tend to regard themselves as an elite bunch who writes
large-scale systems, and don't need no damn GUI.
That's how they'll be eulogized.
Regards,
From: Will Hartung
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <vfr750EK88tq.5t8@netcom.com>
"Tony Tanzillo" <·············@worldnet.att.net> writes:
>I hate to break this to you, but most people don't need to write
>large-scale systems. Only a damn fool would go into business
>catering to such limited number of elite individuals. I suppose
>that is why the cost of LISP systems are so astronomical.
You're right "most" don't. At least, they don't think they do.
The most common "large scale system", business accounting and
distribution, has become almost a commodity for many. But, remarkably,
there is enough of a difference between business needs and special
requirements to give the market a zillion packages ranging from
QuickBooks and PeachTree to SAP.
Yet, with all of this variety, there are industries where they still
need to write, almost from scratch or even the barest foundation (a
simple GL, AP, and AR), a large portion of their core business
transactions. (That's MY world, even though it's not a Lisp world).
Lisp systems are really not overly priced when compared to other,
non-main-stream tools. Even the main-stream tools cost updwards to $2K
for their "enterprise" editions. There are a LOT of tools in the
$3K-$5K per seat range. And some, dig this, even charge $500+ per seat
RUNTIME.
Of course, probably even more disturbing, is that THEY GET IT! People
look over the market, look over their needs, check their resources,
and they BUY THIS STUFF! OH MY GOD! No gun to their head. No dark
dungeons with shock prods. None of that. They actually, consciously
choose a $3K tool over $99 VB.
Just what IS the world coming to?
How is it possible that a company can survive selling such outrageously
priced tools? How is it possible that a company can survive BUYING such
tools? and..and..(the nightmare) funding the costs of bootstrapping
their employees and paying more, horrible prices, by getting them a
little formal training?
The world isn't one big flat market. There are a lot of niches that
poke their heads out and can be effectively solved with a plethora of
more specialized, more advanced tools. The current Lisps happen to be
one of those tools.
Just because you are not looking for, or do not use such tools does not
mean that they don't exist, are not in demand, don't offer tangible
value to their purchasers, or are not successful in their domain.
Fortunately, there is a mass market for the mass marketers. It helps
fuel their corporations, pay their employees, and brings tax revenue
to the their communities and their countries. But now, programming is
being reduced to the realm of "shade tree" programmers. It started as
a science, became understood enough to engineer it, and now we've got the
new assembly line trade in the US. Both because of demand for the
skills, and because of the mass markets tools and press proclaiming
its great ease.
Any programmer with any real experience, the "elite", know that this
"ease" is a myth. The mass market books show a shining path through the
trees to the sunlit meadow, but when you follow the directions somehow
it starts raining, gets dark, you're cold and you can't find your car.
Here the books don't help. They don't even burn well. You're on your
own and all alone. All you have is some book whose best quality is as a
flower press.
They ease the easy stuff, but the hard stuff is still hard.
I swear to you we had a junior programmer in here who had been working
for 6 months that knew that "RAM" and "Hard Disk" existed, but not why
one was slower than the other or how they worked. Some may consider
the fact that this person could write programs an advancement, but I,
being an "elitist", think it shows how far down this industry is
sliding. Because I know that there are a lot of other folks out there
just like him. A frightening thought.
A button pusher and knob puller.
No matter how many magazines you read, how many feet of bookshelf space
they take in the bookstores, or what you may see on TV, the mass market
is not the TOTAL market.
There is a lot of room for specialized tools for advanced applications.
Applications that need a bit more oomph than the "mass market"
programmer and tools that lose a bit on glitz and glamour, but win
with horsepower and torque under the hood.
Not everyone needs to have their buttons pushed and levers pulled
automatically. Some find these automations nothing more than a hole
they have to inevitably dig out of after discovering that not only did
the Yellow Brick Road of Wizards(tm), Experts(tm), and Drag and Drop(r)
not lead them to Oz, but was still under construction when you hit
the poppy fields.
You can keep your road, I'll take a Unimog.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Will Hartung wheezed these wise words:
> They actually, consciously choose a $3K tool over $99 VB.
Is this the only choice available? The message you're giving is that
this is it. If you choose Lisp, then you should expect to pay much
more, and if the rewards are not seen as big enough to justify that
cost, then the only other option is VB? I'd love to be able to tell
people that this is the only choice, but they won't buy it while there
are other options, like C++. Never mind that C++ sucks farts from dead
cats, coz they believe the same thing about Lisp.
Your argument is perfect for those people who've been programming for
more than a couple of decades, and who believe that realistic
solutions can be created with _C++_. Not only that, but they're _doing
it_. If you're saying that these people are writing software for the
plebs, and may perhaps plebs themselves, no wonder people are so much
hostile toward Lisp. Nobody likes to be a called a pleb. We all like
to believe that we're the elite. Lisp folk look down on C++ folk, who
C++ folk look down on VB folk, who look down on Cobol folk, and so on.
Now, let's suppose that there's nothing wrong with creating a
heirarchy. Everybody wants to be at the top of their heirarchy, and
(what a coincidence!) somehow manages to create a heirarchy with
themselves at the top. The fact that many heirarchies contradict each
other can be explained by claiming that anyone lower down in your
heirarchy is clueless, and therefore don't count. Never mind that
there are programmers who disagree with you and who have decades of
experience to "compete" with your decades of experience.
Could there be a Lisp available to the plebs that can compete directly
with tools like VC++, or is this a case of "Let them eat cake"? In
case you had't noticed, there's a heck of a lot of plebs out there,
and they have to use _something_. If you expect them to see the light,
each shell out $3000 for a Lisp, then it won't happen. Not because
they're dumb, but because they have an alternative.
You've just explained why most people ignore Lisp, why some of those
who've heard of Lisp are so hostile to it, and why only a small number
can see the light. I think that where you're mistaken is in assuming
that this makes you "better". It's that heirarchy business again,
and it gets up people's noses. I agree with you about Lisp's "oomph",
but I don't feel that this is only for the elite. I'd also like to use
this power for writing the "little" apps, and I'm not alone.
Perhaps that's why Dylan looks so incredibly tasty...
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
Will Hartung wheezed these wise words:
> You can keep your road, I'll take a Unimog.
Why can't Lispers have both?
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Faried Nawaz
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <nfafergab2.fsf@pain.Hungry.COM>
"Tony Tanzillo" <·············@worldnet.att.net> writes:
That's how they'll be eulogized.
Eulogy -- high praise. Perhaps you meant "elegy"?
faried.
--
WAR IS PEACE FREEDOM IS SLAVERY BACKSPACE IS DELETE
* Tony Tanzillo wrote:
> I hate to break this to you, but most people don't need to write
> large-scale systems. Only a damn fool would go into business
> catering to such limited number of elite individuals. I suppose
> that is why the cost of LISP systems are so astronomical.
> I'm beginning to get the impression that members of the LISP
> community tend to regard themselves as an elite bunch who writes
> large-scale systems, and don't need no damn GUI.
I'm not quite sure what you're implying here. Are you trying to say
that the people who need to write large systems must only use tools
suitable for small systems? That there is no longer any need for
large systems? That the companies that do cater to large system
people should just give up?
Of course most people don't need to write large scale systems. But
those who do and those who cater to them are not stupid or wrong.
They just have different priorities than people who don't have to do
that.
Anyway, I don't have any more to say about this.
--tim
Tim Bradshaw wheezed these wise words:
> I'm not quite sure what you're implying here. Are you trying to say
> that the people who need to write large systems must only use tools
> suitable for small systems? That there is no longer any need for
> large systems? That the companies that do cater to large system
> people should just give up?
Do you mean that people writing small (that's a relative term) apps
can't use Lisp? "One size fits all" means that tools for small apps
might not be scale up for larger apps, but the reverse may also be
true. Maybe this is why AutoLisp differs from Common Lisp?
> Of course most people don't need to write large scale systems. But
> those who do and those who cater to them are not stupid or wrong.
> They just have different priorities than people who don't have to do
> that.
Agreed. This is IMHO why AutoLisp is different from CL. It just looks
like Tony Tanzillo is asking why CL is different from AutoLisp. He's
also given an excellent answer: the demands of the markets. AutoLisp
has a distinctly different market to CL systems, which are generally
not built into a massively popular CAD app. AutoLisp, OTOH...
> Anyway, I don't have any more to say about this.
Let's avoid repeating ourselves further. ;)
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> has a distinctly different market to CL systems, which are generally
> not built into a massively popular CAD app. AutoLisp, OTOH...
Some of the larger CAD systems which are popular
in engineering are written in CL (ICAD, ...).
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> Some of the larger CAD systems which are popular
> in engineering are written in CL (ICAD, ...).
That's why I said _massively popular CAD app_.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Rainer Joswig
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <347CA5B1.DEC29541@lavielle.com>
Martin Rodgers wrote:
> Rainer Joswig wheezed these wise words:
>
> > Some of the larger CAD systems which are popular
> > in engineering are written in CL (ICAD, ...).
>
> That's why I said _massively popular CAD app_.
By what are you measuring this? By amount of sold copies? Or by value of
sold
copies?
Rainer Joswig wheezed these wise words:
> > That's why I said _massively popular CAD app_.
>
> By what are you measuring this? By amount of sold copies? Or by value of
> sold
> copies?
Even simpler than that. By the number of reviews and references found
in popular computer magazines, and the amount of support, books,
online forums, etc. If there's a better selling CAD app for micros, it
has a much lower profile than AutoCAD in the media and elsewhere.
For example, see these resources: <URL:http://www.acad.co.uk/>.
Hence the words "massively popular". You can dispute this if you like,
but remember what I was saying about markets. Pick a market. Even the
CAD market can be divided into smaller markets.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> Even simpler than that. By the number of reviews and references found
> in popular computer magazines, and the amount of support, books,
> online forums, etc.
How do you define "popular"? Popularity is relative.
If an application is popular in engineering like some
stuff from PTC and it happens to be written in Lisp,
and you won't find articles in the Newspaper - is it popular
or not? Still chances are good that the Boeing you
are flying with or the car you are driving has parts
that have been designed with some of those tools.
If you are looking for work in shops you find in hundreds
over the country, good luck. But if you want do something
interesting....
But then you are again reiterating your posts from last year.
Why not make some progress? Btw., http://cowsim.milka.de/
is a site where we have done the programming with SIOD.
It is german and you'll need Macromedia Shockwave
(which is a bit unstable, but fun) to visit.
Ask Milka for an english version. ;-)
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> How do you define "popular"? Popularity is relative.
I stated my definition. "Vox populi".
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
AutoCAD has about 80% of the PC-CAD market (based on
installed units, not value). It has a handful of
dedicated publications, and hundreds of books.
Other CAD products use LISP for scripting. Most notable
are various high-end electronic design automation tools
(which integrate CAD with simulation and other functions),
and use their own flavor of R4RS or CL.
There are also a number of high-end CADD and design tools
originally developed by Evans & Sutherland, that were
subsequently acquired by Parametric Technology, which use
ACL.
In the 80's, Autodesk put many of the dedicated CAD systems
vendors out of business, with their "90% of the features for
10% of the price" strategy. Unfortunately Autodesk is about
to fall victim to that same strategy.
In the past two years, four CAD products have either been
released or announced, all of which sell for 10%-20% of the
cost of AutoCAD, and all of which have AutoLISP-compatible
LISP interpreters that can run existing AutoLISP programs
without modification.
The help-wanted add that was posted by someone in this thread,
is essentially part of a strategic countermeasure that aims
to make AutoLISP more proprietary, and more difficult to clone.
Martin Rodgers
<···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk> wrote
in article <·························@news.demon.co.uk>...
> Rainer Joswig wheezed these wise words:
>
> > > That's why I said _massively popular CAD app_.
> >
> > By what are you measuring this? By amount of sold copies? Or by value
of
> > sold
> > copies?
>
> Even simpler than that. By the number of reviews and references found
> in popular computer magazines, and the amount of support, books,
> online forums, etc. If there's a better selling CAD app for micros, it
> has a much lower profile than AutoCAD in the media and elsewhere.
>
> For example, see these resources: <URL:http://www.acad.co.uk/>.
>
> Hence the words "massively popular". You can dispute this if you like,
> but remember what I was saying about markets. Pick a market. Even the
> CAD market can be divided into smaller markets.
> --
> Please note: my email address is munged; You can never browse enough
> "Oh knackers!" - Mark Radcliffe
>
From: Rainer Joswig
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <347E84B8.802904F7@lavielle.com>
Tony Tanzillo wrote:
> The help-wanted add that was posted by someone in this thread,
> is essentially part of a strategic countermeasure that aims
> to make AutoLISP more proprietary, and more difficult to clone.
To say it more positively, Autocad would get a modern Lisp
implementation.
The original implementation was based on Xlisp. Even
XLisp author David Betz offered them help to improve it long ago.
This has long been overdue.
Yeah, making a product better, improving it is letting it be
more proprietary - which makes the word
"proprietary" even more useless. I never understood
the difference of "proprietary" and "open".
These words are marketing slogans - nothing more.
I wouldn't call what AutoCAD is getting a modern LISP
implementation (the product that they've purchased has
been around for some time, and I have it right here).
There's nothing all that modern about it. For Autodesk,
it serves to make AutoLISP applications dependent on
newer AutoCAD functionality that is not available in
other competing products with AutoLISP-compatible LISP
interpreters, and it provides a way to deploy LISP
applications in an encrypted form that will not allow
them to be read by other AutoLISP-compatible LISP
interpreters.
The cliam that they want to modernize the implementation
of LISP, to bring it more in-line with Common LISP is
pure bovine excrement. Of course, that's the publicly
stated reason for Visual LISP (which is what it's being
called by Autodesk). The actual reasons for it are the
ones I mentioned.
BTW, Autodesk recently purchased the company that was
in the process of developing the AutoCAD-compatible
software with the AutoLISP-compatible LISP interpreter.
They purchased that company in order to eliminate the
AutoCAD-compatible product before it reached market.
Unfortunately for Autodesk, in the process of reviewing
the merger, the United States Department of Justice
intervened, and charged Autodesk with attempting to
restrict free and fair competition by purchasing the
company developing the AutoCAD-compatible product, and
of course, the product along with them.
Before Autodesk could purchase that company, it had to
first divest itself of the AutoCAD-compatible technology.
It did that, and sold it to Visio, who is now bringing
it to market (see http://www.visio.com/intellicad).
In the mean time, Autodesk was forced to sign a consent
decree which prevents it from re-acquiring the product
for a period of 10 years.
Could you also say this in a more positive way?
--
Rainer Joswig <······@lavielle.com> wrote in article
<·················@lavielle.com>...
> Tony Tanzillo wrote:
>
> > The help-wanted add that was posted by someone in this thread,
> > is essentially part of a strategic countermeasure that aims
> > to make AutoLISP more proprietary, and more difficult to clone.
>
> To say it more positively, Autocad would get a modern Lisp
> implementation.
> The original implementation was based on Xlisp. Even
> XLisp author David Betz offered them help to improve it long ago.
> This has long been overdue.
>
> Yeah, making a product better, improving it is letting it be
> more proprietary - which makes the word
> "proprietary" even more useless. I never understood
> the difference of "proprietary" and "open".
> These words are marketing slogans - nothing more.
>
>
>
Rainer Joswig <······@lavielle.com> wrote in article
<·················@lavielle.com>...
> Tony Tanzillo wrote:
>
> > The help-wanted add that was posted by someone in this thread,
> > is essentially part of a strategic countermeasure that aims
> > to make AutoLISP more proprietary, and more difficult to clone.
>
> To say it more positively, Autocad would get a modern Lisp
> implementation.
> The original implementation was based on Xlisp. Even
> XLisp author David Betz offered them help to improve it long ago.
> This has long been overdue.
>
> Yeah, making a product better, improving it is letting it be
> more proprietary - which makes the word
> "proprietary" even more useless. I never understood
> the difference of "proprietary" and "open".
> These words are marketing slogans - nothing more.
>
>
>
I wouldn't call ICAD popular. Not even close.
Relatively speaking, ICAD is about as obscure as it
gets. That's understandable, considering that when
I first tried it, it crashed close to a dozen times
in a matter of an hour (which is about how long it
was on my hard drive).
ICAD is about 1/10 the speed of most modern PC-based
CAD systems (based on a standard benchmark), and has a
grossly-obtuse, 1970's-era user interface.
Martin Rodgers
<···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk> wrote
in article <·························@news.demon.co.uk>...
> Rainer Joswig wheezed these wise words:
>
> > Some of the larger CAD systems which are popular
> > in engineering are written in CL (ICAD, ...).
>
> That's why I said _massively popular CAD app_.
> --
> Please note: my email address is munged; You can never browse enough
> "Oh knackers!" - Mark Radcliffe
>
Tony Tanzillo wheezed these wise words:
> I wouldn't call ICAD popular. Not even close.
I was refering to AutoCAD, of course. ;-)
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <··········@mtinsc04.worldnet.att.net>, "Tony Tanzillo"
<·············@worldnet.att.net> wrote:
> ICAD is about 1/10 the speed of most modern PC-based
> CAD systems (based on a standard benchmark),
Which shows again that people are comparing apples with oranges.
--
http://www.lavielle.com/~joswig/
What you do mean by 'apples' and 'oranges'? I was
running ICAD on an Intel-based Windows NT machine.
ICAD and most modern PC-based CAD products are designed
to do exactly the same thing.
What is the significance to any distinction that you
percieve to exist between ICAD and most other PC-based
CAD systems?
--
/*******************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Expert AutoCAD Programming and Customization */
/* --------------------------------------------------- */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* --------------------------------------------------- */
/* ·············@worldnet.att.net */
/* ·····@compuserve.com */
/* --------------------------------------------------- */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*******************************************************/
Rainer Joswig <······@lavielle.com> wrote in article
<·································@news.lavielle.com>...
> In article <··········@mtinsc04.worldnet.att.net>, "Tony Tanzillo"
> <·············@worldnet.att.net> wrote:
>
> > ICAD is about 1/10 the speed of most modern PC-based
> > CAD systems (based on a standard benchmark),
>
> Which shows again that people are comparing apples with oranges.
>
> --
> http://www.lavielle.com/~joswig/
>
What you do mean by 'apples' and 'oranges'? I was
running ICAD on an Intel-based Windows NT machine.
ICAD and most modern PC-based CAD products are designed
to do exactly the same thing.
What is the significance to any distinction that you
percieve to exist between ICAD and most other PC-based
CAD systems?
Rainer Joswig <······@lavielle.com> wrote in article
<·································@news.lavielle.com>...
> In article <··········@mtinsc04.worldnet.att.net>, "Tony Tanzillo"
> <·············@worldnet.att.net> wrote:
>
> > ICAD is about 1/10 the speed of most modern PC-based
> > CAD systems (based on a standard benchmark),
>
> Which shows again that people are comparing apples with oranges.
>
> --
> http://www.lavielle.com/~joswig/
>
From: Rainer Joswig
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <347E88C3.916DE4E5@lavielle.com>
Tony Tanzillo wrote:
> ICAD and most modern PC-based CAD products are designed
> to do exactly the same thing.
What is this same thing? I was under the impression
that there are many different application areas of CAD
systems, with vastly different demands (time to market,
complexity, frequency of changes or redesign,
standards, integration, cost of failure, ...).
Or is "PC-based" a new quality?
> What is the significance to any distinction that you
> percieve to exist between ICAD and most other PC-based
> CAD systems?
Automation of design changes, object-oriented modelling
integrated in to CL. You can integrate complex design
rules into the modelling language, ...
Tim Bradshaw <···@aiai.ed.ac.uk> writes:
> * Tony Tanzillo wrote:
>
> > 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.
>
> It's hard to imagine anything more badly wrong than this statement.
> Let's look at Window systems. Quite a lot of the crazy lunatics with
> vision were at Xerox PARC, and produced stuff years ahead of its time.
> Then some more customer-driven people with less vision at Apple did
> some fairly derivative stuff. Finally some people at Microsoft with
> practically no vision at all, but a great desire to become rich by
> giving people what they wanted, did Windows. Who became rich here?
> Who became a major success? Who is the richest person in the world?
>
> --tim
You're right, Tim. But look, how many people know that? And Tony very
probably is among the crowd, that is not aware of the real line of
historic development. They thinj Microsoft invented the GUI, and the mouse;
and Netscape invented browsers; and wasn't Excel the first spreadsheet? No?
Most people just don't know the history! Do they know the Star, the Alto?
Do they know lisp machines? They think VB is a great developpment environment,
but have never seen a Smalltalk environment. And so on, and so on.
It is sad, and especially so because it is often very influential people, that purport those views.
Andreas Eder
Andreas Eder wheezed these wise words:
> You're right, Tim. But look, how many people know that? And Tony very
> probably is among the crowd, that is not aware of the real line of
> historic development. They thinj Microsoft invented the GUI, and the mouse;
> and Netscape invented browsers; and wasn't Excel the first spreadsheet? No?
You don't have to think that MS - or Apple - created these ideas in
order to prefer a particular application of them. You don't need to be
ignorant of history to prefer a more recent idea.
> Most people just don't know the history! Do they know the Star, the Alto?
I read about the Alto in the early 80s. I still prefer the machines I
see today. So d oa great many other people who also know the history,
perhaps even more of it than I do.
There are even people who simply _do_not_care_. History is for geeks.
Some people use computers to do work, and nothing else. A means to an
end, rather than an end in itself. Us techies see things differently,
but that doesn't make a user wrong. We may like to see ourselves as
the people on the Mayflower, but users may be the people on the second
boat, and see us as the people they sent ahead to get things ready.
> Do they know lisp machines? They think VB is a great developpment environment,
WHat's wrong with this? It's a _tool_. If somebody can use that tool,
then it has succeeded.
> but have never seen a Smalltalk environment. And so on, and so on.
Why should they? I've liked Smalltalk since the early 80s, but that
doesn't mean that I want everyone to use it. Nor do I condemn anyone
who prefers a different tool.
> It is sad, and especially so because it is often very influential
> people, that purport those views.
Money infuences people. In fact, there's a saying: "Money talks."
I'm interested in tools, but I don't expect everyone else to feel the
same way. Esp when they've got better things to do.
Now, if you can put a figure on the cost of using a tool, or the
savings to be made by using another tool, that could influence people.
Time is money, so a saving of time might work. However, consider the
fact that VB also saves time. You need to show that Smalltalk or Lisp
will save _more_ time, and thus save/make more money.
I don't need convincing, but I know that there are others who do. It's
their business to know about such things, and they demand a strong
argument if anyone wants to convince them that they're doing it all
wrong. I hope is that eventually this will happen, but I'm also sure
that it won't be an argument based on techie issues.
It'll have to be money that does the talking. Show people how errors
in a program written in VB cost a company a lot of money, and how
those same errors could've been avoided by using, say, Lisp. If you
can also show how using Lisp instead of VB will cost less money even
in the short term, and you could have a winning argument.
Don't talk computing history, tho. Accountants will be bored by it.
Talk money and the accountants will love you. So will all the other
bean counters. In other words, see what they want and give it to them.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
Kent M Pitman <······@world.std.com> wrote in article
<···············@world.std.com>...
> ·····@skorpio3.usask.ca (P. Srinivas) writes:
>
> One possible test you could run to see if I'm just making this
> up--implement a commercial CL of your own and focus on flashy steppers
> at a higher priority than we have. If your approach takes the market
> by storm, ... well, I was going to offer to apologize for being
> confused in my priorities, but why should I be apologizing for having
> given you an idea that makes millions? ;-)
>
Look here:
http://ourworld.compuserve.com/homepages/tonyt/lisppad.htm
From: Bruno Haible
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <1424p16134@clisp.cons.org>
Tony Tanzillo <·············@worldnet.att.net> wrote:
>
> That's what you call a 'debugger'?
>
> There's an interesting IDE available for the AutoLISP
> programming language (editor/compiler/debugger), that
> displays source code in an editor window, and highlights
> each expression as it's entered/exited, allowing the
> programmer to step-into/over/out of closures or just
> "run to the cusor". It also has watch windows, call
> stack, breakpoints, and so on.
>
> That's what I call a debugger.
The IDE of ILOG Talk has all of the above.
Plus: It's based on XEmacs or GNU Emacs. Power at your fingertips.
Plus: You can macroexpand forms within the editor. Ever seen a C/C++
"IDE" that can show you the macroexpansion of a piece of source?
Plus: Errors refer to source location, not just line numbers. When
you start modifying your source, inserting or deleting lines, the
error references still point to the right place in the code. So-called
"professional" IDEs on Windows do not do this.
Plus: You can search for all occurrences of a symbol in the source
(intelligent grep). You can also rename all occurences of a local
variable with as single command.
Plus: You can modify your code and re-evaluate a function definition
(or an entire source file) while you are debugging, then restart at an
arbitrary stack frame.
And guess what? ILOG Talk is a Lisp!
Bruno Haible
You get the Linux/x86 version of ILOG Talk for free at
ftp://ftp.ilog.fr/pub/Products/Talk/linux/
----------------------------------------------------------------------------
Bruno Haible net: <······@ilog.fr>
ILOG S.A. tel: +33 1 4908 3585
9, rue de Verdun - BP 85 fax: +33 1 4908 3510
94253 Gentilly Cedex url: http://www.ilog.fr/
France url: http://www.ilog.com/
Bruno Haible wheezed these wise words:
> The IDE of ILOG Talk has all of the above.
Do ILOG still sell this product? Last time I looked, several months
ago, I couldn't find a page for it on the ILOG website. The search
facility produced two references, but that was it.
I'd very much like to know if ILOG Talk is still available, and if so,
how much does it cost? Is it any cheaper, now?
Thanks.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Marc Mertens
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <3479DCFC.AFBB5FB2@akam.be>
UAB wrote:
> I wonder if there is a debugger or any way to trace a program written in lisp.
I have posted a source level debugger on the sunsite site for the linux version
of GCL ,
it is however still beta (maybe even alfa) but you can take a look at it .(I'm
working on
a new release which will have support for CLOS and supports GCL and CMUC).
If you can get the motifd daemon for linux working you should be pleased to know
that CMUCL has already a sourcelevel debugger based on motif. It even works
without motif but is not that easy to use. If you use GCL in emacs or xemacs
then by loading sources with the dload statement allows you to to do also source
level debugging.
Hopes this helps.
Marc Mertens
········@akam.be
From: P. Srinivas
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <65cq4p$i0a$1@tribune.usask.ca>
Marc Mertens (········@akam.be) wrote:
: UAB wrote:
: > I wonder if there is a debugger or any way to trace a program written in
: >lisp.
: I have posted a source level debugger on the sunsite site for the linux
: version of GCL ,
: it is however still beta (maybe even alfa) but you can take a look at it .(I'm
: working on
: a new release which will have support for CLOS and supports GCL and CMUC).
: If you can get the motifd daemon for linux working you should be pleased to
: know : that CMUCL has already a sourcelevel debugger based on motif.
: It even works
: without motif but is not that easy to use. If you use GCL in emacs or xemacs
: then by loading sources with the dload statement allows you to to
: do also source
: level debugging.
I guess there is no such luck for lesser mortals like us who use
commerical CL such as ACL :-(
srini
--------------------
Srinivas Palthepu Email: ·····@cs.usask.ca
ARIES laboratory, Phones: (306) 966-8654 (lab)
Department of Computer Science, (306) 966-4759 (office)
University of Saskatchewan, (306) 373-6724 (home)
57 Campus Dr, Saskatoon, SK, S7N 5A9 Fax: (306) 966-4884
From: Erik Naggum
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <3089413117481270@naggum.no>
* P. Srinivas
| I guess there is no such luck for lesser mortals like us who use
| commerical CL such as ACL :-(
why don't you give Franz, Inc, a call? it's clear that you want to pay for
such a feature. right? you could at least send them a list of requests
for whatever you need to do it yourself. (I remember that you said this is
easy to do.)
Franz ships a product called "Composer" for Allegro CL. it's a graphical
environment with a grapher that makes profiles a lot easier to analyze, but
it also contains a windowed inspector and debugger. I haven't used it
enough to give you a fair summary of its abilities, I'm sorry to say. send
me some of your buggy code, and I'm might try it out. in any case, Allegro
Composer is somewhat old by now and perhaps "clunky" by modern standards,
but it's a lot more "user-friendly" than the command-line interface or even
the Emacs interface, for at least some values of "user". your friendly
Franz, Inc, salesperson may actually ignore your grumpy remarks and help
you if you can make a case for it.
Allegro for Windows has a lot more graphics to it than the Unix version.
unfortunately, it's also a wholly different product inside, so it's not at
all comparable. rumors have it that their next major release will be a
_lot_ more graphical. I'm not sure I look forward to that, but judging
from what I see here, the effect will at least be to get people to gripe
about some _other_ missing but crucial necessity. (I hear it's also going
to use dynamic loading, so whine while you can!) you can get a free
version of the Windows version, too. (I assume you have the free Linux
version, or you would have had a sales or support person to talk to instead
of posting your gripes.)
(no, I'm not affiliated with Franz, Inc, and do not speak for them in any
way, but my cat receives toys from them and I get very good support with
everything I ask about. I hate unfair remarks about people, but even more
so when they are about people I know to be good.)
#\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.
From: Hrvoje Niksic
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <kigoh2y58qr.fsf@jagor.srce.hr>
·······@bittersweet.inetarena.com (Karl M. Hegbloom) writes:
> I think that an XEmacs `gud'/`edebug' sort of source debugger would
> be the best way to work it.
`gud' and `edebug' are two entirely different things. But, speaking
of edebug, I remember having read that edebug has been made to debug
foreign (non-Elisp) Lisps. Is this true? Does anyone know more about
it?
It would certainly be amazing to be able to debug Common Lisp using
edebug/ilisp from within XEmacs!
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm sure they'll listen to reason! -- Neal Stephenson, _Snow Crash_
From: Daniel LaLiberte
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <3486D412.6F081AEF@gte.com>
Hrvoje Niksic wrote:
> `gud' and `edebug' are two entirely different things. But, speaking
> of edebug, I remember having read that edebug has been made to debug
> foreign (non-Elisp) Lisps. Is this true? Does anyone know more about
> it?
Edebug has a language for describing the evaluation patterns of macros
and specifications in this language are used to direct the
instrumentation process. I was able to define specs for all the common
lisp macros included in the cl.el package as a test - the spec for the
loop is exhautively detailed. Edebug also works with read macros, so it
is conceivable one could define a radically different language that can
still be debugged via Edebug. This instrumentation approach to
source-level debugging has its advantages and disadvantages.
> It would certainly be amazing to be able to debug Common Lisp using
> edebug/ilisp from within XEmacs!
Using edebug with ilisp would be very interesting. I never had a need
to use ilisp, however, so I didn't have the personal motivation to build
that interface. I almost got to the point of implementing Edebug in
MCL, but ... that is another story.
The edebug/ilisp interface could probably use pretty much the same
instrumentation mechanism, but it would require a radically different
run-time debugger mechanism, the second half of the Edebug package.
The debugger part is a major hack anyway, and could use a generalization
that allowed it to be usable with external processes. A large part of
what Edebug does is to appear invisible to the environment in which it
runs.
I haven't even kept Edebug up-to-date with regard to Emacs 19
developments. I do mostly web technologies these days. Someday it might
be nice to return - by that time, perhaps Java will have adopted full
Lisp-like semantics.
--
Daniel LaLiberte
GTE Labs, Waltham MA
··········@gte.com