*Development Direction*

Ok, everyone, we need to establish our development priorities and
direction, so here are my ideas to kick-off our discussion:
Strongtalk Project Direction First of all, I want to say "thank you" to
all of you who have expressed interest in Strongtalk, for your
enthusiasm, and also for your patience while the project is set up.  Now
it's time to get going!  To start, let's talk about the big picture.
Why Should Strongtalk Survive? Strongtalk was developed over 10 years
ago, and development was basically halted in 1996.  It was not fully
completed, and there has been no further work on it since then.  In the
meantime, all of the original developers have moved on to other projects
and companies.  Most other projects that have lain dormant for that long
are no more than historical artifacts.

So why is Strongtalk different?  Why should anyone care about this old,
unfinished system?

    *  It is still by far the fastest, most advanced implementation ever
built for Smalltalk, or for that matter, any dynamic language (other
than Self, upon which it is based).  To this day, there are still     no
production virtual-machines for any language that use the full
type-feedback technology.


    * It works really well.  Those who have used Strongtalk the most, the
original members of the project, know that the technology wasn't hype-
the VM truly is extremely fast, has a small footprint, compilation
pauses are insignificant, and it is actually pretty reliable given how
little testing has been done on it.

On the Smalltalk side, the type system and GUI also work very well. 
Although the type annotations may appear verbose to traditional
Smalltalkers, the types really did help find bugs faster and earlier,
and are a huge benefit when trying to understand the code.  It is true
that type-safe code is more restrictive than untyped code, but
Strongtalk's type system is a lot more flexible than you might think if
your experiences are based on other, more restrictive type-systems. It
definitely still feels like Smalltalk!

Development wasn't stopped for any reason related to the success of the
design, but due to the sudden Java fad, which impacted virtually all
dynamic language development.  The only reason it has been sitting on a
shelf for all these years has been to protect Sun's investment in using
the technology for Java.  With time and a changing world, this issue has
finally faded.

    * It was designed from the start as a production-quality system.  
Although it is not finished, it is clean and well-engineered. It is not
a research project, where design shortcuts can be taken because the
system isn't intended for production, or where blue-sky experiments have
been tried that don't quite work out.  It also benefits from the lessons
learned in the Self system's pioneering research implementation (as an
example, Strongtalk's use of an interpreter for initial execution,
rather than a first-stage compiler as in Self, is a significant design
change based on complexity, startup time and memory footprint issues in
the original Self implementation).

    * The VM type-feedback technology has unique advantages other than
performance.  Type-feedback doesn't just make programs run faster.  It
fundamentally changes the programming cost-model in ways that can allow
programmers the freedom to factor their code much more cleanly.  Many
kinds of code factoring, such as instance variable accessor methods,
custom control structures, extensive self-sends, etc., become
essentially free.  This is an important capability that is needed in the
real world.

A related effect is that type-feedback removes much of the traditional
performance penalties associated with Smalltalk and other dynamic
languages that have a unified data model (especially tagged integers)
and full closures, relative to other languages.  This can encourage
adoption of dynamic languages in the future.
What Should We Do With Strongtalk?
There are many different uses that the Strongtalk technology could be
adopted to.   As I see it, there are two basic directions that
development can head in:

    1. Attempt to turn Strongtalk into a full-fledged, production-quality
Smalltalk.
    2. Devote all of our efforts into helping other Smalltalk
implementations (and perhaps other dynamic language implementations as
well) adopt the various Strongtalk technologies.

    3. Option 2, but focusing solely on the virtual-machine performance
technology

Option 1 has several major difficulties associated with it:

    * There are a great many things that would be needed at the Smalltalk
level before Strongtalk would be complete and competitive with other
Smalltalks in functionality: UI functionality, networking and Web
protocol support, refactoring browsers, documentation, revision control,
GUI building tools, etc. ad infinitum.

    * The last thing the Smalltalk community needs is another slightly
different implementation that fragments the Smalltalk developer base
even more, and trying to convince people to switch application
development to a new, different Smalltalk would be very difficult.

    * At the moment, the development resources to do this simply don't
exist, although that could change.
Option 2 would be a significantly more focused effort, and has the major
advantage that it would avoid splintering the Smalltalk market even
further.  And, since it would target existing systems that have active
developer communities, there would hopefully be more development
resources available to do the work, and the result would be more likely
to be used.  Weaknesses of Option 2 include:

    * It would be difficult for mature existing implementations to change
their libraries or languages in significant ways, which would be
required to adopt the parts of the systems written in Strongtalk.  This
would also have big impacts on applications for those platforms.

    * Likewise, mature systems have their own virtual-machine
technologies, some of which have some advantages over Strongtalk's VM
(specifically, Squeak's VM is written in a minimal dialect of Smalltalk,
which is very handy).  This would likely result in a fair amount of
resistance to the idea of changing VMs, partly due to Not-Invented-Here
syndrome.  Frankly, this would be quite understandable- VMs take a large
amount of effort to design and maintain, and who wants someone from out
of nowhere asking you to drop the fruit of years of planning and work? 
The saddest part of it is, the people most likely to resist would be the
smart people who have invested their effort in building or maintaining a
VM or compiler, and those are the people we would most like to be on the
same side with.

Option 3 is like Option 2, but tries to be more realistic by focusing
our efforts on the transferring the VM technology, which is the most
likely to be adopted and bring big benefits to other systems.  It has
the same drawback as Option 2 relative to the VM, but would not disperse
our efforts as much.  The big additional weakness of this option is that
it would lose all the other innovations in Strongtalk, such as the
type-system, glyph-based UI with native widget support, library and
language redesign and simplification, mixins, etc.

The most significant issue we face is that at the moment, there is a
very small amount of time available from people who are familiar with
the details of the Strongtalk VM internals, so we have a significant
learning curve ahead of us.  There is some possibility that this could
change soon, but we can't count on it, so we need to figure out how to
proceed with just the spare-time volunteers available (including me).
The Middle Way
Given the above dilemma, I propose a middle path, that attempts to keep
our options open for now, and use our limited resources effectively,
without committing Strongtalk to any of the above paths before we see
how the community and interest from other systems develops:

    * Stabilize the Strongtalk VM, prepare it for porting, and flesh out
the Strongtalk-level code just enough so that real development can be
done, while leaving open the question of whether Strongtalk will go into
real 'production' or not.

In the process of doing this, I think we should devote considerable
effort to building up VM design documentation and helping those who want
to learn about the VM design move up the learning curve.

    * Attempt to use the expertise and infrastructure gained above to get
the Strongtalk VM technology adopted by Squeak, and/or perhaps even Ruby
or other languages or Smalltalk implementations, and try to lend a hand
as far as that is feasible.


    * Encourage the Strongtalk VM to be adopted as a VM research vehicle
at universities.  This is the only open-source type-feedback VM in
existence, and it is well engineered and highly functional, so this
shouldn't be that hard.  The goal is to end up with a larger base of VM
experts who can take advantage of this technology, and who would
hopefully contribute to it as well.

The advantages of the above are:

    * We can start off slowly building a base of people who understand
the VM, developing documentation as we go.  Over time, this should
alleviate the lack of VM engineering resources, and encourage adoption
of the technology by others.

    * It leaves open the possibility of eventually bringing Strongtalk to
a production state, depending on how resources and enthusiasm develop
over time.
    * It focuses effort on trying to adapt the VM to an existing
Smalltalk, so we don't have to worry about building a community or
splitting the Smalltalk market.  Also, it relieves us in the short term
of the burden of developing all the other libraries and tools needed for
production development in the modern world.
Feedback Of course, ultimately the path we take is up to you, the people
who are interested in helping develop Strongtalk.  This document is not
intended to dictate any path, but to serve as the trigger and focus for
discussion.  There are sure to be differences of opinion on these
matters.    If we are all reasonable and realistic, hopefully we can
come to a consensus that we can all pull together on.

So, let the discussion begin: What direction should we go in?

-Dave