Forth, LISP, etc...

[William Tanksley]

On Tue, 1 Jan 1980, Tril wrote:

>On Thu, 31 Dec 1998, William Tanksley wrote:

>> In contrast, I see a different model.  Data is pictured in my model as
>> being part of a flowing whole.  You can't simply pick up the data and drop
>> it into a black box without seperating it from the flow; therefore,
>> functions can't be pictured as giant black boxes.  Instead, functions are
>> tools, usually hand tools.  You don't pick up the data and bring it to a
>> machine; you pick up the tool and hold it up to the data, where it does
>> its work.

>I'm not sure I understand "hold the tool up to the data".  If you mean the
>data is persistent, and the tools operate on the persistent data, then
>yes. 

No, not really.  The data may or may not be persistant -- the point is
that data is the important thing, the big idea.  I'm comparing a function
to something like a chisel, rather than the traditional comparison to a
huge black box.  A chisel might be too simple; perhaps the hammer that's
used to hit it would be a better example.

At any rate, this model simply encourages designing functions which are
very simple and can be understood at least on the surface by anyone
picking them up/using them.

>Here is something I wrote today:
>Passing an object as an argument to a function doesn't invoke a explicit
>transfer of data; it connects an instance of the function to a history of
>information flow-- i.e. other functions.  An object, then, is a
>placeholder, a state.  The information contained by the object marks where
>the object is in a path of dependencies (a state machine)?

See, I'm experimenting with looking at it the other way around: don't pass
the object to the function, invoke the function on the object instead.
Otherwise there aren't any differences between what I said and what you're
saying :-).

>All data is metaprogramming information.  Configuration options, data
>files, command arguments, input, etc. are all only to select what path of
>execution to use.

No!  This is dead wrong.  No user has ever cared one whit what path of
execution his program took.  The only thing that matters is what gets done
to the data (or more generally, what data is produced).  All
metaprogramming exists for one purpose: to talk about producing data.  All
programming exists for one purpose: to produce data.

(Or information.  Or knowledge.  Or eventually wisdom.  May the day come
quickly.)

Anyhow, Tunes needs to be built for people who are expecting a result, not
a process.  For us, the process is what we're trained to watch for.  It
only bores them.

>This probably makes about as much sense as "you hold the function up to
>the data" :)

You're ahead of me, actually.  I understood you :).

>David Manifold <dem@tunes.org>

-Billy