Re: SmartEiffel shortcomings?

--- Roger Browne <[email protected]> wrote:
> Those are very worthwhile things. Let's look at your
> previous list of desirable improvements:
> [1:] Better exception handling 
> [2:] Better standard library
> [3:] Better garbage collector
> [4:] A "storage" implementation.
> [5:] A useable (not that slow) debugger.
> [6:] Multi Threading.
> [7:] Faster compiler speed for large projects
> [8:] Compatibility for years
> ...and mine...
> [9:] A decent GUI library
> [10:] Smooth support for dynamic library generation
> and use

I think everyone would enjoy having these benefits.
I would imagine that the SmartEiffel Core would
also enjoy these items.

Couldn't some kind of middle ground be reached?

For example:  In response to similar structural
difficulties with the management of the Mozart/Oz
project, they have established a more open body of
contributors (consisting of the original university
researchers, plus major outside contributors) to
form a "Mozart Consortium".

Perhaps something similar could be worked out here?

Certainly it seems like a common source archive could
be used, with one "fork" consisting of the core
SmartEiffel system, and a parallel "fork" holding
the "industrial" version that most of us would like.

Perhaps the monotone archive recently announced would
be a good basis for this.  I'm sure we could host
such an archive on Alioth or a similar Free Software
development site.

Then we don't have to pack up our ball and go home;
we could each work on what we want, while merging
changes (useful to both sides) such that work is
not duplicated.

-Brent