[Fwd: Re: [OT] We need a language]

David Scott Williams wilda21@ca.com
Fri May 30 14:46:02 2003

Woops...mistakenly didn't send this to the whole group

-------- Original Message --------
Subject: Re: [OT] We need a language
Date: Fri, 30 May 2003 17:45:28 -0400
From: David Scott Williams <wilda21@ca.com>
To: Brian T Rice <water@tunes.org>
References: <3ED72D7D.9020202@tiscali.it> 

You really are a dickhead sometimes, ~water.

If TUNES fails to take off, at least you will have refined this aspect
of your self.

Brian T Rice wrote:
 > On Fri, 30 May 2003, PB wrote:
 >>"We need a language that lets us scribble and smudge and smear,
 >>not a language where you have to sit with a teacup of types
 >>balanced on your knee and make polite conversation with a
 >>strict old aunt of a compiler."
 >>Paul Graham, "Hackers and painters".
 > Well, this certainly got a lot of responses. It has well-thought-out
 > responses on LL1 as Fare mentioned. The stuff here is silly.
 > May I re-interpret "we need a language" as a call for HLL definition?
 > There are certainly a lot of misconceptions among today's posters.
 > Certainly the designs in http://tunes.org/HLL/architecture.html should
 > explain that we're not talking about a single language, but something 
 > akin to a network. The spec work at http://tunes.org/~water/spec/ points
 > to a similar explanation, and also explains that the primary point is to
 > be able to define subsets of functionality and such that make those
 > optional proofs that Jeff mentioned possible. The spec defines a 
subset as
 > any situation where something is restricted in /any/ way at all, which
 > includes typing of attributes or configurations. This is both necessary
 > for a useful system and for a safe and high-performance system. How else
 > can you assume that something won't happen except by not letting it 
 > or observing that it doesn't (noting that real-time observation violates
 > the principle anyway)?
 > Slate certainly doesn't attempt to do any of those things, and Max 
 > either, really. They're projects to demonstrate and exercise the use of
 > various aspects, like persistence, interfaces, run-time architecture, 
 > Do any of these things not make sense to people, or are you content to
 > reply about something which has nothing to do with TUNES with ramblings
 > that ignore what TUNES has to teach?