Brook Conner dbc@cs.brown.edu wrote:

"Michael Grant Wilson" mcq@oti.on.ca said:

...

urs@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.

**> On Fri, 22 Jul 94 00:05:23 EST, jecel@lsi.usp.br (Jecel Mattos de Assumpcao Jr.) said:

Jecel> This is a *very* important issue for me: my project will be a Jecel> garanteed failure unless I can teach a number of people to Jecel> program in its language ( as the first programming language to Jecel> most people ).

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 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... :-)

[ ... ]

Jecel> When I looked at Self, I saw at once that: Self = ODL + MPL, Jecel> where ODL is Object Definition Language and MPL is Message Jecel> Passing Language. The MPL is a slightly modified Smalltalk Jecel> that is highly readable ( not as much as scripting languages, Jecel> but handles nested expressions much better than those ). The Jecel> ODL is the LISP-like ( | x <- .... y = ( | .. | .. ) | ) Jecel> kind of thing.

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 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 -- 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).

Jecel> The neat thing is that one or the other might be replaced by Jecel> an equivalent notation and the whole would still be Self in Jecel> a very real sense. And this has happened: in the user interface Jecel> objects are defined graphically and code is practically limited Jecel> to short MPL segments in boxes. The text-ODL is still there Jecel> if you need it, of course, but except for defining inline blocks Jecel> it is not really used for most common programming chores.

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.

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.

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!

Brook