Self-interest July 1994

self-interest@lists.selflanguage.org

19 participants
22 discussions

Re: Obfuscated Self
by R James Noble 26 Jul '94

26 Jul '94

About GNU Smalltalk/Little Smalltalk, dib(a)signal.dra.hmg.gb (David Bruce) writes: > Just out of interest, what's the problem: functionality or efficiency? Well, both are blue-book style interpreters written in C, in GNU Smalltalk's case, it is almost a direct translation from the blue book, for example the bytecode set is the same, which is not true for Little Smalltalk. Gnu Smalltalk includes all the base collection classes, and there is apparently an interface in the works, but this has been delayed. Within a year or so, you may be able to describe Gnu as a good Smalltalk circa 1985 :-) Brook Conner <dbc(a)cs.brown.edu> writes: > Both are, as I recall, hopelessly cut down. GNU Smalltalk includes an > interface to the X Protocol but nothing more in terms of environment. > Last I heard, Little Smalltalk was missing important things like > instance variables :-) Little Smalltalk is based on a different bytecode. It also interprets cascades differently, and objects can have either named or indexed instance variables --- more minimal even than Self. (Actually, if you use both they overlay each other). dib(a)signal.dra.hmg.gb (David Bruce) writes: > This raises the following question (for instructors, I guess): > how slow a system could one `get away with'? Well, we use Tcl here *lots*, and the Kamin interpreters, neither of which are fast. It depends what you're doing. If you kept the Self language, but added a nice UI layer implemented in C(++), you could compete with things like Tcl. Two languages which have done this, quoting Self as an influence, are VisualObliq and NewtonScript. jecel(a)lsi.usp.br (Jecel Mattos de Assumpcao Jr.) writes: > But is you had a book, it would make Self more "respectable" in the > eyes of many educators. A book is a nice idea - Tcl has one, Modula-3 has several, even Lisp-Stat has one. Unfortunately I'm rather busy at the moment :-) James -- James Noble, Graduate Student, Computer Science Department Victoria University, Box 600, Wellington 1, New Zealand kjx(a)comp.vuw.ac.nz

1 0

Re: Obfuscated Self
by jecel＠lsi.usp.br 26 Jul '94

26 Jul '94

Brook Conner <dbc(a)cs.brown.edu> wrote: > Well, for our part, we're going to be looking at Self for teaching > novice programmers object-oriented programming. Compared to C++, I > think we have a win in syntax. Compared to Pascal, perhaps, but that's > some of the stuff we'll be looking it. I think the semantics of the > language will be much easier to teach. There's so much little kruft > that you don't have to worry about (memory allocation, numerical > overflow, VAR vs non-VAR parameters). Of course, this is all > intuition. I recently taught Smalltalk to nine Pascal programmers and was amazed at how hard the class/instance distinction was for them. I thought it would be easy given their three year experience with types. After they seemed to have learned this, they could still not decide whether a method should be a class method or instance methods. I kept wishing I was teaching Self instead ( not possible in a PC-only lab ). > I remember someone on this list a while back saying that Self would > make a wicked cool shell (you know, instead of csh or zsh or > somesuch). Of course, it takes a little bit more memory than csh to > run it... :-) That is one way I am using it in my project. > Jecel> [ Self = ODL + MPL, MPL readable, but less so than scripts ] > > What do you think makes scripting languages more readable? Certainly, > UNIX-based scripting languages have historically been some of the most > obtuse languages on the planet. Hypertalk always struck me as easy to I agree. I was refering to Hypertalk and parents. > read, but hard to write (I could never remember what the damn keywords > were, and kept thinking I could just use English and it might work -- > of course it didn't -- I think the extreme readability combined with > what was actually a rather inflexible syntax was a poor match -- I agree with this too. Given was was achieved in the parsers used in text adventure games, Hypertalk could have been much more flexible. Though it has been 15 years since I've programmed in COBOL, I think even it was not as rigid. > perhaps its a rule of thumb that a language should be as readable as > it is writable and vice versa -- Perl is often called a "write-only" > language, because even the programmer can't figure out what it was she > wrote). For novices, APL and even C are write-only too. > Jecel> [ UI is a graphical ODL ] > > Yeah -- I think what bothers me about the UI though is that it isn't > as responsive as I'd like -- it is plenty fast, once you've grabbed on > an object and are moving it around. But just click on an object and > wait for _some_ response while the VM compiles the click response. > The same kind of thing goes for garbage collecting -- it is plenty > fast (beats the pants of Emacs) but I'd still rather see it in another > thread (with its own LWP where it could be scheduled at a lower > priority and possibly on another processor). Again, I'm just looking > for responsiveness. You need a faster machine ;-) > Now, of course, Jecel's point about replacing the ODL with the > graphical boxes begs the question "Why not replace the MPL as well?" > This could be really cool in 3D: the objects are > things/vehicles/robots in the world. Open up access panels (slots) and > see the engines (methods) driving the object. Move some gears around, > reconnect some wires, and you've changed the object's method. Blocks > become little engine components -- by putting them in the right place > (i.e., lexical context) they do the right thing. It seems that great minds think alike :-). Back in 89 I came up with a "visual Smalltalk", very similar to your idea, for a keyboardless computer for children. Click on the object with the hand cursor and make it do somthing. Click on it with the screwdriver cursor and it opens up to reveal the internal circuits. Complex drawings have some problems ( as a hardware designer, I should know! ) so I later switched to animation to bring using/prgramming/debugging closer together. I already described this here some time ago, so I won't go into more detail right now. > Jecel> If you have to face ".self" files, then I'll agree that there > Jecel> are less intemidating languages around. But the current ( and > Jecel> certainly even more so in the future ) implementation seems > Jecel> to me to allow simple, clean and powerful programming which > Jecel> I would not hesitate to show to novices. > > Let's try this out and _prove_ it! Mario.Wolczko(a)Eng.Sun.COM (Mario Wolczko) wrote: > One test is due to occur next Tuesday and Wednesday: Jon Taylor and > Trevor Hopkins at Manchester University are going to teach an > introductory OOP course using Self as the medium of expression. > > This is the first tangible product of collaboration between the Self > project and various educational institutions in this area. Our goal > is to make the results of these initial teaching experiments > (including teaching materials) available to anybody who wants to use > Self as a teaching vehicle. > > Watch this space for news.. This sounds great! Of course, the best material of all is Self and its user interface. But is you had a book, it would make Self more "respectable" in the eyes of many educators. These teaching materials might be the seed of such a book. A few people have tried to convince me to create a simple PC based implementation of Self and include it for free in a book for novices to spread out the word :-). I don't know if it is a good idea - Little Smalltalk and GNU Smalltalk leave many people with a bad impression of the language. - Jecel

2 1

Re: Obfuscated Self Date: Mon, 25 Jul 94 11:05:22 EST From: jecel@lsi.usp.br (Jecel Mattos de Assumpcao Jr.)
by dib＠signal.dra.hmg.gb 25 Jul '94

25 Jul '94

A few people have tried to convince me to create a simple PC based implementation of Self and include it for free in a book for novices to spread out the word :-). I don't know if it is a good idea - Little Smalltalk and GNU Smalltalk leave many people with a bad impression of the language. - Jecel Just out of interest, what's the problem: functionality or efficiency? I'm not so familiar with {Little,GNU} Smalltalk; are they hopelessly `cut-down' versions of the real thing (cf. microemacs :-)), or just very very slow? I know that an efficient implementation of Self is decidedly non-trivial, but surely the point of the language is that it is simple and so could be implemented naively (e.g., as an interpreter) without an enormous effort (though not necessarily by a novice!). This raises the following question (for instructors, I guess): how slow a system could one `get away with'? David Bruce ---- post: DRA Malvern, St Andrews Road, Malvern, Worcestershire WR14 3PS, ENGLAND email: (internet) dib(a)dra.hmg.gb or dib%hermes.mod.uk(a)relay.mod.uk phone: +44 684 895112 ** fax: +44 684 894389 or 894540 ** telex: 339747

2 1

Re: ToonTalk
by Randall.Smith＠Eng.Sun.COM 25 Jul '94

25 Jul '94

Dave and I at least are old chums of Ken Kahn, who was at PARC while we were designing Self there. Ken's current work is a natural outgrowth of his interest in (of all things) prolog-like languages, and his interest in animation. Other neat things Ken has done include Visual Janus, and, much earlier a system called Dierector at MIT. If anyone wants his e-mail address, let me know. Ken is currently trying to productize this system, which is really cool for an interesting meaning of the word "cool." --Randy

1 0

Re: consistency again ( was: Notation for delegation in OMT or BOOCH )
by mulet＠info.emn.fr 25 Jul '94

25 Jul '94

When I introduced Moostrap to you, my purpose was not to say that Self is not a reflective language. In fact, it provides same kinds of reflective stuffs as Smalltalk, which is structural reflection. But in Self there is no protocol for controlling message passing properly, i.e. as a metalevel operation (considering the panic/notPanic toggling). In Moostrap, we can dynamically redefine the algorithms for message passing for handling classes, before/after ... it is related to Clos-MOP and ABCL/R. Best regards, Philippe Mulet.

1 0

Obfuscated Self
by jecel＠lsi.usp.br 22 Jul '94

22 Jul '94

Brook Conner <dbc(a)cs.brown.edu> wrote: > "Michael Grant Wilson" <mcq(a)oti.on.ca> said: > > urs(a)cs.stanford.edu wrote: > > > On the other hand, they would be a wonderful tool for an annual > > > Obfuscated Self Contest. :-) > > > > Not required. After C++, Self is already the most easily obfuscated > > language on the planet. > > Oh yeah, right :-) You forgot Perl, Tcl, Postscript, and everyone's > favorite, machine language that writes over itself. This is a *very* important issue for me: my project will be a garanteed failure unless I can teach a number of people to program in its language ( as the first programming language to most people ). I have looked closely at scripting languages ( including Hypertalk ) and have also thought a lot about ECHONET ( You can read about it in the September 1983 issue of Byte, pages 356-373 and October 1983 pages 384-395. Now this was a language that did *really* agressive inlining! ). When I looked at Self, I saw at once that: Self = ODL + MPL, where ODL is Object Definition Language and MPL is Message Passing Language. The MPL is a slightly modified Smalltalk that is highly readable ( not as much as scripting languages, but handles nested expressions much better than those ). The ODL is the LISP-like ( | x <- .... y = ( | .. | .. ) | ) kind of thing. The neat thing is that one or the other might be replaced by an equivalent notation and the whole would still be Self in a very real sense. And this has happened: in the user interface objects are defined graphically and code is practically limited to short MPL segments in boxes. The text-ODL is still there if you need it, of course, but except for defining inline blocks it is not really used for most common programming chores. If you have to face ".self" files, then I'll agree that there are less intemidating languages around. But the current ( and certainly even more so in the future ) implementation seems to me to allow simple, clean and powerful programming which I would not hesitate to show to novices. - Jecel

3 2

More Reflection in Self?
by jecel＠lsi.usp.br 22 Jul '94

22 Jul '94

Several papers I have read as well as dicussions on usenet have implied that Self is a very reflective language. I would say that this is a wrong impression: Self is roughly equivalent to Smalltalk, with mirrors merely making up for the lack of classes. So the question is: Do we need more reflection in Self? My answer: no. ( !?!?! ) I'll explain: 1) Self runs on top of Unix and X. All of the system services can be accessed through the system call or by adding primitives. 2) Parts of the application can be written in other languages and interface with the Self part through a rather thick "firewall". 3) The set of "knobs" you can mess around with in the VM is well thought out and will allow as much access to the implementation as most applications will ever need. 4) The thread implementation is very flexible and allows the scheduler to really be written in Self ( having done some "real time" in Smalltalk V/286 lately, I find this very important ). So... why am I trying to add more reflection to Self in my Merlin Project? Because 1) it runs on bare hardware ( it *is* the OS ), 2) primitives written in other languages have transparent access to the implementation, 3) I want to get rid of the VM altogether and 4) I want to go beyond threads to multiprocessing with object migration and other weird stuff. Brook Conner <dbc(a)cs.brown.edu> wrote: > mulet(a)info.emn.fr (Mulet Philippe 40448387) wrote: > > Mirrors are not causally connected to the structures they represent. > > Hmm? How do you mean? What reflective stuff do you want to do that > can't be done with mirrors? This isn't a challenge: I'm trying to > figure out how much extra junk you have to add to something like the > base Self model to get full reflection. (Part of my research is in > stripping down existing object models until you get something that you > can use to build exciting new object models. TR available any day > now). And I am trying to find out how much junk I can throw out to get reflection in Self :-) - Jecel

1 0

Re: consistency again
by jecel＠lsi.usp.br 22 Jul '94

22 Jul '94

> Bruce McKenzie <bruce(a)trwlasd.com> suggested making the behaviour > of receiving messages dependent on system state. > Brook Conner <dbc(a)cs.brown.edu> showed how to do this in > Self using dynamic inheritance. This is a very good example of how to use dynamic inheritance. This makes it as easy to vary the result of message lookup depending on either global as on the individual object state. An interesting paper I read which included different actions on message reception depending on whether an object was idle or executing another method ( they have single thread objects ) was: "An Effiecient Implementation Scheme of Concurrent Object-Oriented Language on Stock Multicomputers" by Yonezawa et al, in Fourth PPOPP, 1993, pages 218-228. Their compiler simply generates several C++-like VTables and the object switches between them as its state changes. This is another case of trading memory for speed. - Jecel

1 0

Re: consistency again ( was: Notation for delegation in OMT or BOOCH )
by Bruce McKenzie 20 Jul '94

20 Jul '94

> [ deleted ] > I found this work very interesting. One of the things I liked most > was how message reception was devided into two phases: the lookup > where the object ( really the meta-object, but let's ignore that ) > decides which of its slots is refered to by the message selector, and > the apply where the result of the lookup does something according to > its nature. > > [ more deleted ] > > I would not complicate the implementation for consistency unless there > was a real gain. I can imagine some pretty useless stuff ( I suggested > method parents about two years ago :-) : > Background: I'm a near-lurker on this list. I do Objective-C programming for the NeXT. One of the nicest aspects of Obj-C is the (true) dynamic binding, and the run-time class creation, loading, and general mayhem that is possible. One benefit that I can see to the two-phase approach is the possibility of implementing a conscience for an object. Namely, "Normally, I implement all setPosition:: messages, but when the system is in a 'panic' state, I ignore them." (implying that "setPosition::" is a family of messages, and you don't want to put the same state checking code in each one) Objective-C provides capabilities to do this, but it would be a bit of a hack. Does this sound useful? Have people experimented with this? --- Bruce McKenzie (spuds(a)netcom.com, NeXTMail welcome) Atlas Software Ventures, Inc. PO Box 1299, Santa Clara, CA 95052-1299 800/278-9909 (ASV-9909) *** Software Development, specializing in NEXTSTEP *** ---

2 1

consistency again ( was: Notation for delegation in OMT or BOOCH )
by jecel＠lsi.usp.br 20 Jul '94

20 Jul '94

mulet(a)info.emn.fr (Mulet Philippe 40448387) wrote: > I am working on meta-object protocols for controlling and extending > the semantics of message passing. > > As such, Pierre Cointe and I, defined a prototype-based language, close > from Self at first, without any delegation, but supporting a full reflective > model. > Then, we extend this model only by involving its reflective facilities, > so as to provide single delegation, multiple delegation, caches, ... > in an incremental way. > > If you are interested, I can give you more information, I found this work very interesting. One of the things I liked most was how message reception was devided into two phases: the lookup where the object ( really the meta-object, but let's ignore that ) decides which of its slots is refered to by the message selector, and the apply where the result of the lookup does something according to its nature. This reminded me of: > Subject: Re: consistency in Self Randall.Smith(a)Eng.Sun.COM (Randy Smith) wrote: > ivan(a)cs.man.ac.uk wrote: > > Maybe this is an extreme point of view - but don't you think it's inconsistent > > that you can't have a parent slot 'implemented' as a method? > > OK - so it might be a bit slow - you'd have to call the parent slot method(s) > > for an object for every message it received. > > No, I don't think it extreem: it's also bothered me for the very > consistency reason that you point out. > > Should the method in the parent slot be evaluated when a message lookup > has to go through that slot? If so, why? And if so, what if that method > sends subsequent messages to self that don't match directly in the > receiver? Infinite regress city. > > But maybe the method in the parent slot is not evaluated when it is > looked up through (new verb form there). If not, why not? And is there > some utility to having parent as a message be different from parent > used in lookup? > > These thoughts have always bogged me down. >From the lookup/apply point of view ( there are certainly others ) the lookup and the "parentness" of a slot are a property of the receiver of the message, while the behaviour of the slot ( if it returns data, assigns to another slot or executes code ) is a property of the slot itself. To execute the slot's code during lookup is to mix things up in a not very useful way. So whether one way is more consistent or the other depends on your model of how things work. I would not complicate the implementation for consistency unless there was a real gain. I can imagine some pretty useless stuff ( I suggested method parents about two years ago :-) : 1) parent argument slots - we already have an implcit ":self*" slot in every method. But user definable parent arguments ( how is that for dynamic inheritance :-) would be very dangerous as any method might get inside access to objects passed as arguments to it ( a poor man's multimethod? :-) 2) assignable method slots - we already can assign blocks ( but can't do anything with them ). We can also get close with "sillyParent: ( | x = ( ... ) | )" as an aproximation of an assignable slot "x". And, for the patient, there is always "_AddSlots: ( | x = ( ... ) | )" 3) I'll leave this as an exercise for the readers... - Jecel

1 0

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 July 1994