[self-interest] squeakifying? (was: licenses and working together)

[Jecel Assumpcao Jr]

Gordon Cichon wrote:
> Yes, I absolutely agree with you.

Oh. That means I will have to actually sit down and program what
I have been promising all these years.

My sister has decided to use my system in her PhD project, which
will have a group of high school students programming a simulation.
So I had better have *some* Self running on Windows PCs by March
or nasty things begin to happen.

> I agree with you that the best implementation of Self would be
> in Self. But what exactly is Self? For me, Self is more than
> this angle-bracket-thing. You also defined some extensions
> to the Self language. I think Self is not well-defined enough
> to do an implementation in itself now. Ideally, at least SIC
> should be implemented in Self.

I have played around with some extensions (extra bytecodes for
writing portable primitives, parallelism in tinySelf 1) but
that doesn't mean Self 4.0 can't implement itself as it is.
We need at least the NIC implemented - the Mac port shows we
can get by without the SIC for a while. For those on the list
not familiar with these terms, NIC is the simple compiler that
generates slow code and the SIC is the more complex one that
generates faster code.

> I think, this is logically the next step at the implementation
> side to lay down a framework onto which optimized compilers for
> different architectures can be plugged in. Just like GCC has its
> framework, Self could have its own, too.

Exactly. I was looking at Ian Piumarta's paper at the VM workshop
(http://www.squeak.org/oopsla99_vmworkshop/) but don't feel that
is the way to go. I once saw a generic compiler backend written
in C++ once that was very nice: the main classes would define
everything in terms of abstract methods (generateJump(), for example)
and then each CPU would get a subclass that would fill in the
details be overriding these methods. Not as elegant as a declarative
approach like the GCC, but it does get the job done simply and
very effectively.

> It would be a nice thing to "squeakify" Self, but please correct
> me if I'm wrong, a squeakified Self would run so slowly that the
> UI would be completely unuseable.

I don't know what you mean by "squeakify". If you mean to an
interpreter in Self and translate it to C, you are right. It
would be much worse than Squeak, in fact, unless we added some
bytecodes or did a compilation to threaded code.

I want a NIC in Self that spits out X86 instructions. We can
always worry about PPC/Sparc/ARM/MIPS at some unspecified date
in the future :-)

> And this Mango stuff is IMO
> exactly the right stuff to play around extending Self grammar and
> semantics. I would like to keep this stuff going, and not to
> break it. Say, if you had an arbitrary slow interpreter of Self,
> say written in perl, you would find it pretty difficult if not
> impossible to write demanding code with it without UI. The Self
> language gives you so much freedom that you are completely lost
> without a user interface that guides you through the process.

>From my experience with tinySelf, things can get out of hand even
in the Self environment. But I got ten times further than in
C/gdb before I ever ran into trouble. Using anything other than
Self 4 for developement makes no sense (except if you are working
on a port because you don't have where to run Self 4...).

But I see no need to extend the Self grammar (though we do need
a parser in Self, among other things).

> And, IMHO I think, what holds back Squeak is that it is too
> old and too late, and it is not even free software. Come on,
> this is just another implemenation of Smalltalk-80. They are even
> proud of not being integrated into an windowing system. Who is
> today going to deploy an application that is not integrated into
> the windowing system?

True, but they have their reasons and they did more than I expected
on such a weak base. Now that they have created a motivated group,
they are trying to go back and fix the implementation. It seems
to be working.

> I think, Smalltalk could have played the role that Windows plays
> today, i.e. the integrating framework for different applications
> that run on a virtual machine if ParcPlace hadn't been so jealous
> about its licensing policy.

There was Smalltalk/V (16 bit DOS) and the Tektronix 4004 ($15K).
And I feel guilty about this as well since we could have finished
the Merlin 2 by the end of 1987.

> If they had sold Smalltalk-80 for 50
> bugs, people would have used it, just like they used Windows. 

No, Windows has much more than 50 *bugs* :-) :-)

> But
> that opportunity is over for a long time already.

Linux proved that the OS wars can be restarted after everyone
is sure they are dead.

> Any OO environment
> that likes to be used by the people must have 1) a social licensing
> policy, and 2) a social environment. It has to integrate into its
> host environment, window system, operating system, and other object
> models. The time of autism is over and it won't come back.

I have some ideas about that. The first thing is to be able to map
any morph to an OS window, not just worldMorphs. When you choose
"move to own window", your application looks nice. But one wrong
move of the mouse and suddenly half of it is gone and there is
a big white area in the window. Morphs in MVC windows in Squeak
have this exact same problem.

Another thing that might help Self feel more native would be to
move the objects picked up by the hand to their own window on
those window managers that support frameless windows. It could
be made to look like it does now, except that the objects you
are holding can go beyond the borders of the world you are over.
Imagine dragging something from a factory window to a world when
the windows are far apart to see what I mean.

So I want integration with the OS, but I want to allow Self to
be the OS when it needs to (like on the machines I am building).
Why do we have to choose one or the other? Oberon has both and
so can we.

-- Jecel