[squeak-dev] [Cuis] Cuis

Josh Gargus josh at schwa.ca
Thu Jan 21 19:49:16 UTC 2010


On Jan 21, 2010, at 10:00 AM, keith wrote:

> The Vision
> =========
> The "lurkers" just want to see a new flashy image, that they might try a little project in one day.
> 
> The "community" want to see the board provide vision and to promote harmony both philosophically/ideologically, and with technical facilities; harmony among all squeak forks, even those who don't want to be harmonised (i.e. Pharo). The community members want to be able to publish a package (e.g. Magma) and have it be tested to work for everyone, whether they be pharo users or squeak users. The community wants to be able keep its large published, even deployed code bases up to date and bug free.
> 


The "community" doesn't want only one thing, and different people in it want different things to different degrees.  I don't dispute that what you have described above is desirable, in principle, to the vast majority of community members.  However, it is fundamentally at odds with other goals that various community members hold dear.  A balance must be struck.

Here's a very specific example.  I would like to see more integrated support for concurrent programming in the Squeak kernel.  Toward that end, I've added a trivial implementation of "promises" to the trunk (hopefully, I'll take it further relatively soon... one of the things I've done in the interim was to re-read Mark Miller's dissertation).  The current changes are intentionally non-invasive.  However, it is possible to envision widespread adoption of such programming constructs throughout the image.  Any packages that use such constructs would rely on the support in the Kernel package.  

How do you propose to support new programming paradigms that push us beyond Smalltalk-80, and yet have every package be loadable into every release of every fork?  It's fine if your answer is that this conflicts fundamentally with your vision: compatibility is king.  Just be aware that your vision is no more synonymous with the "community's" than mine or Andreas's.

It is impossible to deny that since the inception of the new development process, there has been a steady flow of high-quality contributions integrated into the trunk image.  Most of these haven't been from Andreas, although he's probably the most productive single member (that's just how he is).  It is unfortunate that this progress has been at the cost of some cross-fork compatibility.  However, you have to admit that there is something about the new process that is enabling Nicholas, Levente and many others to contribute in a way that they weren't before.  Even if it wasn't a problem with Sake/Bob per se (i.e. there were other external factors at play, like uncertainty about the 3.10/3.11/4.0 roadmaps), what's done is done; things are moving again, and that's good.  

In text trimmed below, you refer to a "golden age" of Squeak development under your guidance.  However, my impression is that the community has been greatly enthused by the progress that has been made since the switch.  Personally, I wouldn't go so far as to say we have a golden age today, but it's certainly better than a year ago.  As long as you propose that we stop using a process that is clearly "working" (for some definition of "working" compatible with what I've written above) and switch to one that is at best unproven, then it is natural and proper that your proposal will meet with resistance.

I wholeheartedly wish for the rapid healing of your hurts; your position within the community as the "extreme" advocate of cross-fork compatibility is potentially very valuable if we can achieve some of your goals without sacrificing the benefits of the new process (and, of course, I wish it simply for your own sake).  It's a new decade!  Let's see if we can find some common ground.  I do believe that it exists.

Cheers,
Josh



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100121/27de3ce2/attachment.htm


More information about the Squeak-dev mailing list