Is there a debugger or similar for Common Lisp?
UAB
I wonder if there is a debugger or any way to trace a program written in lisp.
Kent M Pitman
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
Martin Rodgers
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
Kent M Pitman
"Tony Tanzillo" <tony.t...@worldnet.att.net> writes:
> Kent M Pitman <pit...@world.std.com> wrote in article
> <sfwg1op...@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.
P. Srinivas
Kent M Pitman (pit...@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: sr...@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
Kent M Pitman
Oops. I said I wasn't going to reply further in this thread.
Well, ignore my previous remarks if you like. Sorry about that.
Kent M Pitman
sr...@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? ;-)
Tony Tanzillo
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 <pit...@world.std.com> wrote in article
Tony Tanzillo
Kent M Pitman <pit...@world.std.com> wrote in article
<sfw90uf...@world.std.com>...
> sr...@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:
Erik Naggum
* 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.
Martin Rodgers
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
Marc Mertens
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
mmer...@akam.be
Marc Wachowitz
"Tony Tanzillo" <tony.t...@worldnet.att.net> wrote:
> 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.
What would you think if someone demanded that the technical operation
of chemical factories should be optimized towards being "user-friendly"
for some arbitrary guy who happened to walk in from the street? Wouldn't
you consider such a state of mind insane? At least I'd do so, and I don't
see the suggestion that powerful programming languages and programming
tools should be optimized towards users without a decent education about
program design and implementation at all differently.
Now I don't have anything against people who want to play around with
programmable software, but I consider their interests, and the kind of
programming which they are likely to find appealing, comparable to a
chemical toolbox with which some children (and perhaps also some adults)
like to play with - it's just entertainment, and shouldn't be confused
with the needs of serious work (not implying the latter couldn't - or
shouldn't - also be enjoyable, but it demands much more background).
> A novice can actually watch a program execute, by seeing
> visually observing program logic flow.
As instructive as program visualization may be, unless people learn to
use sophisticated abstraction techniques (which implies differentiation
between a specification and some implementation - something they won't
learn by low-level debugging), they shouln't pretend to be qualified as
professional programmers. Working through some books about logic, problem
analysis, and program semantics will be a much better investment than an
arbitrarily friendly debugger. A basic understanding of programming logic
(rather than the execution of some particular program) may be helped by
going through some carefully selected examples, but that much can as
well be done "on paper" (nothing against software support for teaching,
but use specialized systems for that task, not the tools meant to be used
day in day out by experts). Beyond such simple steps, I'd want much more
expressive tools than single-stepping, which usually means that one
either has to derive the information from reading the program, or from
problem-specific utilities, which can be naturally built along with the
"main" source code. For a few remaining low-level debugging tasks, it
doesn't appear to make sense to waste lots of effort in graphical user
interfaces which are supposed to be "intuitive" to a novice, instead
of providing necessary hooks into the system for competent programmers.
Besides, all this "intuitive GUI" stuff does only get into the way if
one wants to perform a task automatically, solving it once and for all,
freeing one's thought and time for more insteresting problems.
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
P. Srinivas
Erik Naggum (cle...@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.
P. Srinivas
Marc Mertens (mmer...@akam.be) wrote:
: UAB wrote:
I guess there is no such luck for lesser mortals like us who use
commerical CL such as ACL :-(
Rainer Joswig
In article <65cole$h4l$1...@tribune.usask.ca>, sr...@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.
Tony Tanzillo
Erik Naggum <cle...@naggum.no> wrote in article
<30893610...@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,
Erik Naggum
* 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.)
Richard A. O'Keefe
"Tony Tanzillo" <tony.t...@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
Tony Tanzillo
Richard A. O'Keefe <o...@goanna.cs.rmit.edu.au> wrote in article
<65dktd$dfr$1...@goanna.cs.rmit.edu.au>...
> "Tony Tanzillo" <tony.t...@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.
>
> 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?
Marc Wachowitz
"Tony Tanzillo" <tony.t...@worldnet.att.net> wrote:
> Popularity is my yardstick. One you can't argue with.
What you seem to be missing is that your measure of "good" or "successful"
isn't necessarily very interesting for everyone else. As difficult as you
may find it to believe, some people do have a notion of quality which isn't
dictated by the lowest common denominator of incompetence, but based on
understanding what they are doing. Not everyone wants to become a winner
in a race for maximizing foolishness, which is what much of society seems
to be about. One can also aim to optimize what one perceives to be right
within the constraints of being able to survive sufficiently well. It may
not necessarily make one a millionaire to be invited at every business party,
but it may still enable one to lead a life which one considers worth living
despite the necessary compromises, instead of becoming a mindless supporting
example for the thesis that intelligent life can't be found on this planet.
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Tony Tanzillo
Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de> wrote in article
<65drkj$n0t$1...@trumpet.uni-mannheim.de>...
> "Tony Tanzillo" <tony.t...@worldnet.att.net> wrote:
> > Popularity is my yardstick. One you can't argue with.
>
> What you seem to be missing is that your measure of "good" or
"successful"
> isn't necessarily very interesting for everyone else.
This is an old argument for a musician. Should one write commercial
"pop" tunes that sell millions of records, or should they write the
kind of music they like, and eat bread and water?
Unfortunately, you're the one that's missing something. As superior
as you may view yourself, you are part of a dying culture that will
not even warrant a footnote in the pages of history.
> may find it to believe, some people do have a notion of quality which
isn't
> dictated by the lowest common denominator of incompetence, but based on
> understanding what they are doing.
Fortunately for us mortals, it isn't always necessary to
understand everything one does. That is only a requirement of
a pig-headed elitist that is so hopelessly immersed in their
own implementations, that they are incapable of distinguishing
the means from the end.
I know others who see things your way. Their basic problem is that
they never get anything done, because no matter how good it is,
it is not good enough. Hence, they are stuck in a never-ending
cycle of improving on what they did yesterday, as a result of
what they learned today.
> Not everyone wants to become a winner in a race for maximizing
> foolishness, which is what much of society seems to be about.
Would euthanasia be a solution for you? I mean, if you are so
enamored with looking down your nose at the rest of society,
and how 'foolish' it is; how superior you are to it, then
then why not go out and get yourself a 45, and just blow your
brains out? I would certainly consider it, if I were forced
to walk amidst so many 'foolish' mortals.
> One can also aim to optimize what one perceives to be right
> within the constraints of being able to survive sufficiently well.
You obviously have very little real-world business experience.
My advice to you is to stay within the confines of your academic
sanctuary, where one doesn't have to pay for their mistakes, and
hence, tends to learn very little from them.
In spite of how superior you obviously consider yourself,
you have much to learn.
Tim Bradshaw
* 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
Martin Rodgers
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
Rainer Joswig
In article <65dbjs$f...@mtinsc02.worldnet.att.net>, "Tony Tanzillo"
<tony.t...@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?
Frank A. Adrian
Richard A. O'Keefe wrote in message <65dktd$dfr$1...@goanna.cs.rmit.edu.au>...
>"Tony Tanzillo" <tony.t...@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
frank_...@firstdatabank.com (W)
fra...@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.
Tony Tanzillo
> > 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,
Marc Wachowitz
"Tony Tanzillo" <tony.t...@worldnet.att.net> wrote:
> Unfortunately, you're the one that's missing something. As superior
> as you may view yourself, you are part of a dying culture that will
> not even warrant a footnote in the pages of history.
If relatively simple pc software is the whole software market you see,
it might even be true (as frightening as it sounds for the poor users),
but there are - and will remain - quite a few application areas where
the cost (whether monetary or human health/life) of a serious software
failure is just too high to let "become a wizard in a week"-programmers
work on the non-trivial parts of the system. No visiual debuggers or
similar gadgets will change that.
> > One can also aim to optimize what one perceives to be right
> > within the constraints of being able to survive sufficiently well.
>
> You obviously have very little real-world business experience.
>
> My advice to you is to stay within the confines of your academic
> sanctuary,
Hmm, I've been working for several years now on a commercial integrated
work-flow and documentation system for power plants (other industry kinds
may join in near future), which is continuously developed and successfully
used since more than a decade by several large and small customers, works
on different mainframe and workstation operating systems, and is currently
being redesigned/reimplemented towards a more thorough distributed/client-
server architecture to enable various forms of distribution (depending on
e.g. the size of an installation and allowed delays for recovery in case of
component failure). Judging from the amount of money this costs a customer
(where of course, the software price is a only one aspect of this cost),
and given that it saves more already due to the shortened down-time during
a single revision of a nuclear power plant (which has to be done annually),
I'd say this is very much happening in the real world of business.
(Btw, I tend to have quite good contacts with people performing diverse
functions - like consulting, development, user support - in this company,
so I get to know what's happening beyond my own field of work, too.)
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Martin Rodgers
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.
Tony Tanzillo
No, but I would be happy to take a closer look at it
if you can point me to some info.
Thanks.
Rainer Joswig <jos...@lavielle.com> wrote in article
<joswig-ya0231800...@news.lavielle.com>...
> In article <65dbjs$f...@mtinsc02.worldnet.att.net>, "Tony Tanzillo"
> <tony.t...@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.
>
Marco Antoniotti
"Tony Tanzillo" <tony.t...@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
Andreas Eder
Tim Bradshaw <t...@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
Georg Bauer
Richard A. O'Keefe <o...@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
Will Hartung
"Tony Tanzillo" <tony.t...@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. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Tony Tanzillo
>
> What would you think if someone demanded that the technical operation
> of chemical factories should be optimized towards being "user-friendly"
> for some arbitrary guy who happened to walk in from the street? Wouldn't
> you consider such a state of mind insane?
You mean, you're not going to use the old nuclear power plant, or
'controlling the glide path of a space shuttle or aircraft' scenario?
Not all programming (actually only a small percentage of same)
qualifies as mission-critical. The problem you have, is that
you're out-of-touch with what the masses are doing with computers
these days.
Get out of the computer science department, and have a look at
the world around you. Programming is not just for 'professional
programmers' any more,
I understand that you might have a hard time accepting that,
but that is the reality.
> Now I don't have anything against people who want to play around with
> programmable software, but I consider their interests, and the kind of
> programming which they are likely to find appealing, comparable to a
> chemical toolbox with which some children (and perhaps also some adults)
> like to play with - it's just entertainment, and shouldn't be confused
> with the needs of serious work (not implying the latter couldn't - or
> shouldn't - also be enjoyable, but it demands much more background).
So, you're belittling the type of programming that these 'unqualified'
individual do, as a means of self-aggrandizement? So, the millions of
AutoCAD users, and millions of VB users are just 'playing around' (with
a very dangerous weapon)?
> As instructive as program visualization may be, unless people learn to
> use sophisticated abstraction techniques (which implies differentiation
> between a specification and some implementation - something they won't
> learn by low-level debugging), they shouln't pretend to be qualified as
> professional programmers. Working through some books about logic, problem
> analysis, and program semantics will be a much better investment than an
> arbitrarily friendly debugger.
You are obviously in very bad shape. I'm not sure where you spend your
time, but I have gone as far as I will to explain that the people I'm
referring to are not, and do not want to become professional programmers.
They don't give a damn about theory of software design or program
semantics. They don't care if their code is "elegant" or not, or
even if it is grossly-inefficient. The only thing that matters to
these people, is that it works, and it doesn't take them forever
to write.
You seem to view programming as if were an art, that should only be
practiced by some elite group of individuals. It's also clear from
your comments that to you, programming is the end, rather than just
a means to it.
I feel very sorry for you. Your point of view is hopelessly jaded to
the point where you seem to have convinced yourself that a bug in a
software program is going to ultimately lead to the destruction of
all life on the planet. What a pathetic shame.
Now, if you'll excuse me, I'm going to go blow up New Jersey
with a few lines of badly-written HTML.
Tim Bradshaw
* Tony Tanzillo wrote:
> Not all programming (actually only a small percentage of same)
> qualifies as mission-critical. The problem you have, is that
> you're out-of-touch with what the masses are doing with computers
> these days.
But a great deal of programming qualifies as `this costs money if it
breaks', and a reasonable chunk of programs which cost money if they
break are large enough that you have to be reasonably serious about
getting them right -- just hacking isn't any good unless you're a
genius.
> They don't give a damn about theory of software design or program
> semantics. They don't care if their code is "elegant" or not, or
> even if it is grossly-inefficient. The only thing that matters to
> these people, is that it works, and it doesn't take them forever
> to write.
I'd like not to give a damn about any of these things either. But I'm
forced into it by my own limitations as a programmer. I want to be
able to be write reasonable-sized systems, and be involved in quite
large systems. And I'm just not bright enough to do that without
being concerned with all this boring stuff like abstraction and
efficiency and design and engineering.
And Common Lisp is a good match for those concerns (not as good as it
should be of course).
--tim
Faried Nawaz
Eulogy -- high praise. Perhaps you meant "elegy"?
faried.
--
WAR IS PEACE FREEDOM IS SLAVERY BACKSPACE IS DELETE
Faried Nawaz
"Tony Tanzillo" <tony.t...@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.
Tim Bradshaw
* 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
Martin Rodgers
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.
Martin Rodgers
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. ;)
Rainer Joswig
In article <MPG.ee6490b7...@news.demon.co.uk>,
mcr@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, ...).
Rainer Joswig
In article <MPG.ee6471a6...@news.demon.co.uk>,
mcr@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 <rob.l...@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)
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
David Thornley
In article <65dt1k$i...@mtinsc04.worldnet.att.net>,
Tony Tanzillo <tony.t...@worldnet.att.net> wrote:
>Richard A. O'Keefe <o...@goanna.cs.rmit.edu.au> wrote in article
>> >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.
>>
>> 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).
>
>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.
>
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
da...@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly.
Martin Rodgers
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_.
Martin Rodgers
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.
Bruno Haible
Tony Tanzillo <tony.t...@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: <hai...@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/
Rainer Joswig
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?
Craig Brozefsky
"Tony Tanzillo" <tony.t...@worldnet.att.net> writes:
> You seem to view programming as if were an art, that should only be
> practiced by some elite group of individuals. It's also clear from
> your comments that to you, programming is the end, rather than just
> a means to it.
Writing is a means for a sales person to get their message out to a
prospective client. Writing is also an art form with a well developed
aesthetic sense. For one it is an means, for another it is an ends in
itself.
Why is it that his viewing of programming as an art seems to
automatically make you assume that he thinks it should only be
practices by an elite few? There is not a logical connection between
the two. A highly developed aesthetic does not automatically lead to
elitism and seperatist notions. Why do you think the two are linked?
--
Craig Brozefsky cr...@onshore.com
onShore Inc. http://www.onshore.com/~craig
Development Team p_priority=PFUN+(p_work/4)+(2*p_cash)
I hear my inside, the mechanized hum of another world - Steely Dan
Tony Tanzillo
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
<mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk> wrote
in article <MPG.ee68299c...@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_.
Martin Rodgers
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.
Martin Rodgers
Tony Tanzillo wheezed these wise words:
> I wouldn't call ICAD popular. Not even close.
I was refering to AutoCAD, of course. ;-)
Martin Rodgers
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.
Rainer Joswig
In article <65j1fi$q...@mtinsc04.worldnet.att.net>, "Tony Tanzillo"
<tony.t...@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.
Rainer Joswig
In article <MPG.ee744a06...@news.demon.co.uk>,
mcr@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. ;-)
Martin Rodgers
Rainer Joswig wheezed these wise words:
> How do you define "popular"? Popularity is relative.
I stated my definition. "Vox populi".
Erik Naggum
* 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.
Martin Rodgers
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...
Martin Rodgers
Will Hartung wheezed these wise words:
> You can keep your road, I'll take a Unimog.
Why can't Lispers have both?
Georg Bauer
Don't know why you ignore it, but Allegro CL/PC includes a full
GUI-Designer in "the windows way". Of course.
Tony Tanzillo
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 */
/* --------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* to...@compuserve.com */
/* --------------------------------------------------- */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*******************************************************/
Rainer Joswig <jos...@lavielle.com> wrote in article
<joswig-ya0231800...@news.lavielle.com>...
Tony Tanzillo
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
<mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk> wrote
in article <MPG.ee744a06...@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.
Tony Tanzillo
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 <jos...@lavielle.com> wrote in article
Rainer Joswig
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
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, ...
Martin Rodgers
Tony Tanzillo wheezed these wise words:
> Not all programming (actually only a small percentage of same)
> qualifies as mission-critical. The problem you have, is that
> you're out-of-touch with what the masses are doing with computers
> these days.
I call this the "One size fits all" argument (OSFA for short). One
size of solution applies or none at all. Fortunately, we can choose
tools that fit the size of the problem. Ideally, this should include
Lisp-based tools, but in practice, not every problem demands a $3000
tool. There are, however, less expensive Lisp tools. One of them costs
as little as $300 (currently available for only one platform, alas),
and others for only a little more.
OSFA can work against the freely available tools, as they don't
_necessarily_ include the same quality of support as the commercial
tools. For markets where support is seen as a critical issue, any
tools without guanteed support will likely be ignored.
Whether or not Lisp suffers because of this is debatable. Lisp
survives. Lisp's image may suffer, amoung non-Lispers, but this isn't
bad enough to kill the commercial Lisps, nor commercial use of Lisp.
So it's easy for some of us to believe that OSFA is reasonable.
Perhaps it's only those of us with problems that don't fit so well
that are unhappy? I think that this is why Lisps like AutoLisp exist.
When a tool doesn't fit, somebody - in this case AutoDesk - makes it
fit. Lisp is flexible enough to allow this. The result might not be
Common Lisp, but that's not always the ideal goal. CL is only one way
of Lisp, and there have been - and I hope will be - more.
This is Lisp's great strength; there need be no limits but those
limits that we ourselves create.here need be no limits but those that
we ourselves create. A Lisp like AutoLisp doesn't threaten CL. It only
threatens the idea that CL is the final word. Insisting that all Lisps
should be CL may be one of those limits. Insisting that all Lispers do
things in the same way may be another.
Could this be why some Lispers prefer a GUI debugger, and others
prefer a different style of debugging tool? I think so.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
Martin Rodgers
Tim Bradshaw wheezed these wise words:
> And Common Lisp is a good match for those concerns (not as good as it
> should be of course).
Nothing ever is. ;) We're always striving for something better, and if
we think we've found it, another generation of programmers may find
something we've not thought of. This pushes us forward.
BTW, is this ng for Common Lisp only, or can we also talk about other
Lisps? Could a non-CL Lisp like AutoLisp also push us forward?
Tony Tanzillo
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 <jos...@lavielle.com> wrote in article
Rainer Joswig <jos...@lavielle.com> wrote in article
Espen Vestre
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> tools that fit the size of the problem. Ideally, this should include
> Lisp-based tools, but in practice, not every problem demands a $3000
companies are willingly spending zillions of dollars upgrading their
office applications to the newest incompatible standard from Redmond,
forcing them to throw away the pc's they bought less than two years
ago, and forcing them to waste man-year after man-year configuring
these machines. And don't tell me they get any more productivity
out of it!
Compared to that waste of money, the price of an lisp environment
- even the $3000 ones - is nothing.
--
Espen Vestre
Martin Rodgers
Rainer Joswig wheezed these wise words:
> These words are marketing slogans - nothing more.
Meaning "difficult to clone". That means a great deal. It's easy to
understand why a vendor should wish to make a product hard to clone.
When a product is based - or supposedly based - on an open standard,
then this action is still understandable, but less forgivable.
Not that this always stops it from happening. A number of languages
have suffered, and are suffering, from this plague. Common Lisp is
relatively free from it, but even CL systems have features not defined
by ANSI CL. Could some of those features may be hard to clone?
This need not necessarily be a problem. We might even expect a vendor
to add something to CL, to make their product distinct from the
competition. Consider the extensions to LOOP. Even now, after ANSI CL
has standardised LOOP extensions, we still see further extensions from
vendors. LWW's SQL extensions, for example.
We only need to worry about extensions when they affect features that
we can't avoid using. While using those extended features is still our
choice, this is our responsibity. If we can clone those features, then
we have the freedom to move to another product. In this case, that
would be another Common Lisp.
Whether you consider AutoLisp to be "modern" or not is unimportant. It
has a history, it has a large user base, and that gives it inertia.
That user base may easily have different demands from a CL programmer,
since you can use a CL not embedded inside AutoCAD. As AutoLisp is
tied to AutoCAD, the demands made on it are determined by the user
base for the app. Not everything that applies to CL will necessarily
also apply to AutoLisp.
Perhaps in an ideal world, AutoCAD would use a full CL, but this is
not an ideal world. Anyway, not everyone can agree on what an "ideal
world" should look like! ;) Thus, we compromise.
I bet there are even a few compromises in the design of CL, probably
because not everyone could agree on the design of everything in the
language. This is human nature. We see things differently. If it were
not so, then CL could've been designed by a single person (Kent?).
Except that it helps to divide a task that large. ;)
--
Please note: my email address is munged; You can never browse enough
Tony Tanzillo
Interestingly (and perhaps ironically), AutoLISP is by-far the most
widely-used dialect of LISP on the planet. It's probably also the
most-limited dialect (based largely on David Betz's Xlisp 1.5).
Martin Rodgers
<mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk> wrote
in article <MPG.ee894268...@news.demon.co.uk>...
> Tim Bradshaw wheezed these wise words:
>
> > And Common Lisp is a good match for those concerns (not as good as it
> > should be of course).
>
> Nothing ever is. ;) We're always striving for something better, and if
> we think we've found it, another generation of programmers may find
> something we've not thought of. This pushes us forward.
>
> BTW, is this ng for Common Lisp only, or can we also talk about other
> Lisps? Could a non-CL Lisp like AutoLisp also push us forward?
> --
> Please note: my email address is munged; You can never browse enough
Rainer Joswig
In article <65m0t5$g...@mtinsc02.worldnet.att.net>, "Tony Tanzillo"
<tony.t...@worldnet.att.net> wrote:
> 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.
Maybe you would even get a native compiler.
Then you may get code that cannot be loaded
into other systems. Really evil.
Maybe some people would also like to protect
their investment from being stolen and/or copied.
Having your own code floating around in
source doesn't help that much.
> They purchased that company in order to eliminate the
> AutoCAD-compatible product before it reached market.
There is FelixCAD in Germany. How are they doing?
> Could you also say this in a more positive way?
This is business. Somebody has created a product
and wants to protect it (and there are different
strategies for that - see for example SUN).
Others want a cheap entry into a market
cloning just what is there.
Martin Rodgers
Espen Vestre wheezed these wise words:
> companies are willingly spending zillions of dollars upgrading their
> office applications to the newest incompatible standard from Redmond,
> forcing them to throw away the pc's they bought less than two years
> ago, and forcing them to waste man-year after man-year configuring
> these machines. And don't tell me they get any more productivity
> out of it!
They don't necessarily spend $3000 on a single office app. That's the
difference. Your argument has a big hole in it. In fact, there are
office apps _bundled_ with Win95 machines. I'd recommend pursuing that
line elsewhere, as you have more of an "MS advocacy" argument.
> Compared to that waste of money, the price of an lisp environment
> - even the $3000 ones - is nothing.
Development tools are not office tools. While we can see how a single
Lisp environment may be better value than a single C++ environment,
we've already recently had an excellent explanation for why this
doesn't convince many people. If your only choice is between a tool
that costs less than $1000 and another tool that costs several times
that, and nobody can show you the figures that judtify that extra
cost, what are you going to do?
Remember: bean counters see things differently. Money talks. So talk
money. If you instead talk techie, don't be suprised if they buy
something else. Sorry, but $3000 is a lot of beans. So is $99. Perhaps
it's just easy to justify $99? I only know of one magazine for Windows
developers that doesn't have any ads by MS, and that's because they
lost the MS adverting contract by being honest. Yep, money talks.
I'm not saying that Lisp sucks. I'm simply pointing out that you have
to do more than say "$3000 is nothing" to a bean counter.
--
Please note: my email address is munged; You can never browse enough
Tony Tanzillo
Tim Bradshaw <t...@aiai.ed.ac.uk> wrote in article
<ey3hg90...@eigg.aiai.ed.ac.uk>...
> * Tony Tanzillo wrote:
>
> > Not all programming (actually only a small percentage of same)
> > qualifies as mission-critical. The problem you have, is that
> > you're out-of-touch with what the masses are doing with computers
> > these days.
>
> breaks', and a reasonable chunk of programs which cost money if they
> break are large enough that you have to be reasonably serious about
> getting them right -- just hacking isn't any good unless you're a
> genius.
Agreed, but I think that we're not agreeing on what 'programming'
is. As one other person put it, writing spreadsheet macros is a crude
form of programming, that is typically not done by programmers. Ditto
for automating repetitive operations in CAD and other programs.
There is nothing mission-critical about writing a macro that draws a
front, top, and side view of a refrigerator. But that _is_ programming.
> > They don't give a damn about theory of software design or program
> > semantics. They don't care if their code is "elegant" or not, or
> > even if it is grossly-inefficient. The only thing that matters to
> > these people, is that it works, and it doesn't take them forever
> > to write.
>
> I'd like not to give a damn about any of these things either. But I'm
> forced into it by my own limitations as a programmer. I want to be
> able to be write reasonable-sized systems, and be involved in quite
> large systems. And I'm just not bright enough to do that without
> being concerned with all this boring stuff like abstraction and
> efficiency and design and engineering.
Again, no argument. It's just that programming is used for many
things, and at many different scales. Most of those using AutoLISP
are not involved in any kind of large-scale systems.
Tony Tanzillo
Zillions?
Is that more than trillions?
End-users require working applications. They don't want to
roll their own. Do you actually think that rolling their
own solutions in LISP is going to be less-costly than using
shrink wrapped windows applications from any vendor?
There are plenty of Windows application vendors aside from
Microsoft. Of course, you are a Windows-hater, and think
that it's the scourge of the planet, then you probably think
all Windows applications are worthless heaps of garbage.
I can't help that, but I can tell you that there's no LISP-based
replacement for the types of applications that are in use today.
Suggesting that one can displace shrink-wrapped business
applications with a LISP system (and do what with it?),
is absolute insanity.
Espen Vestre <e...@nextel.no> wrote in article
<w6wwhtq...@gromit.nextel.no>...
> mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk
(Martin Rodgers) writes:
>
> > tools that fit the size of the problem. Ideally, this should include
> > Lisp-based tools, but in practice, not every problem demands a $3000
>
> companies are willingly spending zillions of dollars upgrading their
> office applications to the newest incompatible standard from Redmond,
> forcing them to throw away the pc's they bought less than two years
> ago, and forcing them to waste man-year after man-year configuring
> these machines. And don't tell me they get any more productivity
> out of it!
>
> Compared to that waste of money, the price of an lisp environment
> - even the $3000 ones - is nothing.
>
> --
>
> Espen Vestre
>
Rainer Joswig
In article <65m2fb$g...@mtinsc02.worldnet.att.net>, "Tony Tanzillo"
<tony.t...@worldnet.att.net> wrote:
> Interestingly (and perhaps ironically), AutoLISP is by-far the most
> widely-used dialect of LISP on the planet.
Compared to Emacs Lisp? We have not a single version of Autolisp
here, but a dozen of Emacs and XEmacs.
Or Scheme? Widely used in education (my old SICP copy had in
1988 its eight printing) and as extension language.
What is "by far"?
Tony Tanzillo
There are millions of people writing AutoLISP code.
I don't count educational use, since it's not elective
in many cases, but required.
Rainer Joswig <jos...@lavielle.com> wrote in article
<joswig-ya0231800...@news.lavielle.com>...
Rainer Joswig
In article <65m36t$g...@mtinsc02.worldnet.att.net>, "Tony Tanzillo"
<tony.t...@worldnet.att.net> wrote:
> own solutions in LISP is going to be less-costly than using
> shrink wrapped windows applications from any vendor?
Some shrink wrapped (even windows) applications happen
to be developed in Lisp.
> I can't help that, but I can tell you that there's no LISP-based
> replacement for the types of applications that are in use today.
So you don't think that there are Lisp-based "ordinary" applications
out there?
You mean, you could not use Interleaf to create documents?
Maybe you should tell your ideas to those companies who are
creating applications like N-World for Unix/NT or music notation
software for Macs. Or tell the GNU guys who are using
Scheme in graphics software (GIMP), spreadsheets
Face it. There is nothing in Lisp (whatever flavor) to prevent
you from writing/using "real" Lisp-based applications.
Only your imagination.
Tony Tanzillo
> Then you may get code that cannot be loaded
> into other systems. Really evil.
No native code compiler. Byte codes + huge runtime system.
> Maybe some people would also like to protect
> their investment from being stolen and/or copied.
> Having your own code floating around in
> source doesn't help that much.
Byte-code compiled .FAS files can be decompiled.
The protection offered by the addition of a byte-code
compiler is no more secure than what is available now
for protecting LISP code (encryption, and scrambling
code into gibberish).
Just as hackers around the world are able to reverse-
engineer AutoCAD's proprietary .DWG file format each
time it is changed, they will also reverse-engineer
the encrypted LISP code, and eventually, other CAD
programs will be able to read it.
> > They purchased that company in order to eliminate the
> > AutoCAD-compatible product before it reached market.
>
> There is FelixCAD in Germany. How are they doing?
They're not doing well, because they lack marketing
channels here in the US (it's also sold here).
> This is business. Somebody has created a product
> and wants to protect it (and there are different
> strategies for that - see for example SUN).
> Others want a cheap entry into a market
> cloning just what is there.
Autodesk has a near-virtual monopoly on CAD, and
that is not in the interest of the consumer. While
you can say that 'it's business', most consider it
to be bad business, since Autodesk would not have
to compete if there are no competitors, and it is
competition that drives product development and
enhancement.
Interestingly, AutoLISP was actually being phased-
out up until the point when they realized that it
was being cloned. At that point, they did an about-
face, and decided to make it more attractive.
We have competition to thank for this.
> --
> http://www.lavielle.com/~joswig/
>
Rainer Joswig
In article <65m5g4$l...@mtinsc05.worldnet.att.net>, "Tony Tanzillo"
<tony.t...@worldnet.att.net> wrote:
> There are millions of people writing AutoLISP code.
1 million? 10 million? 100 million?
Is writing AutoLisp code required for using AutoCAD?
Tony Tanzillo
The comparison was between a 'LISP system' (e.g., a development
environment) and shrink-wrapped applications, regardless of what
language they're written in.
--
Rainer Joswig <jos...@lavielle.com> wrote in article
<joswig-ya0231800...@news.lavielle.com>...
> In article <65m36t$g...@mtinsc02.worldnet.att.net>, "Tony Tanzillo"
Tony Tanzillo
It's estimated to be 2-3 Million worldwide.
Rainer Joswig <jos...@lavielle.com> wrote in article
<joswig-ya0231800...@news.lavielle.com>...
> In article <65m5g4$l...@mtinsc05.worldnet.att.net>, "Tony Tanzillo"
Tony Tanzillo
Martin Rodgers
Rainer Joswig wheezed these wise words:
> Why being so negative? How about this recent job offer from Autodesk...
I'm not being negative. Note all the other things in that job offer.
You might only see the reference to CL, but I see the whole picture.
Let me know when AutoLisp reaches full compliance with CL. I'd love to
see this happen, so I can then point to AutoCAD whenever anyone doubts
that real work can be done in Common Lisp. However, please note the
references to ActiveX, esp ActiveX Automation. Even AutoLisp might not
be the only way of creating AutpCAD apps!
Thanks.
Martin Rodgers
Tony Tanzillo wheezed these wise words:
> Interestingly, AutoLISP was actually being phased-
> out up until the point when they realized that it
> was being cloned. At that point, they did an about-
> face, and decided to make it more attractive.
Excellent, but why did it take AutoLisp clones to convince them? Don't
they listen to their users? Presumably the people creating the clones
listened, otherwise they could all be getting it wrong - or getting it
right more by accident, good sense, or whatever.
> We have competition to thank for this.
It certainly helps.
Martin Rodgers
Rainer Joswig wheezed these wise words:
> Face it. There is nothing in Lisp (whatever flavor) to prevent
> you from writing/using "real" Lisp-based applications.
If you mean using Common Lisp, then there could be a few things.
These things may be limitations imposed by people, which would make
them merely percieved limitations, but that can be enough.
> Only your imagination.
And a "One size fits all" attitude. Some problems fall below a size
threshold at which a Lisp system may be practical. Of course, in
theory you could write Windows shell extensions in ACL/PC, but the
fact that you don't need to is significant, as is the fact that this
particular problem domain doesn't even demand the power of Lisp.
There are ways to overcome this limitation, like writing a Lisp
compiler that compiles Lisp (or Lisp-like) code into C code for a
shell extension, or any similar kind of DLL. It's also possible to
write a "proxy" DLL that runs the Lisp app and then talks to it,
so the real work is done in Lisp.
While the above example may seem to be yet another "Hello, World"
class of app, there are actually people who write such code, and even
users who wish to use the result. This doesn't mean that Lisp is no
good. It just means that there's a threshold below which a CL system,
like ACL/PC, may be overkill.
This is why "One size fits all" doesn't work. When you insist that it
does, the message you're giving people is that they can't use Lisp.
This too is a limitation.
Some programmers use a tool because it allows them to write code fast,
and get it working quickly and painlessly. There's a big market for
tools like that. Alas, this leads some people to think that this is
the only market for them. They dismiss all other tools. If they merely
said, "This tool isn't for me", there'd be no problem.
Instead, there are some misguided individuals who like to tell us that
we can only use _what they use. Ever since I began using computers,
these people have been telling me what to use, and curiously, it's
_always_ what _they use_. It might be hardware (even the CPU!), or
software, and I always wonder why they care so much. You name it, and
someone will think they know your business better than you do, and can
tell you what you're doing wrong, even before they know any details. A
comic, Harry Enfield, based an entire character on such a person.
I'm not sure that this behaviour is unique to programmers using any
single language, but it does seem to be most common amoung those who
use C++. We, who use Lisp, should know better than to do the same.
So, while I don't currently feel a need for a GUI debugger for Lisp,
I'm not troubled by the fact that AutoLisp users may feel otherwise.
Espen Vestre
"Tony Tanzillo" <tony.t...@worldnet.att.net> writes:
> End-users require working applications. They don't want to
> roll their own. Do you actually think that rolling their
> own solutions in LISP is going to be less-costly than using
> shrink wrapped windows applications from any vendor?
You misunderstood my point.
My point is roughtly that the development department's investment
in a lisp development platform is _not_ expensive when you compare
it to the amount of money that the rest of your average company
spends on its office-application-running PCs.
I don't want to turn this into an MS-bashing thread, I just make
the point that _huge_ amounts of money is spent on "standardizing"
on the ever changing standards of MS in _any_ company, so that
anyone whose boss would complain about a $3000 lisp development
system should have a fairly simple job arguing for the reasonable
cost/benefit ratio of that investment compared to the questionnable
cost/benefit-ratio of your average company's "standardizing" policy.
--
regards,
Espen Vestre
Rainer Joswig
In article <65mags$l...@mtinsc05.worldnet.att.net>, "Tony Tanzillo"
<tony.t...@worldnet.att.net> wrote:
> The comparison was between a 'LISP system' (e.g., a development
> environment) and shrink-wrapped applications, regardless of what
> language they're written in.
When your application needs extensive customer programming,
a Lisp system starts making sense. If you are
user of a Lisp machine (like me), this makes sense, too.
Otherwise you are comparing apples and bananas.
Rainer Joswig
In article <65mb11$l...@mtinsc05.worldnet.att.net>, "Tony Tanzillo"
<tony.t...@worldnet.att.net> wrote:
> It's estimated to be 2-3 Million worldwide.
Is writing an Emacs init file already Lisp programming? ;-)
Given that Emacs comes with most Linux distributions,
is available on Macs, Windows NT, almost all flavors
of Unix comes with some commercial software development
packages on Unix (SUN, Eiffel, ...), there are books
about Emacs and Emacs Lisp, I'd guess Emacs
is in the same league.
Rainer Joswig
In article <MPG.ee8b5be8...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> I'm not being negative. Note all the other things in that job offer.
> You might only see the reference to CL, but I see the whole picture.
Who cares about "Common Lisp"?
> Let me know when AutoLisp reaches full compliance with CL.
Why?
> see this happen, so I can then point to AutoCAD whenever anyone doubts
> that real work can be done in Common Lisp.
I don't know what you want to point at, I can point at my own
work.
Rainer Joswig
In article <MPG.ee8bfa87...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> Rainer Joswig wheezed these wise words:
>
> > Face it. There is nothing in Lisp (whatever flavor) to prevent
> > you from writing/using "real" Lisp-based applications.
>
> If you mean using Common Lisp,
I don't mean "Common Lisp".
then there could be a few things.
> These things may be limitations imposed by people, which would make
> them merely percieved limitations, but that can be enough.
This is your problem.
>
> > Only your imagination.
>
> And a "One size fits all" attitude.
Again, your problem.
> good. It just means that there's a threshold below which a CL system,
> like ACL/PC, may be overkill.
Again, your imagination is the limitation.
> This is why "One size fits all" doesn't work. When you insist that it
> does, the message you're giving people is that they can't use Lisp.
> This too is a limitation.
I never said such a thing.
> So, while I don't currently feel a need for a GUI debugger for Lisp,
> I'm not troubled by the fact that AutoLisp users may feel otherwise.
I'm using GUI-based debuggers for Lisp daily. I don't like
command line interfaces which are limiting me. The only
useful command line interface for productive (Lisp)
programming *I* have seen so far is the "Dynamic Lisp Listener"
of Symbolics Genera. But this is not your ordinary command
line interface.
Ketil Z Malde
"Tony Tanzillo" <tony.t...@worldnet.att.net> writes:
> There are millions of people writing AutoLISP code.
There are probably millions of people writing elisp code as well. Rough
estimate: 5 million linux users, 25% uses (X|GNU)Emacs, and make up half
the total Emacs user mass = 2.5 million users.
> I don't count educational use, since it's not elective in many cases,
> but required.
So most employees choose which CAD to use, do they? I fail to see any
difference.
~kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Rainer Joswig
In article <65f20v$o...@mtinsc03.worldnet.att.net>, "Tony Tanzillo"
<tony.t...@worldnet.att.net> wrote:
> 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.
They went to Apple.
> I hate to break this to you, but most people don't need to write
> large-scale systems.
That's true - no doubt. Sometimes you are part of a large-scale
system, or you are using a large scale system. Then
the question is, what does it cost to make "small" extensions
to it? The indiviual says, I'm not working on a "large" system,
still he is working *with* a large system.
Still, it is important to support a level of tools
which are easy to learn (like Scheme).
> 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.
Some of these are. They have a certain business model. We're
not prepared to pay $x0000 to have unlimited
access to CL on our Unix systems (I would like to have such
an infrastructure at at some point), but currently this is
not discussable and unrealistic. Getting a project and using CL then
is a bit more realistic.
> 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.
Since the Lisp community is very diverse, I would not make
such a claim. Still, you are right, *some* of them are
arrogant.
GUI debuggers are common in the Lisp community - I mean
I'm using them on MCL, Genera and LWW.
Most of them are just not source level debuggers
you might be used to from other platforms. Part
of the reason is that it is not easy or even useful
to have a source level debugger (see for interesting ideas "ZStep"
from Henry Lieberman). In the presence of full compile-time
source transformations (Macros), a source level debugger won't
help really. I can't imagine how to use such a tool on some
of the code I'm using. Much of the computation can be done
at compile time. What you see then in the debugger
is just some distant idea. A single line can expand
into thousands of expressions at compile time.
You could argue for an evaluator based approach - then
you get "step". Still you can write new languages and
source level debuggers in Lisp (like "SK8" from Apple).
Martin Rodgers
Rainer Joswig wheezed these wise words:
> Who cares about "Common Lisp"?
[looks at posts to comp.lang.lisp] I wonder.
> > Let me know when AutoLisp reaches full compliance with CL.
>
> Why?
Why indeed. Why anything.
> > see this happen, so I can then point to AutoCAD whenever anyone doubts
> > that real work can be done in Common Lisp.
>
> I don't know what you want to point at, I can point at my own
> work.
AutoCAD has the advantage of having a huge market. Bean counters are
more interested in things like that. They'll probably ignore your
code, too, unless you can show a huge market for it.
Get this: code will only impress programmers, and in some cases only
then when it meets their ideologican requirements, like if the code is
written in C++. Bean counters only care about beans.
This is because money talks. It's easy to make a connection between
AutoCAD and money. Bean counters can understand that. That's why I'd
be happy to use AutoLisp, and even more happy if it were closer to CL.
Money talks.
Martin Rodgers
Rainer Joswig wheezed these wise words:
> Given that Emacs comes with most Linux distributions,
> is available on Macs, Windows NT, almost all flavors
> of Unix comes with some commercial software development
> packages on Unix (SUN, Eiffel, ...), there are books
> about Emacs and Emacs Lisp, I'd guess Emacs
> is in the same league.
In terms of supported platforms, yes. In terms of numbers of users, I
can't say. Is this an Emacs vs AutoCAD war? I hope not. What is it?
It used to be a simple question about debuggers...Please let's not
drift into Emacs advocacy! Life is too short for that. Likewise, an
AutoCAD advocacy thread would be equally silly.
Tony was answering your question about popularity. He gave a figure.
Emacs is irrelevant to this issue, unless there are people doing a
significant amount (numbers, please!) of CAD work in Emacs.
This is getting way too silly. Do you doubt that users like the
AutoLisp debugger?
Martin Rodgers
Rainer Joswig wheezed these wise words:
> This is your problem.
Thanks for your support. I'm explaining why there's so much ignorance
about Lisp hostility toward it, and all you can say is that you don't
care. Could be a little more positive?
> > And a "One size fits all" attitude.
>
> Again, your problem.
I disagree.
> > This is why "One size fits all" doesn't work. When you insist that it
> > does, the message you're giving people is that they can't use Lisp.
> > This too is a limitation.
>
> I never said such a thing.
Not in those words, but that is the message that you're giving. Alas,
you don't appear to realise it. That's why I'm attempting to explain
it to you, someone who challanges every little point I make.
Unless, of course, you have no problem with a CL system using a
AutoLisp style debugger?
> > So, while I don't currently feel a need for a GUI debugger for Lisp,
> > I'm not troubled by the fact that AutoLisp users may feel otherwise.
>
> I'm using GUI-based debuggers for Lisp daily. I don't like
> command line interfaces which are limiting me. The only
> useful command line interface for productive (Lisp)
> programming *I* have seen so far is the "Dynamic Lisp Listener"
> of Symbolics Genera. But this is not your ordinary command
> line interface.
Would you object to anyone using the AutoLisp debugger in a CL system?
We're not disagreeing about any Lisp issues. The debugger is more of
an environment issue, and not all Lisps need to use the environment or
style of debugger. So, what's the problem with Tony Tanzillo's POV?
Is he demanding that all Lisps use a debugger like AutoLisp's?
Martin Rodgers
Rainer Joswig wheezed these wise words:
> GUI debuggers are common in the Lisp community - I mean
> I'm using them on MCL, Genera and LWW.
> Most of them are just not source level debuggers
> you might be used to from other platforms.
We can agree on that. ;)
Rainer Joswig
In article <MPG.ee8eaef7...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> > I don't know what you want to point at, I can point at my own
> > work.
>
> AutoCAD has the advantage of having a huge market. Bean counters are
> more interested in things like that. They'll probably ignore your
> code, too, unless you can show a huge market for it.
I don't have to point to something else. We are using Lisp-based
software. "Code" is not the question. We are using this stuff.
Whatever you are talking about abstractly, we are using
it already (whether you or somebody else is able/willing
to be interested). If somebody is asking me, whether it
is/was useful, I can demonstrate what *we* are doing (which is
not really exciting but helps us making money and giving
people work). I guess that there are some people out there
who could say that, too. Somebody must buy this stuff or
Franz, Harlequin, etc. would not exist.
You are talking about this abstractly. Others are using
it. This has nothing to do whether AutoLisp has a huge
market or not or if somebody would like to look at my
code. Why are you not understanding that there
are really people out there who are using Lisp (in
whatever incarnation you like)? But Lisp is only
a tool. If your head is empty, Lisp won't help you.
Get ideas, follow them, then you may have a contribution.
Rainer Joswig
In article <MPG.ee8ecf41...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> > > This is why "One size fits all" doesn't work. When you insist that it
> > > does, the message you're giving people is that they can't use Lisp.
> > > This too is a limitation.
> >
> > I never said such a thing.
>
> Not in those words, but that is the message that you're giving. Alas,
> you don't appear to realise it. That's why I'm attempting to explain
> it to you, someone who challanges every little point I make.
I never said such a thing.
> Would you object to anyone using the AutoLisp debugger in a CL system?
No. Why should I?
Rainer Joswig
In article <MPG.ee8ee9b9...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> Rainer Joswig wheezed these wise words:
>
> > Given that Emacs comes with most Linux distributions,
> > is available on Macs, Windows NT, almost all flavors
> > of Unix comes with some commercial software development
> > packages on Unix (SUN, Eiffel, ...), there are books
> > about Emacs and Emacs Lisp, I'd guess Emacs
> > is in the same league.
>
> In terms of supported platforms, yes. In terms of numbers of users, I
> can't say. Is this an Emacs vs AutoCAD war? I hope not. What is it?
The question was "Is Autolisp the by far most widely used Lisp?.
I happen to say no.