SmartEiffel open Edition - what would be the goals?

This message explores an idea that I mentioned in a previous message
(replying to Lothar).

I think the Eiffel community has the capability to develop a popular,
industrial-strength open Eiffel compiler, tools and libraries. What
should the broad goals of such a project be?

I can't really embrace Daniel's idea of repeating history by developing
SmartEiffel 1.2 as a transition between 1.1 and 2.x. The SE team has
done several man-years of development between 1.1 and 2.x. Why repeat
any of that work? If we want the fruits of that development, we should
just keep using 1.1 until we are able to upgrade to 2.x. If we don't
want the fruits of that development, we can continue to maintain 1.1.
To do some of the same work over again seems like an unnecessary
duplication of effort. But maybe I misunderstand Daniel's goals.

An interesting question is: what should we do if we want to continue to
develop SmartEiffel, but with different priorities than the SE research
team? What would the priorities be for a community-developed industrial-
strength SmartEiffel? Here are my suggestions:

   1. Correctness. All the other benefits in the world are of
      no use if the software crashes or produces erroneous results.

   2. Compatibility. We want compatibility with the past
      (so that we can use existing libraries), and compatibility
      with the future (so that we can use future enhancements).
      The future is currently being led in two different
      directions, by the SE research team and by ISE Eiffel.

      So the answer is to start from SE 1.1 (because it has
      lots of library support, and is somewhat compatible with
      several other Eiffel compilers), then over time to introduce
      ISE or SE2.x features that don't break the libraries (either
      because the new features don't break compatibility, or
      because the library maintainers are ready to move
      forwards). There's no hurry to introduce new features,
      because existing Eiffel is already a mighty fine language.

   2. Interoperability. We need to be able to use Eiffel for
      real-world projects, so: we need to be able to call
      and be called by software written in different languages;
      we need to run our software on different platforms and with
      different configurations and different execution environments.

   3. Performance. We want SmartEiffel to be fast to compile.
      We want the compiled executables to run fast.

   4. Productivity. We want an elegant language surrounded by a
      productive set of tools.

   5. Simplicity and maintainability. We want a product that's
      easy to build, easy to learn, easy to maintain and easy
      to use. This goal can be hard to reconcile with some of the
      other goals, but in my opinion it's critically important.

Should we fork SmartEiffel 1.1 with a set of goals similar to these?

Regards,
-- 
Roger Browne <[email protected]>