good books (was: learning Lisp)
Brian T Rice
water@tunes.org
Thu Feb 20 17:38:02 2003
On Thu, 20 Feb 2003, Jecel Assumpcao Jr wrote:
> On Thursday 20 February 2003 19:53, Brian T Rice wrote:
> > Yeah, it's a huge disparity, and I love the way the Squeak community
> > treats its members, but we're unfortunately in a totally different
> > situation, with 7 years of dead time, little code, and documentation
> > that still needs a hell of a lot of work.
>
> I agree, and besides that Squeak (like Merlin) was created for children
> and newbies while I think that Tunes is more like Chuck Moore's
> ColorForth - he created it for himself and if other people are
> interested, fine, but that is their problem and not his.
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. 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.
> My point was that there are often several different ways of saying the
> same thing and you will get different reactions with them.
That's something I'll have to think about.
> > Speaking of the Slate documentation, I do have a new version of the
> > manual that I'd like to release soon (I've been somewhat steadily
> > improving it for a few months), but it still needs a quantum leap to
> > be the kind of manual that can be read without any background. Do you
> > have any suggestions of a pattern to follow or some language manual
> > that's similar enough and has the right level of detail and
> > approachability?
>
> I liked the manual that came with the original Methods and then
> Smalltalk/V the best. Tim Budd's "Little Smalltalk" book was very nice
> too. I have the original blue book ("Smalltalk-80: The Language and Its
> Implementation") and liked the middle part with the class catalog. The
> introduction had too many circular definitions for my taste.
I haven't been exposed to any of these books. Hopefully a "catalog" of
Slate libraries can be generated somewhat automatically.
> If you don't mind me branching off into a totally unrelated thread: what
> is the relation between Slate, Arrows and Tunes? The reason I ask is
> because I am trying to figure out ways to work together with other
> people. Back when Pios/Moose became Tunes, Far=E9 and I talked about
> merging our projects. That didn't work out mostly for reasons that no
> longer exist (Merlin wasn't free then but is now, for example).
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.
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.
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. 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. :)
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.)
--=20
Brian T. Rice
LOGOS Research and Development
mailto:water@tunes.org
http://tunes.org/~water/