Self-interest December 2010

self-interest@lists.selflanguage.org

20 participants
31 discussions

Even A Developer Would Call It Ugly
by Josh Flowers 15 Jan '11

15 Jan '11

but we did get a very basic, very hacked up, very functional IRC client working in Self. I actually used it for a good deal of the chatting I did in #self-lang. Most of the UI was created directly, so I don't think filing out the code is going to do much good. If enough people are interested I'll work on creating something more reusable. There was a half-joking claim that without screenshots the thing doesn't exist, so - and I warn you this is not safe for people with design astetic to look upon - here it is:

3 3

Hello! (or, What's the best way to learn Self?)
by Casey Ransberger 02 Jan '11

02 Jan '11

Forgive the newbie! I've been lurking for awhile, figured it was time. I found Squeak about three years ago, and it tied a lot of loose threads together for this particular token SIGPLAN weenie. I've read most of the Self papers, and am fascinated/awed by the object model. In a lot of ways it's close to an ideal to me. Smalltalk had this strange, unexpected effect on me: it crystalized things for me in a way that hadn't happened since Lisp, and before that, assembler. A lot of my preconceptions about programming disappeared into message passing, it's one of those new ideas that subsumes and unifies a set of old ideas. I'm really excited about Self, because it attacks the few things that were hurdles for me when I was learning Smalltalk. What's the difference between a Class Variable and a Class Instance Variable, and why would a Class Instance Variable be different from an Instance Variable? And WTF is a "Pool Dictionary" anyway? It seems we don't speak of them for some reason:P It's really good to see so much buzz around the system. When I first started reading about it, Self was a dead language, one of those mysterious wonders I would hear spoken about with reverence in mostly empty halls, lost to a microprocessor gone out of vogue, and only present like some distant, unseen celestial body, in the influence it exerts on other objects in its domain. Now I'm hearing about new releases and it works on x86! Thank you! I figured I'd ask what a good starting point might be for picking up the syntax and UI: I grok the object model pretty well (I think.) -- Casey Ransberger

5 10

Kqueue glue or deeper hook
by David Goehrig 01 Jan '11

01 Jan '11

Selfers, Matter of style question, I am building a kqueue binding for a web service app I'm building and was wondering if it would be preferred to be integrated in the os unix space along side select with glue code to implement it as a foreign function object, or would it be better to extend the base VM and make it more primitive? If anyone else already has an implementation I would love to steal their btw. Dave -=-=- dave@.com -=-=-

4 5

Re: [self-interest] have to get this off my heart
by ungar＠mac.com 31 Dec '10

31 Dec '10

On Dec 28, 2010, at 11:59 AM, Jecel Assumpcao Jr. wrote: > David Ungar wrote on Mon, 27 Dec 2010 18:50:51 -0800 > > On Dec 27, 2010, at 11:03 AM, Jecel Assumpcao Jr. wrote: > > > [gripe - strings instead of objects for annotations] > > > > The string part was an easy implementation way to save space. Sure > > storing objects would have been nicer.In fact they were changed back > > and forth to objects in a way that was transparent. Annotations were > > meant to be functional, so you could replace them but not change them > > in place.That saves a lot of space. Remember that every slot in every > > point object conceptually had its own annotation. > > Yeah, I didn't find a good alternative that would be reasonably space > efficient. In the syntax, an annotation can span a number of slots. But > in my designs I ended up just replicating the annotation for each slot > separately (sharing when possible). Hmmmm.... just now I see that there > is no reason to insist that maps be "flat". Just because the old object > tree was replaced by annotation doesn't mean that the maps couldn't > remain a tree. Then an annotation that only appears once in the source > would only need to appear once in the runtime structure. Lookup > performance is not as important in a compiler. > yes > > > > [gripe - strings in the parameters of fail blocks] > > Not sure what you mean here about Ole's extractor. > > It was easy for unrelated parts of the system to leak into the snapshot > that was being extracted. One example is floating point for the > factorial - there is one branch in the "power" function where the result > could be a float (but it never is in this application) and so you get > this huge overhead. The other place is string functionality: the > factorial app just needs enough to print its results but due to code > like > If the result could be a float, then there isn't much hope for an automatic extractor to know it couldn't be, unless I don't understand your example. > > + a = ( | > | asSmallInteger _IntAdd: a IfFail: [| :error. :name. | > ('badTypeError' == error) ifTrue: [ > " use double dispatching " > a addSmallInteger: asSmallInteger ] False: [ > ('overflowError' == error) ifTrue: [ > " retry after coercing to bigInts " > asBigInteger + a asBigInteger ] False: [ > primitiveFailedError: error Name: name ]]]). > > you bring in stuff from String. Hmmmm..... this isn't nearly as bad as I > remember since only '==' is being used. I thought there were lots of > 'beginsWith:' all over the place. > At one point there may have been beginsWith:, and you could argue (and I would agree) that we would have been better off making error objects to pass in to fail blocks. The issue there is *not* exceptions vs fail blocks, but rather fail-blocks with string arguments vs fail-blocks with object arguments. > > > IMNSO, exceptions were a botch invented in languages without blocks > > .I never liked the fact that control could invisibly branch off.For instance, > > in a long method with exceptions, containing A; B; C;, you cannot count on > > B being executed if A is executed. At least with fail blocks you can see > > the branch in the return symbol in the block .I know that others like > > exceptions. To me they are like iterators, both were workarounds for > > languages without blocksthat became enshrined in our culture. I prefer > > blocks. But that's just me. > > Actually, besides blocks you need non local returns to get the effect of > exceptions and I think Self code is a great example of how to do this. > But when I mentioned "exception objects instead of strings" I was just > thinking of having something like > Yes, of course. To me, "blocks" means blocks + block arguments + block locals + (what squeakers call closure semantics) + non-local return. Sorry if that wasn't clear. > > traits errors = (| isBadType = false. isOverflow = false. ..... > |). > badTypeError = (| parent* = traits errors. isBadType = true |). > overflowError = (| parent* = traits errors. isOverflow = true > |). > > This wouldn't really help in the '+' method above very much, but with a > more complete hierarchy and some actual functionality in the error > objects rather than them being simple tokens it could make a nice > difference. > Yup, these would be better to pass in to the fail blocks than strings. > > > > [tinySelf 0: special constant slot for object annotation] > > That would allow object annotations to be accessed without reflection, > > a change from what I considered tobe the appropriate base-level > > semantics. It is simpler, though. It violates my preferred model of > > object encapsulation. > > I agree, but in tinySelf 0 I had a bunch of "system slots" which you > couldn't access by sending messages to their object but which showed up > when talking to a mirror. The annotation slot was the only one I added - > the rest (like the "hidden parent slots" in the block clones and block > activations) were already part of the execution story for Self and I > just reified them. > So, slot types were always a tempting addition, but the problem was where to stop. If some slots are hidden sometimes, why not have many kinds of hidden slots hidden at various times? (This brings me right back to Us as a nice unification.) And you still, as you said, have the problem of reifying slots; in other words the problem solved with slot annotations. - David > > -- Jecel > >

2 1

have to get this off my heart
by Jan-Paul Bultmann 30 Dec '10

30 Dec '10

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

7 15

Distributed Objects
by Jan-Paul Bultmann 29 Dec '10

29 Dec '10

Hey, I realized that remote message sending between Objects of different worlds would come in pretty handy. Transporting Object live would become trivial and we could do networking entirely in self without inventing protocols. It was one of the powerful things that next introduced, in its lightweight form. So has something like this been tried and worked on before? Doing it for unary messages would be trivial, but once you put argument objects in there it gets nasty. Cheers Jan

3 2

Self on Windows (was: RE: [self-interest] have to get this off my heart)
by Shaping Shaping 29 Dec '10

29 Dec '10

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@yahoogroups.com [mailto:self-interest@yahoogroups.com] On Behalf Of ungar(a)mac.com Sent: 2010-December-27, 20:44 To: self-interest(a)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(a)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 > > >

3 2

Klein, ARM and Self Hardware
by Jan-Paul Bultmann 29 Dec '10

29 Dec '10

Hey, This ones a bit more towards Adam :) How is Klein going? I know you're basically doing this alone... I talked a bit with Thomas about where the best point was, to start pushing self without getting lost on the way. There is so much to do and once you start fixing one thing you notice you have to go a layer deeper and deeper and deeper. Like my goal of writing a desktop background. Should be a easy start, I thought :), oh what a fool I was. I endet up with the glCanvas. But writing OpenGl glue for the current vm might too not be the right choice, maybe this should rather be done for Klein. So what do you think? The other thing is, maybe we should pick a device and make it the main supported platform for self. I was thinking about something like this http://www.alwaysinnovating.com/products/touchbook.htm It seems to fit to the interest there was in porting self to the iPad, and I personally think multitouch fits our direct manipulation mantra well. Once we had full support of the single device fir Klein we Could port it to other platforms. But knowing exactly what hardware we are running on might help us the same way it helps apple compared to Microsoft or android. So again what do you think :)? Cheers jan

9 21

retrying
by ungar＠mac.com 28 Dec '10

28 Dec '10

> > From: David Ungar <ungar(a)me.com> > Date: December 28, 2010 10:08:54 AM PST > To: "self-interest(a)yahoogroups.com" <self-interest(a)yahoogroups.com> > Subject: Re: Self on Windows (was: RE: [self-interest] have to get this off my heart) > > > It would be great to have one. > > - David (from iPad, typos likely) > > On Dec 28, 2010, at 1:32 AM, Shaping Shaping <shaping1(a)rocketmail.com> wrote: > >> >> 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(a)yahoogroups.com [mailto:self-interest@yahoogroups.com] On Behalf Of ungar(a)mac.com >> Sent: 2010-December-27, 20:44 >> To: self-interest(a)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(a)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 >> > >> > >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >

1 0

"parent* = lobby" considered harmful
by Jan-Paul Bultmann 28 Dec '10

28 Dec '10

Hey, After spending some though on deepfreezing objects (pickling in python and serializing in java) and in the course of the discussion about deep copies, I came to the opinion that there should be no object holding the lobby as parent except for the world. It is like importing everything in any other language. Like doing import * or include<*.h>. In self a parent is seen as a part of the object that can be reused. But needs an object all prototypes at all time? And should all the prototypes really be globals :)? So that we not only reference the objects we really need leads to the problem that we don't know its true foundation. We could easily deep copy it when it only referenced them, because the object graph would contain exactly the objects it needed to work in every world, without taking the entire world with it. It wouldn't know about the others anyway. I like the way mixins are used, you have to explicitly demand them. Other objects and especially prototypes should be handled the same way. You reference them explicitly only if you need them, say in a "import*" parent object (if you don't want them to mess your object) and not via the lobby by name. Since slots are created in the context of the lobby you could easily add a slot and do "gasTank = gasTank" Any thoughts :D? Cheers Jan

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest December 2010