Self on Windows (was: RE: [self-interest] have to get this off my heart)

Tue Dec 28 09:32:07 UTC 2010

Hi David/everyone.

I've been following Self in the background for a number of years, am intrigued 
by it, and very much want to immerse myself in it for a time, to more fully 
determine its merits, its potential, and my potential with it.  However,  I use 
a Windows machine.   I don't remember when the question was last asked, but: 
 Why have we still no Windows version of Self?  

Shaping

From:self-interest at yahoogroups.com [mailto:self-interest at yahoogroups.com] On 
Behalf Of ungar at mac.com
Sent: 2010-December-27, 20:44
To: self-interest at yahoogroups.com
Subject: Re: [self-interest] have to get this off my heart

On Dec 26, 2010, at 5:12 AM, Jan-Paul Bultmann wrote:

I didn't say that they are useless :D
No, but you implied that when you said that you hated them and that their 
functions could be performed by invisible slots, whatever that means.

But they are one of those black magic things that happen in the VM and don't 
emerge out of existing concepts a bit like resends. Even though they are 
implemented nicely through the use of mirrors.

Sorry, but everything happens in the VM: slots, methods, method invocation, and 
objects. Resend, too. So, I don't see why annotations are any more
magical than anything else.

They also create a problem that is best known form  XML, what is property and 
what is content.
Should a comment go into the method or in to the annotation, why is the 
storeString stuff not in the annotation as well as prototype information.
They could be purely for meta information like store-strings, comments and 
categorisation, but then we should put everything that is not necessary for the 
function of the object into them.

When you speak of property and content, you embrace a dichotomy that is 
context-relative without owning up to its multiordinality.
In other words, just as with deep-copy, what is property vs content depends on 
one's purpose at the moment.
Methods already contained lots of "meta information", for instance temporary 
variable names, indentation, etc. etc.
Yes, it would be nice to handle all of that better--see Simonyi's intentional 
programming--BUT, in Self there is a clear distinction:
what we thought of as a method--remember we started from Smalltalk--was in the 
method; what we thought of as in the environment
(including the transporter) went into the annotations. When I read your remarks, 
I feel that you haven't thought about as many scenarios,
or as many previous systems, as one would have to do to understand the design 
space and all of the tradeoffs involved.
Many of my own designs for, say the transporter, seemed great for the first few 
objects saved, but failed miserably later on.

Even though they tend to contradict the principle of simplicity in my opinion, 
when they are there they should be part of the family and not some distant 
cousin you don't talk about.

When I read the above, I wondered if perhaps you had not heard of the principle 
of progressive disclosure.
Once designs a conceptual system so it can be learned in pieces. In the case of 
Self, there is a run-time story of objects and slots.
No annotations. They have no effect on the dynamic behavior of base-level 
programs.

Then, as you learn more, you can encounter object and slots comments, and 
finally the transporter.

I understand simplicity differently than you do. Following Shannon's information 
theory, simplicity has to do with how much once has to hear,
given one's prior (i.e. what you know already), to understand a system. Again, I 
would love to see a system that did all Self does,
without something like annotations. Design one, make it work, make it work on 
the scale of programs that Self does, and I would be
delighted to read about it.

When describing a Object we can no longer say it is composed of slots, and those 
slots hold information.

Yes we can, when describing its dynamic behavior. You seem to not understand or 
to discount the idea of context.

We have to say that a Object is composed of slots and Meta information in form 
of an annotation object, and those slots hold Information and meta information.

Yes, when it's time to file something out, or name it.

So it is not the idea that a Object can hold meta information that I don't like, 
it is more the fact that we should embrace them as a part of the language we are 
proud of, (like the totally awesome namespace ;) and cloning ) or we should find 
a different way.

I really don't understand the gripe. You seem to want to embrace a concept of 
"the language" that has no meaning to me.
Is the environment part of your "language"? It certainly makes a different for 
the programming experience.
What about the pre-programmed pieces that come with the image?
What about the concurrency model?
What about the fact that, in Self, you can split up your methods with no 
performance cost whatsoever? I would say that's part of "the language"
since it changes how you program.
What about the quality of the syntax error messages?

Every one of these things both is and is-not the "language." All matter.
I have heard many with too much mathematical training assert that Scheme Lambdas 
are "the same as" Smalltalk blocks.
But there is a huge difference in syntactic weight, and incorporation into 
common idioms.

What Randy & I cared about was the complete experience, the ability to unleash 
creativity.
Is the result of that project perfect? No.
But I'm afraid that I just don't resonate with any of these criticisms of yours.

Take care,

- David

Cheers Jan
On Dec 26, 2010, at 8:21 AM, ungar at mac.com wrote:

I put annotations in to support the other world; not the world at 
execution-time, but the world at programming time.
I have yet to see a model of execution that supports all of the structure a 
programmer needs to impose upon the world.
For instance, if you are going to file out a subset of objects or slots and then 
file them in to another world of objects, I am convinced
that you need more information than just what is needed to run the objects. See 
my OOPSLA transporter paper for details.

Also, it is very useful to have categories within a single object. At run-time 
you need just one object, but at concept-time, you need
some way to group things, although a strict hierarchy may not be optimal.

So, if you need some information that plays no role in execution, it must only 
exist in the reflective domain.
I don't see how you get anything much different than annotations, but I would 
enjoy seeing proposals.

Copy-down is a bit of a different matter. It sort of straddles programming time 
and run time, though only REFLECTIVE run-time.
Maybe the folks at Vrije have a better way, or maybe Ly, my latest object system 
design is better. (I think so.)
In Ly, all non-constant slots are copied-down, as part of the language.
You like names that are not googable, don't you ;D

It's easy to complain about something, but think about why it's there and how 
else you would do it.
In my experience, one ends up sweeping dirt around under the carpet; it doesn't 
go away. 
Once in a while there is a nice unification. If you don't like annotations, 
let's see you find that unification.

- David

On Dec 25, 2010, at 10:39 PM, Josh Flowers wrote:

Not sure I'd have been quite so diplomatic about it - but I don't disagree.

> First of all I wish you all the best :D.
> 
> I hate annotation.
> They are like a language in a language.
> Why not create invisible slots or something that are simply hidden my the 
>outliner.
> C'mon they managed to do the fricking namespaces with objects and slots... why 
>then staple something on top later.
> This has kept me up all week, what a relief.
> 
> Happy Holidays, Jan
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20101228/432c1a85/attachment.html>