On Tue, 16 Feb 1999, R. A. Harmon wrote:

> I think many good suggestions have been made that will improve Squeak not
> only as a tool for creating applications, but for building the future
> vision.  I also think a second fork would be counterproductive to both forks.
> 
> Some things I'd especially like to see are:
> 
>         - a more module core release.
>         - interaction with outside tools.
>         - mechanism for calling code written in other languages,
>           and calling from code written in other languages into Squeak.
>         - a declarative model.
>         - Integrated source management.

I agree that the things you list would be great for both the current
research-oriented Squeak vision, and a Squeak tool for creating
"professional" applications.

Still, there are potentially some features which would be great for the
Squeak application tool, but might not fit in as well with the Squeak
vision.  Native window support is probably a good example... it's
essential for a good application tool, but it would add a fair amount of
complexity to Squeak (threading issues), and it would compromise
portability to platforms such as PDA's which have no native windows.

I guess when considering adding features essential for a Squeak
application tool, there are 3 options:

1.  Add the feature to the main Squeak (supported by the Disney team).
2.  If the feature is too complex/platform-specific or otherwise doesn't
fit in with the Squeak vision (i.e. is rejected by the Disney team), add
the feature to a special Squeak Pro fork (whatever it be called).
3.  If the feature is too complex/platform-specific or otherwise doesn't
fit in with the Squeak vision (i.e. is rejected by the Disney team), and
there is no Squeak Pro fork, give up and don't add the feature, and let it
become one of many neglected, unsupported file-ins sitting off on a server
somewhere.

Of course, #1 is always the best option.  But in the event that #1 won't
work, #2 is still a better option than #3.  I believe that the Disney team
has indicated in the past that they wouldn't mind if a more stable,
professionally oriented version of Squeak came about while they went on
ahead with the future vision.  (Although I don't want to speak for anyone.
:) )

So, native window support is probably a #2 item.  Improved modularity is
another issue which has been brought up a lot lately, hopefully it's a #1
item, but I'm not sure if Squeak Central has any opinion on it.

Although if modularity were truly addressed, maybe forking might become
less of a necessity?  (I'm not sure if something as fundamental as native
window support could be separated into a module, though.)  Maybe "fork" is
too strong a term anyway... the set of Squeak Pro tools would ideally just
lag behind the Squeak vision, upgrading (merging?) to a newer Squeak
version periodically (once a year or so, not too often so as to preserve
stability)... 

(Sorry for the rambling, it's getting late...)

- Doug Way
  EAI/Transom Technogies, Ann Arbor, MI
  dway at eai.com, dway at mat.net
  http://www.transom.com

  Smalltalk: Guaranteed Y10K Compliant