related projects (was: good books)

[Jecel Assumpcao Jr]

On Thursday 20 February 2003 22:37, Brian T Rice wrote:
> On Thu, 20 Feb 2003, Jecel Assumpcao Jr wrote:
> > [silly Tunes, Squeak/Merlin is for kids!]
>
> Actually, I'd prefer to go along with a dual route, essentially:  one
> group of people who really grasp everything, and another group of
> even educators who teach using whatever we make.

Right, but as you mentioned in the other thread there is currently 
nothing for the second group to do. So I have no problems with an 
initial focus on the first group.

> Alternatively, our
> end users could be "web designers" who simply use our system (along
> with the appropriate number of bridges to existing systems) as an
> extended, more dynamic version of the world-wide web. Basically, we
> will *not* win over C programmers or perl hackers until we have a
> full system, so there's little point in trying. But out-doing Squeak
> in the systems, semantics, and user interface would be possible. The
> premise of Tunes is that we could do this with far fewer people than
> it takes to work on Squeak, for example.

How many people do you think made Squeak? I would say it was basically 
Dan Ingalls and John Maloney in the first phase, and Andreas Raab in 
the second. I hope I am not being horribly unfair here, but that was my 
impression.

And Squeak has the problem of a huge legacy it must be compatible with, 
so doing neat stuff is really hard. Putting modules in GNU Smalltalk is 
trivial compared to the effort that went into the failed Squeak 3.3.

So I agree - Tunes doesn't need a large group to exist.

> I haven't been exposed to any of these books. Hopefully a "catalog"
> of Slate libraries can be generated somewhat automatically.

The source files and comments are already a great start. They are very 
readable.

> > [relation between Slate, Arrows and Tunes?]
>
> Slate's an intermediate platform for Tunes, at least in my view of
> things. The interfaces work will go into this as well as the
> libraries and the run-time. None of the code we're writing for Slate
> is "Tunes code" as such: it will eventually need to be extended
> again. But it represents an intermediate point for Smalltalk, Lisp,
> and some less-expressive systems between them and Tunes, and so at
> least tells us how code has to change.

Ok, let me be more specific: I saw the Slate effort as being about 
multidispatch without types. Since I think about Tunes as being as 
serious as possible about types and correctness by proof, these looked 
like two different directions to me.

> The technical objection to the Self model for Tunes is simply its
> statefulness (not state per se, but the way it's expressed), the
> irregular grammar, and the system model.

I didn't notice between the way Slate and Self express statefulness, but 
wasn't really paying attention. In the other aspects, my own work now 
differs more from Self than Slate does. I have to write this up on my 
swiki so people can see what I am doing.

> As for Arrow, I am trying to resurrect my code for that, but it won't
> load in to newer Squeaks unless I discard all those damned class
> comments I wrote for it. Anyway it'd be more expressive/ible in
> Slate.

I can still run Squeak 1.3 when I need to :-) Do you think it would be 
worth having a Slate version of Arrow before you have a GUI?

> The relation to Tunes is mostly as a theory, and is missing as
> much in its plan for operation as Tunes is, except that Arrow has
> fewer concepts or rather structural requirements to support. This
> property means that I don't have to worry about "what a Context is"
> or "what kinds of meta-objects should be supported and how", because
> the model is so much simpler that there's no language concept to
> potentially stand in the way of getting the information annotation
> you want done. The disadvantage is that the basic idea has no real
> language concepts as such to explain it.  :)

Einstein said "make things as simple as possible, but no simpler."

To figure out what that is, I like to build things so simple that they 
no longer work in practice (a microprocessor with just one instruction, 
for example), learn as much as I can from it and then throw it away and 
start with something more reasonable.

> So that's my outline. There's a lot to work out, and I can't say for
> sure how much Self/R is closer to Tunes than Self, but Slate
> definitely picked up some ideas from it, and may continue to do so.
> (We don't even have a real MOP at the moment, so there's a lot of
> room for expansion there.)

There is a lot that I have worked out but haven't written down yet. A 
new syntax, meta-object architecture, lots of hardware stuff that is of 
no interest to Tunes, etc. I am changing the name from Self/R to Neo 
Smalltalk since I feel we are getting closer and closer to the core of 
what Smalltalk is all about even as it looks less and less like 
Smalltalk-80.

Right now I am bootstrapping a really small implementation of the 
language on a 16 bit microprocessor, so the details that I owe you all 
will have to wait a little longer.

-- Jecel