AW: [Squeakfoundation]New mailing list request for Bellesqueak

[Paul Fernhout]

Andreas Raab wrote:
> Nice (and pretty long ;-) memo. However, I am somewhat surprised to see
> you so focused on licensing issues. After all, if you're really off the
> blue plane you can choose any license _you_ want. If people agree with
> it they'll follow. If not you gotta figure out how to fix it.

Thanks. Good point on picking a new license for a totally new system.

I guess I see license management as a bigger and bigger part of the open
source / free software puzzle as time goes by and code and content
accumulates which does not interoperate... And obviously there are other
issues like modularity which I care about. My feeling about the status
of Squeak licensing both in theory and practice (which others disagree
with me on) has always been a major impediment to my making a major
investment in using or improving Squeak (beyond casual use for some
experiments such as LinksWorld, Embedded Squeak, Pointrel in Squeak, or
for prototyping, doing simple text and data processing, playing Morphic
games, reading email, debugging HTTP headers, exploring 3DS, wowing
friends, etc.).

> But seriously, wouldn't it be time to start thinking about what
> BelleSqueak wants to do besides discussing licensing issues?! ;-) In
> response to Cees message ("what do other people think") I would like to
> post my reaction depending on the content and not the license. 
> [snip]
> After all, as long as you're doing it for your own
> personal purposes you _can_ use GPLed code. Nobody is arguing that parts
> of the code within Squeak need a clarification on the license but that
> doesn't quite justify a "ground up rewrite", does it?!

I was trying to avoid a discussion of the project on its (vaporware)
merits in this thread -- hoping instead to have such discussions (and
related redesigns they will undoubtedly suggest) on a Bellesqueak list
itself. But you have a good point.

So, in a nutshell my technical vision for Bellesqueak is:
* A VM based on GNU Lightning (or something similar) and including hooks
to the real hardware (If you can't crash it, you're not doing the
driving)
* A way to translate code targeting the VM to native code (GNU
Lightning, or  Ian Piumarta's work on which it is based)
* Easy creation of isolated VM subsets for remote debugging 
* Various tools to operate over that virtual instruction set
* Multilanguage support including psuedo- Python, Forth, Smalltalk,
Scheme, Basic (forgive me), Object Pascal, and C sharing some common
libraries
* A common set of tools to operate over those various languages
* Integrated (distributed) source code and discussion archiving with
license management
* A version of a prototypish Smalltalk with a method hierarchy as
opposed to a class hierarchy
* A focus on modularity from the start
* A focus on transparency from the start
* Accepting tradeoffs towards moderate efficiency 
* A lighter-weight GUI than Morphic but with more "security" features
for selective locking of GUI elements and otherwise holding to many of
the Morphic ideals
* Building security and event handling in from the start (as above)
* Retaining desirable Squeak ideas like generating its own code and
having a simple base portability layer for bitmaps and event handling
(defined with a low level API other languages like C or Forth can easily
use natively)
* Some content related to sustainable development (simulations, texts)
* Some information management tools for handling email and in general
the flood of information we see daily these days

Obviously I haven't explained why my gut says these are good goals to
pursue, but for one small example, a VM based on virtual CPU
instructions will seem less efficient then a Smalltalk specific one, but
I think the potential speed up in easy translation to native code will
then make up for this loss in emulation many times over for Jitter type
code, and then this might allow other languages on this platform to have
the same big win. If all the tools target this VM set, then there is a
lot of leverage and much motivation to use it well or enhance it in good
ways.

These goals haven't changed that much from those I (and of course
others) have been thinking about over the years, although the rest of
the world is catching up with .Net DotGNU etc. See for example:
  http://www.create.ucsb.edu/squeak/9612.html#Letter94
Obviously, IBM was using a VM with multi-language support back in the
1960s (System 360)...
  http://pucc.princeton.edu/~melinda/

But these goals are in large part obviously hype, handwaving, and
vaporware at this point (which is why I call them goals). But hopefully
one can see that starting from scratch in this context given several of
these goals makes sense if one pursues these ends -- while at the same
time realizing that many existing pieces of code or documentation could
be useful to integrate as the system progresses (thus even as one starts
from scratch, one stands on the shoulders of others). I guess when I say
start from scratch I mean something more like -- exercise tight
editorial control over what goes into the system after performing some
experiments. Clearly, one needs scaffolding for building from scratch
and systems like Squeak (or Python) may help building the next
generation systems more quickly. 

Almost everyone of the goals listed above could be found in one system
or another -- the difficulty is bringing them together (in an open
source / free software way). The closest term one has now is an
Operating System, but I think that concept lacks some flavor of what I
am getting at as I try to implement "interpersonal" computing building
on the ideals of Alan Kay, Doug Engelbart, Vannevar Bush, etc. Could all
these be done somehow incrementally one at a time in Squeak? Probably
yes (including even swapping in a more generic VM), but I think it less
work and more fun to take the lessons from Squeak and "burn the disk
packs". And obviously, it will be the easiest work if the project is of
interest to enough people that they want to participate in it -- and
obviously the people on the Squeak list are some of the best people to
implement such a system if they found it of interest at some point as a
next generation Squeak. But obviously, since it is vaporware at this
point, it should not distract too much from incremental evolution of
Squeak.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com