relationship with our tools? NO.

[Matt Miller]

On Mon, 7 Dec 1998, Tril wrote:

> On Mon, 7 Dec 1998, Matt Miller wrote:
> 
> > system today.  By the nature of the GPL, the source is there.  You can
> > hack around with it and make it as insecure and unstable as you like.  Is
> > the major difference for you the fact that these things must be done in C?
> 
> Yes, being in C is part of the problem.  It's not just C, though, it's the
> form the source code comes in, ASCII text.  The need for source code to be
> processed all at once by a huge compiler is, IMHO a relic from the days of
> punch cards.  

Ok, I have been following the threads, but apparently not understanding
what I was reading.  I suppose I should wait for your specification of a
TUNES system, before asking these questions, but perhaps my fumbling
questions will help you refine your specification.

As I understand some of the previous discussions (and in light of the
above, which I didn't quite 'get' before):

- I create a "useful program" on my TUNES system.
- I share it with another TUNES user.
- My friend recieves an "object file" which describes how the "useful
program" works.
- Her TUNES system evalutes this object in the context of the TUNES system
which she has created.  
- She adds functionality to this, perhaps by "linking" it with another
TUNES object file which she has created.

Is that an oversimplified look at the process?

Also, per some previous discussion, this object would be constantly be
being "reevaluated" as part of the whole system.  I guess this is the part
with which I have the most difficulty.  Perhaps this is where Brian's
arrow structures arise?  Allowing us to determine the "dependencies"?
While I understand from the below that you aren't overly concerned with
binary effiencieny, it seems TOO inefficient to reevaluate the -entire-
system each time the user enters a keystroke, for example.

> Somehow, people decided efficient binaries were more important than saving
> programmer time.  Now, it is true, some effort is required to make a
> program optimized for a platform.  But spending time optimizing an
> algorithm for a specific platform and a specific data set is DIFFERENT
> from what we have today.  What we have is languages which force
> programmers to think in terms of the low level machine.  All programmers,
> not just kernel ones. 
> 

A lot of this, I believe is programmer mindset.  Some people naturally
write exceptionally efficient code.. they are venerated.  Others spend a
lot of time polishing their code to get these sorts of results.  

How will the TUNES abstraction of the underlying system work?  Will
we be writing to a "virtual machine" which takes care of all the
bookkeeping?  At some point, someone has to deal with registers and serial
ports and disk drives... will all of these things be abstracted out?

> The idea of a kernel itself is based on low level design, that of making
> the OS efficient.  Well, instead of the system programmers choosing what
> will be efficient, the user needs to do that.  Any design configuration
> has limitations and tradeoffs in efficiency in some cases, and benefits in
> other cases. 
> 

This seems at odds with my understanding of the above.  You seem to be
espousing 2 different desires:

- To make people not have to deal with low level "stuff" 

while,

- Making them responsible for the efficiency of the underlying
structure.

How do you reconcile these?  (I'm certain that you have.)

> So in TUNES we allow the user to make requests that have effects
> throughout the entire system, reconfiguring the organization of the
> various modules.  I am writing a specification for TUNES now that explains
> how all this works. 
> 
> Low level languages not only make it more time-consuming to program,
> but time-consuming to understand the code by reading it.

How will I view the code on my TUNES system?  (And please don't tell me ,
however I want)  It won't be ASCII text.  Will it  look like what another
user viewing the object sees?  Will it be the same code that I downloaded
off the 'Net?

> I don't know much about Emacs, except that it is a huge editor that runs
> lisp.  Is there something more?  Has lispos list discussed extending emacs
> to encompass an OS, Fare?  

While developed as an editor, it's capabilities have been extended far
beyond that by endusers.  I saw just yesterday, I think that someone had
developed an AOL Instant Messenger client which runs inside of emacs.
Some people use emacs as their login shell.  It's that comprehensive and
extensible.

Matt