Path: utzoo!attcan!uunet!convex!killer!pollux!ti-csl!pf@csc.ti.com
From: pf@csc.ti.com (Paul Fuqua)
Newsgroups: comp.software-eng
Subject: Re: What's a PC? (What's the best environment)
Message-ID: <63259@ti-csl.CSNET>
Date: 12 Nov 88 00:50:11 GMT
References: <5315@louie.udel.EDU>
Sender: news@ti-csl.CSNET
Organization: TI Computer Science Center, Dallas
Lines: 66


    Date: Thursday, November 10, 1988  3:22pm (CST)
    From: new at udel.EDU (Darren New)
    Subject: Re: What's a PC? (What's the best environment)
    Newsgroups: comp.software-eng

					     Personally, I think the browsers
    (system browser, debugger, inspector, ...) and the predefined classes
    (views, collections, ...) are the main contributors to productivity.
    Also, the almost instant turn-around fromchange to test is vital.

That's part of what I mean by "integrated environment."  As a colleague
put it, you get much more than just the program you're running, you also
get the debugger, etc. (cf Unix and C, in which you usually have to
recompile with -g to use the debugger effectively).

The environment lends itself to quick edit-test-debug cycles on small
parts of the program, which can then be built up independently and
combined and reused and modified.  When I did my last simulator, I first
built up the display from existing windowing code (which itself is built
on the window code supplied with the system), then added the command
loop, then went back and built up the simulation objects and their
operations, then hooked the parts together and started running.  Pieces
of that code came from previous projects, and other pieces are in later
projects, and it's mostly because modularity is easy.

    Of course, the o-o aspect is important in supplying such abilities.

Exactly.  That's what I was saying.

    >Most modern Lisps provide lists, arrays, structures, and "objects" (as
    >in Flavors or CLOS).

    But it doesn't supply Rectangles, Debuggers, Contexts, CompilerParseNodes, ...

We're going to get into religion here if we're not careful.  I use a TI
Explorer, and before that a Symbolics 3600, so my biases are toward Lisp
machines in the MIT mold, which *do* supply that sort of thing.  What
you can't do is send messages to arbitrary things, because not
everything is an "object," in the sense of understanding messages and
having state.  However, many of the data types available have components
and operations upon them, and you can get a handle on nearly anything
and pass it around, so even the non-"objects" are a lot closer to
object-oriented than, say, C or Fortran.  It's a short step from data
abstraction to object orientation.

    One of the advantages (and disadvantages) of Smalltalk is that EVERYTHING 
    is an object, including your execution stack, your mouse, your compiler,
    your menus, your screen, your source, your object, and so on. 
    Even error messages are messages sent to objects. 

On a lispm, error instances are objects, with operations to print their
message or enter the debugger.

    Can you add multiple inheritance (cleanly) to your OO Lisp?

It's already there, as part of the basic design of both Flavors and
CLOS.  Folks I work with wonder how anyone tolerates the lack of
multiple inheritance in C++.

                              pf

Paul Fuqua
Texas Instruments Computer Science Center, Dallas, Texas
CSNet:  pf@csc.ti.com (ARPA too, sometimes)
UUCP:   {smu, texsun, cs.utexas.edu, im4u, rice}!ti-csl!pf