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