Well, I'm hacking pretty hard, mostly under the sheets in the VM. The
high order bit is: great job indeed. No small task, and well done.
More [and higher level] comments in the VM, but you know that.
Documentation and code have drifted, but we're only in beta -- I
assume that's gonna be fine by release-time.
The UI. Heh. Slow sun-4 over a net. I lose bad. I seem to want
more flexible [erk I might mean "shell-like"] typeins. Visual mark
for context would be very nice. Being able to change context visually
would be nice as well.
Having results avoid stacking if they can might be nice. Rather than
having a bunch of smallInts stacking in Z, they could also stagger a
bit in X and Y so I can better see them all. 2.55 D rather than 2.5.
Big gripes. No effective reflection on run-time structures. I can't
muck with a mirror on an activation and change stuff. Likewise with
the parsing. I should be able to change a method's byte-codes and
have the change be effective.
Likewise, I can't see any way to change the output of the parser from
Self, either by hacking the parser or by modifying every method in the
system. I'd like it sometimes.
I understand there is work afoot to change the way _Prims work. Good.
I don't know what it is, but I'll spew my half-thought-out idea. I
see most of the _Prims as methods on some hidden parents. They are
messages that will invoke a method even if the receiver does not have
an explicit parent-chain for them. Handy mechanism, and I want it
open to the world. Or at least me. How you "ground them out" is
another matter. I don't like seeing _Defines in code all over the
place -- I might want to change the behavior of defining, and if it's
encouraged to cut to _Prims, I can't do that. I don't have a good
answer for this, but want to have these "hidden parents" just take
regular messages and be [more or less] regular objects so I can prod
them and change them.
Anyway. There's other stuff that I know doesn't stand a chance to
make an impact, so the hell with it. I think I'm starting to like
I too just love Self 3.0!
The language is exceptionally pretty... I really like the default
semantics of sending a message to self for example. The concepts of
slots are simple yet powerful. The orthogonal nature of the language
What I'm doing:
I've been trying to implement a program to play the pencil and paper
game of 'sprouts'... to see how fast it will go, and generally
evaluate Self. In terms of development speed it compares rather
favourably with C++ so far, but that isn't saying much!
My Comments on Self:
The UI is greatly improved, usably fast, though could be faster on my
SUN IPX. The 'type-in' windows are great! The slot adding features
need further thought, as they are usually slower that the type-in
method. I felt the animations were OK, but I wanted more speed and
switching them off improved the speed nicely. However it lost me
information, such as the waggling when you produce the same answer to
two different evals.
The debugger is really, really powerful. I wish it was slightly more
integrated with the UI, but it's very good in any case.
The Bugs I have seen with the Beta release are:
- ui occasionally crashes, when I try to move things fast, with an error
like 'no myUI slot' or something. Some kind of concurrency bug...?
- ui occasionally hangs, apparently when moving an object on the
screen. Killing the process and typing 'ui start' is an apparent work
- ui(?) occasionally grabs all of memory. This crashes Self, losing any
- ui pauses for up to 5 minutes apparently at random (if I run 'jobs'
on the shell window I started on, that starts OK then hangs on the
suspended processes till the end). It doesn't seem to be garbage
collection, but then my _Spy doesn't work half the time... ;-)
- ui sometimes stops buffering keyboard presses. Have to hold the keys
down to get anything in. It seems to be linked to moving large (1/3
screen height) objects around, or when the screen is very full(?)
- something like typing '_Spy: true' to 'lobby' seems to permanently
disable the spy feature... haven't quite pinned this down, you may
need to exit and read in the snapshot again or something to trigger
the bug, but when triggered it persists as long as my snapshoting
- I had difficulty removing a descendent of list that is contained in
a descendent of a hashed set, e.g. 'remove: first' gave an error that
that member wasn't present, until I changed the definition of 'hash'
in my descendent... I think perhaps traits collection hash has a
Still, it *is* great fun! Can't wait for the release... my admiration
to the team.
p.s. if the team needs info on any of the bugs, ask and I'll try to
obtain stack listings etc.
Thanks for the comments--there is one I do not understand.
You seem to have tried to change a method's bytecodes and have it
What exactly did you try?
There is a way to do this, using the methods in mirror.sm
to create new methods (based on info from old ones), and then
do a one-way become (called *Define* (stars are wildcards)) in mirror.sm.
I can send you a short program that does it, if you are interested.
I just loved Self 3.0!
This is a huge improvement and I think you have crossed a threshhold
where the system is now a lot closer to Smalltalk implementations
in maturity. Many people who are rather conservative have expressed
interest in trying out Self when I showed them 3.0.
The animations are very entertaining ( and well thought out ) and
do not tire with repeation. I really prefer to program graphicaly
to typing what reminds me of LISP ( even though I adore LISP! ).
By working with methods one at a time people can clearly see
that Self looks almost exactly like Smalltalk.
On page 22 of "How to Use Self 3.0" there is a footnote saying "Menus
do not reflect the philosophy of concreteness we espouse for the ui."
I had the same problem with a "visual smalltalk" I designed many
years back. What I did was to call them "remote controls" and stop
worrying about it ;-)
The syntax on page 27 of "The Self 3.0 Programmer's Reference Manual"
does not seem to me to allow nesting of annotation as mentioned in
the text. I guess the text is right? How about a 'Man:' annotation
for Unix fans? :-) An 'Examples:' annotation might be nice too. Maybe
these things should go into the module objects as they refer to a whole
group of objects ( an application ) rather than just one.