C - eunichs

[Reti@RIVERSIDE.SCRC.SYMBOLICS.COM]

    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: ian@iexist.att.com (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
    better, no?
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
	most general.

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

	Ian