specs

[William Tanksley]

On Sat, 2 Jan 1999, RE01 Rice Brian T. EM2 wrote:

>> I didn't ask for specifications, but I think that these are too low
>> level. In fact, they are implementation specifications. And I think
>> that we first need to specify what something should allow us to do
>> before trying to see how to implement it. It seems a bit early to talk
>> about pointers, memory chunks all that stuff. 
>> In fact, I think that we should first specify our needs, and then see
>> how we can build something that can fullfill them.

>i've already specified the arrow language!  the only thing left is
>vocabulary!  can't you understand that?  it's not some arbitrary computer
>programming language where the concepts are opinion-based.

Nonsense!  That's entirely what it is.  Nonsense to the "already
specified" part as well.  You may have defined it to your own
satisfaction, but we aren't mind readers and can't tell that.  You gotta
post it!

>in case you missed it, here is the language, everyone:

>arrows are abstract objects with N slots, the "default" being 2.  iteration
>on the default arrow type yields multi-dimensional arrow types.  each slot
>is a reference to an arrow.  all arrows are available for reference.

>THAT'S IT!  everything else is vocabulary which builds conceptual
>frameworks.  if you are looking for more specifics on the definition of the
>arrow language, LOOK NO FURTHER!

I'm looking for more specifics.  Here are some.

 - what's an abstract object?
 - what's a slot?
 - how is the number of slots significant?
 - what is "iteration on the default arrow"?
 - what's a reference?  How does it differ from a slot?

Most importantly,

 - what's the use?

>you people really are dense.

You may have done a lot of study to get this theory, but I wonder whether
you've ever tried writing it down before.  You're using terminology from
diverse fields in ways which are not directly related to the original
field -- it's a healthy guess that the meanings have changed, but it's
_hard_ to guess how.  Your so-called specification won't be complete until
it contains all of the things I mentioned in my last post, with all of the
possibly ambiguous terms de-ambiguized.

Seriously -- we can't even start on the design until we know _precisely_
what you want.

>this is the largest container for semantics ever devised!  it's obviously
>very much bigger than you can imagine.

I like your general attitude towards the Tunes project, and I think you're
right.  At the same time, though, and with all due respect, this really
looks like megalomania, and it's rather hard to study your work without
being baffled by it.  Seriously, even if we are all dumber than you
(possible, but unlikely), you still claim to need us.  Don't throw us away
so easily!

>witness a recent statement from the discussion:  the way to achieve tunes is
>not to add code, but to take code away from a specification.

Very Zen.  As such, I can't argue with it -- viewed as a koan, it holds
too much truth in its own contradiction.  Viewed as anything else, of
course, I have to call it rubbish.

Western logic isn't the only way to view the world, and I've become decent
at using other means.  But Logic isn't wrong just because it's not
omnipotent.

-Billy