Self-interest January 2011

self-interest@lists.selflanguage.org

18 participants
10 discussions

Self (and OOP) noob says Hi!
by cgnormandin 03 Feb '11

03 Feb '11

Hello list! I've dabbled with Smalltalk Squeak, and GNU Smalltalk. Didn't get too far ;( OOP has been a real struggle for me. Hoping Self will change all of that. Is there a "Self by Example", or something similar? I need to get familiar with the VM, as well as the language itself. Much obliged ... -- Duke

7 10

UnitTests
by Jan-Paul Bultmann 17 Jan '11

17 Jan '11

Hey, I just wanted to share this with you, it gave me a good laugh. http://blip.tv/file/2089545 It also has an interesting point. Smalltalk died because you could make a mess too easily. And I think this is especially true to Self, because of its behaviorism. Cheers Jan

16 34

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

retry
by ungar＠mac.com 15 Jan '11

15 Jan '11

Begin forwarded message: > From: Yahoo! Groups <notify(a)yahoogroups.com> > Date: January 11, 2011 10:45:50 PM PST > To: ungar(a)me.com > Subject: Unable to deliver your message > > > We are unable to deliver the message from <ungar(a)me.com> > to <self-interest(a)yahoogroups.com>. > > ... > From: David Ungar <ungar(a)me.com> > Date: January 11, 2011 10:44:51 PM PST > To: "self-interest(a)yahoogroups.com" <self-interest(a)yahoogroups.com> > Cc: "self-interest(a)yahoogroups.com" <self-interest(a)yahoogroups.com> > Subject: Re: [self-interest] UnitTests > > > We invented it back before the net was anything like it is today. We had to take frequent breaks back then to > gather the firewood for the steam boilers on those old computers. > > -- David (tapped out on my iPhone; blame it for any typoze;-) > > On Jan 11, 2011, at 6:47 PM, Jason Grossman <spam-me(a)xeny.net> wrote: > >> >> On 12/01/2011, at 12:43 PM, dpharris(a)telus.net wrote: >> >> > Can you give 'us' a url, again. 'us' is very difficult to google. >> >> Right! I've complained to the author of Nu about the same problem. Io isn't much better either. >> >> I would prefer a language to be called Zthsqwjkkr than any combination of only two letters. >> >> Jason >> >> __._,

3 3

retry
by ungar＠mac.com 14 Jan '11

14 Jan '11

Begin forwarded message: > From: postmaster(a)mac.com > Date: January 11, 2011 5:24:03 PM PST > To: ungar(a)mac.com > Subject: Delivery Notification: Delivery has failed > ... > From: ungar(a)mac.com > Date: January 11, 2011 5:24:02 PM PST > To: self-interest(a)yahoogroups.com > Subject: Re: [self-interest] Re: UnitTests > > > Amen. To paraphrase Gilad Bracha: most programmers don't understand much about a language beyond its concrete syntax. > > > > On Jan 11, 2011, at 4:41 PM, Mario wrote: > >> >> >> --- In self-interest(a)yahoogroups.com, "Adam" <adam.spitz@...> wrote: >> > P.S. Incidentally, for those of you who don't feel like watching the whole video, the relevant part is at 21:25: >> > Ward said, "What killed Smalltalk is that it was just too easy to make a mess. You C++ programmers are lucky, because the language punishes you if you make a mess. Your builds start to take forever. You've got to undo some of the mess just to survive. But the Smalltalk people could add mess upon mess upon mess with no immediate ill effects. Their builds didn't run any slower - there *was* no build. There was nothing that went wrong with them; as long as they could manage to keep all the balls in the air, they were all right. But eventually you could build a system that was so indirect and so impenetrable and so convoluted that no one could understand it or touch it and it would become impossible to deal with." >> >> Adam, thanks for posting the quote. >> >> Sadly, I watched the whole thing before seeing your message, and was not impressed. Martin has an entertaining presentation style - but the argument was simply lacking. >> And his rewrite of history - as evidenced by that quote - is complete BS. Smalltalk had a small but fast-growing market, and was thriving before the arrival of Java. There were numerous startups addressing various problems (including Animorphic, which developed HotSpot from the Self VM, but before that was developing a Smalltalk VM) and even we at Sun Labs had been talking to SunSoft about productizing Self as a Smalltalk engine (that was the genesis of my Smalltalk-in-Self effort). >> >> What killed Smalltalk was the arrival of Java, plain and simple. Not because Java was better, but because it appealed to the legions of C and C++ programmers, mostly at a syntactic level (from expression syntax all the way up to a file-based environment). It came at a time when then was widespread disenchantment with C++ (I remember the wave of enthusiasm for C++ at OOPSLA'90 which had evaporated by OOPSLA'92). And the clincher was that it was associated with the Internet. Who'd have thought something as transient and shallow as applets could have fired so many people's imaginations? It all seemed kinda obvious and trite to the Smalltalk community. >> >> Sadly, for widespread adoption, syntax matters. Maybe if Ruby catches on in a big way the world will be ready (readier) for Smalltalk, or Self, but I suspect by then we'll have different problems to solve (ubiquitous concurrency, for a start). I'm convinced that radically new programming paradigms are adopted only by wholesale attrition of the existing workforce, so it's a generational thing. >> >> -Mario >> >> > > >

1 0

Traits, Lobbies and The Transporter
by Josh Flowers 10 Jan '11

10 Jan '11

As I write up the notes about programming the IRC channel morph it's clear there isn't much left: I hooked up all the morphs, rearranged some code, and then spent three days finding the relevant formulas and incantations to file out my code. I'll still work to get those notes typed up, but I'm also putting together this e-mail to talk about the parts of Self I didn't like - mainly because I don't think there's any chance they'll generate conversation on the wiki. So on to the criticism.... Traits: Thought I liked traits, but learned that I don't. When I first came across them they seemed like a natural part of the environment, but in practice they don't seem to fit. Self's a concrete environment but traits become very abstract objects. When looking at the code you'll often find them referencing slots that don't exist on the trait itself, even if you go chasing up the parent slots. Doesn't take me long to realize that the trait object assumes it's children define the slot, but it still doesn't feel right. The lobby: Pettily, I don't like the name. As a user of the system I don't think of it as the place where objects enter the world (and if I did I'd still probably not like 'lobby'), but as a place where the blue prints for objects are kept. If anything the already-used term 'factory' seems like a better name. But that's just semantics - what really strikes me about the lobby is that it feels like it should be a virtually-physical place. Much like the actual morph Factory, there should be a way for me to simply drag an outliner into the lobby, and then name it (and then drag them out again when needed). The Transporter: We've gone over this one to some degree so I won't go into detail, but it also lacks the tangible feel of Self. To back up the point a bit, I don't believe the IRC channel morph I created has ever successfully been filed out/into a clean snapshot. The transporter may be a good tool for a lot of things, but it also feels like there needs to be an easier way to share objects. I also don't like the same-named movies, but I don't think that's influencing me. Just points for conversation (if any of us have the time), Josh

2 1

Saving objects with Hackney
by Russell Allen 04 Jan '11

04 Jan '11

All the talk about object saving etc inspired me to throw together a rough sketch of a framework for object saving as a exercise in building stuff in Self. The code builds upon the transporter's facilities but ignores modules. All it does is take a object root, map out the bounds of the object cluster using a fitness test, then write out the set of objects on the file in a pleasing indented manner. It more or less handles internal loops; but a nice mechanism for that depends on moving the parser from the VM into Self. It has a hardcoded limit of 1000 objects to iterate over, just to make development easier by preventing accidentally iterating over the entire image. The current fitness test is simply whether (a) the sub-object has a creatorPath and (b) whether it is a worldMorph. Playing with this is a good illustration of Dave's point that the tricky question is where to stop! This is a rough outline of a framework for testing stuff (in particular there aren't any tests and the code is ugly :) - it probably isn't particularly useful. Things I missed while writing this: a streams library, a unit testing framework, a modifiable Self parser If you take a clean snapshot and put the attached hackney.self file in the same directory, you can load it by: bootstrap read: 'hackney' From: '' and then save objects as: transporter hackney save: myObject As: fileName and load by getting the results of: transporter hackney read: fileName Have fun, Russell

2 5

Re: [self-interest] have to get this off my heart
by ungar＠mac.com 04 Jan '11

04 Jan '11

Interesting, your description of slot alternatives. Lisp was the limit: only two slots, no names. So bad that folks had to invent static typing for it. Slot types do see problematic to me, but we did have argument slots in Self. Tough choices. - David On Dec 31, 2010, at 11:03 AM, Jecel Assumpcao Jr. wrote: > David, > > > 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. > > Sorry, I have two very different examples of how stuff could "leak". > There really was no relation between the float problem and the string > parsing so I shouldn't have mixed them like that. > > > 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 ratherfail-blocks with string arguments vs fail-blocks with object > > arguments. > > Once again, the problem was with my description. I wanted to say what > you just said but "exceptions" slipped in when trying to make an analogy > of how the set of objects to be used as parameters might be organized. > Many OO languages have a hierarchy of error and warning objects and I > was thinking of something like that. I didn't mean to bring any other > aspect of exceptions into the discussion (right now I am implementing a > Squeak VM and am finding them very troublesome...) > > > 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. > > You were clear, but I added the comment about non local returns just in > case someone else following the discussion isn't aware of the importance > of that aspect. In particular, this is something that is used very > rarely in Smalltalk-80 compared to in Self. > > > ["system slots" in tinySelf 0] > > > > 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. > > I tried several different designs going to both extremes (lots of > implicit information vs explicit) and it isn't easy to find a good > balance. Perhaps there isn't one, and each situation a different choice > is the best. > > Just as an example, in one version of tinySelf 0 (done before Self 3 > came out, so this didn't have annotations) each slot had three words in > the map: the name, a value and a code pointer. The system just called > the indicated code with the supplied value (along with the receiver). > The code for a constant slot (shared by all constant slots in the > system) just returned the value, while the code for a data slot indexed > the receiver. The code for a method that hasn't been compiled yet was > the interpreter itself (the value is the bytecodes) while if it has been > compiled it was the native code (the value is still the bytecodes, but > that is ignored). > > This Forth-like version has almost everything implicit. You can create > many new types of slots, but there is no good wait of doing stuff with > them other than their default behavior. The other extreme was to have > each slot be a full object, which is hardly efficient in terms of memory > but does make everything very explicit. > > -- Jecel > >

1 0

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

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 January 2011