[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
C - eunichs
Date: Wed, 23 Jan 91 08:16 PST
From: kma@SAMSON.cadr.amis.com (K. Mark Alexander)
Date: Tue, 22 Jan 91 15:28 CST
From: firstname.lastname@example.org (Ian Bruce)
There seems to be a tendancy to equate lisp to a symbolics development
environment. I could, given the genius which SYmbolics initially had
and several years to do it, probably create a similar environment (with
all the fault tolerance -- and bugs) on a UNIX box.
I wish someone would get the stroke of genius to do this. Given the
arguments I've seen on this subject it should be relatively easy to do
in C. It's already been done once, the second time around should be
My personal opinion (speaking as a long-time software implementor on lots of development
environments besides the Symbolics Lispm) is that this would be a VERY LARGE job. There
were a large number of man-years expended upon the environment before Symbolics got it
(at the MIT AI lab) and there have been (very rough guess) several hundred man-years expended
since then. All this in a development environment which makes development and debugging particularly
easy. While it is in theory doable, I don't think it can be done in practice.
In fact, many of the
best lisp hackers I know already work on SUNs. Lisp has come a long way
with CommonLisp and CLOS, etc., but for production software for many
applications, the image is too large and the (not well written Lisp code)
is too slow.
This is a bug not of Lisp, but of the implementation, right?
We deliver Lisp on SUNs via AKCL (which generates C, by the
way). C is a great assembly language for integration of systems written
in higher level languages (e.b., SDL, lex, yacc, CL). Lisp is not the
only language that gives you leverage -- it may be the most powerful and
The people who use software are not just the people who write it!
That's true, but let me point out a few of the 'development' features that two
real-world, large projects on Lisp machines that I've worked with recently depend upon:
1) an error system that can trap ANYTHING (including operating system bugs, disk errors,
network errors, even faults due to broken hardware) and produce automatic bug-reports
including backtraces for logging (and eventual later inspection by the developers).
These backtraces can optionally be automatically mailed to the developer.
2) run-time type checking (in conjunction with the above) to catch several classes of
bugs in the complex software (attempts to access arrays out of bounds, attempting to
operate on wrong or inappropriate data types). The software is in production use,
but the (now) occasional bug needs to be caught and eventually fixed.
3) Instrumentation of what would be operating-system or driver code in other environments
for real-time, operator-initiated tracing. The types of things traced are incoming and
outgoing serial packets, process switches, page faults, etc. These are traced in an
application-dependent way and only for the processes which participate in the application
and only when requested by using encapsulation.
4) One of the two systems allows the operator to modify the behavior of the system by
changing the actual code that is run; run-time evaluation and compilation are both
an inherent part of the application.
All of these would be much harder (though not impossible, I'm an old systems hacker, after all)
to do under Unix/C.
cannot ask a customer to buy an XL1200 to run my application, I can
justify it for developing the application.
It depends on the application. Both of the ones referred to above run on XL1200's.
We are a long way from the
day when lisp will be generally used for application development until
the problems of size and speed are well resolved.
- C - eunichs
- From: kma@SAMSON.cadr.amis.com (K. Mark Alexander)