Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!apple!malcolm From: malcolm@Apple.COM (Malcolm Slaney) Newsgroups: comp.lang.lisp Subject: Re: Unix Lisp Environments (why the slow evolution) Summary: SCT is a big pain.... Message-ID: <30132@apple.Apple.COM> Date: 5 May 89 04:26:35 GMT References: <7802@zodiac.UUCP> Organization: Apple Computer Inc, Cupertino, CA Lines: 30 In article roberts@studguppy.lanl.gov (Doug Roberts) writes: >I think, however, that you missed one of the >major reasons that the Unix LISP environment is still decidedly >inferior to a LISPm: the majority of the market that is considering >LISP as a language in which to deliver applications is currently a >member of either the Unix or the VMS community: _they are not aware of >the productivity that exists ion a LISPm_. Nor _will_ most of them >become aware, given the cost disparity between LISPm hardware and the >other workstations. I think the real problem with LispM's is the very long learning curve. I was using Lisp for several years and then ran into a particurly nasty file system bug. I was amazed to see what a true wizard could do (thanks Kanef). As far as the original question goes...it is much harder to build a good system building tool for Lisp then it is for a conventional language like C/Fortran/whatever. In most conventional languages each compile can take place independently since the compiler doesn't depend on the environment. This is not true of Lisp. If you strip out the environment stuff and ignore the syntax than Symbolics' System Construction Tool (SCT) is much like make. I wonder if Symbolics will ever get rid of all the nasty bugs in SCT. What I really missed on the Symbolics machine was a good source code control system (no file versions are a bad way of doing that). I ended up keeping my Lisp sources on a Sun, accessed them on the LispM with NFS and used RCS on the Sun. Best of both worlds. (And using TAR to do distributions was MUCH simpler than distribute-system....argghh!!) Yours for bastardized systems.... :-). Malcolm